Empathy versus sympathy in software

Nathan Marz recently wrote about what he calls suffering-oriented programming. The key take away was “don’t build technology unless you feel the pain of not having it.” This reminded me of Steve Jobs when he said, “it’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” Where Marz was saying how to choose what to build, Jobs was saying how not to choose what to build. For me, both lead to the same conclusion: develop empathy for your users, not sympathy (i.e. don’t feel sorry for them).

Sympathetic software is superficial and users sense it instantly. Empathetic software feels like it was written by an omniscient user with two key qualities: monk like awareness of reality (Jobs) and the engineering prowess to build accordingly (you).

We can’t develop empathy through reading, talking, listening, thinking or hiring someone else. None of these are sufficient. What is absolutely necessary is to do what your users do, day in and day out. If you feel the monotony, the frustration, exasperation, and the pain, then you’re on the right track. 

For example, if you’re trying to automate a punch card accounting system, then put on your overalls, and start learning how to punch cards. When you think you are an enlightened punch carder, do it some more. At the end of the path is awareness of the real problems, and you’ll know all the big and small things needed to solve them.