Comment by edw519
15 years ago
Typical enterprise developer:
1. User knows exactly what he wants.
2. User can only express that in his own language.
3. Data flow diagrams, best practices, structured design, etc.
4. Dev still doesn't know what user wants but builds anyway.
5. 2 years later, project scrapped.
Scott Nesin:
1. User knows exactly what he wants.
2. User can only express that in his own language.
3. Developer patiently encourages user to express himself.
4. Eureka!
5. Much learned; happy ending.
It is a rare developer who can handle the Nesin step 3. It requires an empathy that doesn't come naturally to many engineers. However, when cultivated, that empathy makes for phenomenal developers. When I manage development teams, that is the number one trait I manage for. With empathy, all other problems can be solved.
[empathy] is the number one trait I manage for. With empathy, all other problems can be solved
You win. I've stumbled across a handy mental model (in which empathy plays a pivotal role) through research on mindfulness, emotion, and neuroscience, as well as in an emotional intelligence course taught at Google by Chade-Meng Tan. In short:
Bodily awareness -> emotional self-awareness -> emotional other-awareness (empathy) -> effective communication -> healthy relationships -> happiness.
It turns out that your brain uses the same machinery to model your own emotional state as that which it uses to model the emotional states of others, so the better you are at identifying your own emotional states, the better you will be at identifying them in others, which will allow you to communicate more effectively and so forth.
Also relevant: Asana's Jack Stahl touches on the importance of empathy in a post post about peer feedback at work: http://asana.com/2011/06/peer-feedback-at-asana/
Edw519 comments in list. Edw519 turns every post into a list. Do you speak in list?...
"how are you this morning Ed"... "1) I woke up 2) I had some coffee 3) I checked HN 4) Hell yes I am ok" :)
Moral of the story: Scott Nesin should be in charge of all Enterprise Development Projects from here on out. :)
Moral of the story: have engineers only work on projects from clients who are related. Nepotism facilitates communication!
Feeling potential for a new buzzword-methodology in this. It's common sense, but not so common that you can't charge for workshops/talks/certifications.
The only thing you need now is a good, substantial name that evokes a mechanical and engineering process, like "User Language Oriented Design".