Empathy? Still speaking for software developers? Since when dealing with other people helps us create programs for computers? If you have a good specs may not even need to talk or chat to anyone
If you have a good specs may not even need to talk or chat to anyone
Judging from your use of the word “specs,” it seems to me that your experience with software development has mostly been with waterfall processes (or some variant where specs are created up front and the developer has little to say about the requirements for the feature). Or perhaps you worked with people who use the word “Agile” but don’t embody Agile’s iterative learning approach.
But for some developers, the ideal situation is where you accept the fact that we can’t know what the user wants— and when you can’t know, you don’t write specs. So you follow an iterative (I.e. Agile) process so you can develop -> learn -> develop -> learn.
And learning about your users involves being able to empathize with your uses needs so you can properly listen to what they really want you to build. And sometimes they don’t know until they’ve tried your software. That’s why in my opinion specs don’t work.
I like that you called out empathy. Frances Frei's TED Talk on trust has stuck with me for a long time. She advocates that trust has three components: authenticity, logic and - as you called out - empathy.
When I hire, I look for someone that will fit well with the team in question, and someone who is untrustworthy will never be a good fit.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Empathy, Curiosity, Persistence, and Humility
You can only pick one! Just kidding, these are all great answers. :)
Empathy? Still speaking for software developers? Since when dealing with other people helps us create programs for computers? If you have a good specs may not even need to talk or chat to anyone
Great software are made by great teams. :)
A balance is required, but empaty isn't the first thing that comes to mind, when talking about software development, engineering or construction.
Okay :)
Judging from your use of the word “specs,” it seems to me that your experience with software development has mostly been with waterfall processes (or some variant where specs are created up front and the developer has little to say about the requirements for the feature). Or perhaps you worked with people who use the word “Agile” but don’t embody Agile’s iterative learning approach.
But for some developers, the ideal situation is where you accept the fact that we can’t know what the user wants— and when you can’t know, you don’t write specs. So you follow an iterative (I.e. Agile) process so you can develop -> learn -> develop -> learn.
And learning about your users involves being able to empathize with your uses needs so you can properly listen to what they really want you to build. And sometimes they don’t know until they’ve tried your software. That’s why in my opinion specs don’t work.
Samsara: 5 Agile Techniques to End Suffering And Increase Learning
Cubicle Buddha ・ Apr 7 ・ 6 min read
I like that you called out empathy. Frances Frei's TED Talk on trust has stuck with me for a long time. She advocates that trust has three components: authenticity, logic and - as you called out - empathy.
When I hire, I look for someone that will fit well with the team in question, and someone who is untrustworthy will never be a good fit.