Thoughts on empathy & software
N.B.: This is a collection of various, vaguely connected thoughts. I apologize if this seems to ramble and doesn't have a coherent point.
When I think of empathy I don't just think about the the ability to understand and share the feelings of another. I think about what it means to understand and share with another person. I think about the practicality of empathy in my day-to-day work.
Many of us have heard about "Developer Experience" and "Developer Empathy" in terms of API and service design. The idea of putting yourself in your user's shoes to understand how they'll use your API to solve their problems is a key skill in designing successful APIs.
However, I don't think we extend this concept far enough. Empathy is critical to not just the end product but the entire process of creating, using, and dealing (sometimes coping) with software.
Think about code reviews. Code reviews are absolutely critical to producing quality software. However, empathetic code reviews are even more critical. Think about it- if you're afraid of your reviewer, can you successfully write good code? Do you feel safe to experiment and learn? On the other side of the fence - if you're a reviewer and you lack empathy you become callous and even frightening to people who work with you. If people don't want to work with you then you can never benefit from another's perspective.
I can't stress how important empathy is to open-source projects. A maintainer without empathy will eventually scare away all but the most steadfast contributors. Likewise, a contributor without empathy can frustrate maintainers and cause some to want to leave.
We see this all the time. There are fantastic projects with maintainers who can't work with others and so their projects wilt. We also see contributors and users of open-source projects who make demands and have expectations without ever considering that the maintainers don't solely exist to cater to them.
It seems like sometimes it's very easy to forget that there is another human being - a person with feelings, desires, and experiences - on the other end of a code review, an issue, or a comment. Text is extremely poor at conveying tone and emotion (yes, even with the addition of github emojis).
I often have to remind myself of this. It's easy for me to just see the code and ignore the person. It's not easy to exercise empathy. It's something I'm trying to make a conscious effort to improve. I try to add levity when things get tense. I try to be objective. I try to ask questions about the motivations of certain things instead of just disagreeing with the code outright. I've sometimes even asked other developers to meet in person or over video chat to discuss a code change because I think things are getting too heated in the code review.
I also try to extend this empathy to software I use. With open-source projects I always try to keep in mind that I'm not the only person who uses this software, and my bug or feature requests probably isn't the top priority. I try to contribute instead of just reporting. I try to give the maintainers context so that they can understand where I'm coming from.
This isn't to say that you should be a pushover. Empathy isn't just about understanding someone else's feelings, but also your own. You need to have empathy towards yourself. If someone comes to you with a critical bug and you feel bad for them but you've just finished working 10 hours and you need food and rest - they can wait. Balance is so important. If you keep putting others before yourself then it will eventually backfire. You're no good to others if you burn out. Conversely, if you never take anyone else's feelings into consideration then it becomes much more difficult to grow as a person.
So, I guess my point here is that as you interact with others over the medium of text, emojis, and occasional gifs is to remember that there is another person on the other end. Sometimes it's not just about the code.