Thoughts on Empathy in Engineering

Posted by Matt Farmer on October 22, 2015 · 2 mins read

I’ve become more and more aware recently of the importance of empathy in how I do my job. Which, in some ways, is a bit comical because if you were to list some adjectives to describe the classic stereotype of the software engineer you likely wouldn’t mention “empathetic” in that list. I don’t know that I would either. But, nonetheless, empathy for my users – understanding them – is increasingly important for what I do.

If I don’t understand my users, their goals, and the realities of their day to day then I will build software that’s frustrating for them to use. If I build software that’s frustrating for them to use, then they’re not going to want that software, regardless of how well it solves the problem for them. In software design we spend a good bit of time thinking about usability and how it impacts the decisions users make about what software they use. Oftentimes solving a problem isn’t the hard part. Solving a problem in a way that makes the user want to buy and continue using your product is far more challenging.

I can write you a piece of software that does the same thing that Mint does in a few weeks, for example, but you probably wouldn’t choose to use it over Mint because it wouldn’t be solving that problem in a usable way. You would be so frustrated by how my solution works that you wouldn’t use it.

This gap is becoming more important for a lot of verticals that have gotten away providing a poor user experience to users. My generation is getting older. And as we’re getting older, we’re moving up in the ranks of the organizations we’re a part of. The number of people who grew up with iPods in their pockets will eventually take over leadership positions in organizations. As they do, the expectations they place on software their companies will purchase will increase.

Playing with new toys is fun. Whether your poison is Lift (like it is for me), React, Angular, Symphony, Rails, Sinatra, Express, Meteor, or whatever else you can name — if you want to build the best software for your users, you have to have a deep understanding of who they are, what they’re doing, and why they’re doing it.