This article was originally posted on Daniel Westheide's blog.
In 1999, Andrew Hunt and Dave Thomas, in their seminal book, demanded that programmers be pragmatic. Ten years later, Chad Fowler, in his excellent book on career development, asked programmers to be passionate. Even today, I still consider a lot of the advice in both of these books to be incredibly valuable, especially Fowler's book that helped me a lot, personally.
Nevertheless, in recent years, I have witnessed again and again that one other quality in programmers is at least as important and that it hasn't even seen a fraction of the attention it deserves. The programmer we should all strive to be is the empathic programmer. Of course, I am not the only one, let alone the first one, to realize that. For starters, in my bubble, Benjamin Reitzimmer wrote an excellent post about what he considers to be important qualities of a mature developer a while ago, and empathy is one of them. I consider a lack of empathy to be the root cause for some of the biggest problems in our industry and in the tech community. In this post, I want to share some observations on how a lack of empathy leads to problems. Consider it a call to strive for more empathy.
So what is empathy? Here is a definition from Merriam-Webster:
the action of understanding, being aware of, being sensitive to, and vicariously experiencing the feelings, thoughts, and experience of another of either the past or present without having the feelings, thoughts, and experience fully communicated in an objectively explicit manner; also: the capacity for this
Empathy at the workplace
It shouldn't come as a surprise that the ability to show empathy can come in handy in any kind of job that involves working with other people, including the job as a programmer. This is true even if you work remotely – the other messages you see in your Slack channels are not all coming from bots. There are actual human beings behind them.
One of the situations where we often forget to think about that is code reviews. Just writing down what is wrong with a pull request without thinking about tone can easily lead to the creator of the pull request feeling personally offended. April Wensel has some good advice on code reviews. What's crucial is to develop some sensitivity for how your words will be perceived by the receiver, which requires to put yourself into their shoes, see through their eyes and reflect how they will feel. This is easier the better you know the person, otherwise you will have to make some assumptions, but I think that's still far better than not reflecting at all on how the other person will feel.
Another workplace situation where I have often seen a lack of empathy is when members of two different teams need to collaborate to solve a problem or get a feature done. In some companies, I have seen an odd, competitive "us versus them" attitude between teams. This phenomenon has been explored by social and evolutionary psychologists, and while such a behaviour might still be in our nature, that doesn't mean that we cannot try to overcome it. A variant of "us versus them" is "developers versus managers". We developers have a hard time understanding why managers do what they do, but frankly, often, we don't try very hard. I have often seen developers taking on a very defensive stance against managers, and of course, the relationship between managers and developers in these cases was rather chilly. Getting to know "the other side" would certainly help to empathize with managers. Understanding why they act in a specific way is absolutely necessary in order to get to a healthy relationship with them.
Empathy in the tech community
Empathy is not only important at your workplace, but also very much so when you are interacting with others in our community, be it on mailing lists, conferences, or when communicating with users of your open source library, or developers of an open source library you are using. In some of these situations, a lack of empathy can strengthen exclusion, ultimately leading to a closed community that is perceived as elitist and arrogant.
As a developer using an open source library, empathize with the developers of the library before you start complaining about a bug, or better yet, a missing feature. Sam Halliday wrote an interesting post called The Open Source Entitlement Complex. It's hard to believe, but apparently, many users of open source libraries have this attitude that the developers of these libraries are some kind of service provider, happily working for free to do exactly what you want. This is not how it works. The same way that wording and tone are important in code reviews, try to empathize with the developers who spend their free time on this library you use. Serving you and helping you out because you didn't read the documentation is probably not their highest priority in life, so don't treat them as if it is.
On the other hand, when presenting your open source library to potential users, consider how these people will feel about that presentation. Does it make them feel respected? Does it make them feel welcome? I am sorry to disappoint you, but I think that a foo bar "for reasonable people" does not have that effect. Personally, I find this to be very condescending and think it will intimidate a lot of people and turn them away. It implies that any other way than yours is not reasonable, and that, hence, people who have not used your library yet, but some different approach, are unreasonable people. As library authors, let's show some empathy as well towards our potential users. As always in tech, there is no silver bullet, and there are trade-offs. There are probably perfectly good reasons why someone has been using a different library so far, and maybe even after looking at your library, there will still be good reasons not to use yours. Even if you are convinced that your library is so much better, you aren't exactly creating an open and welcoming atmosphere by basically telling people visiting your project page that they are unreasonable for using anything else.
If you are at a tech conference, and you ask women whether they are developers at the very beginning of your conversation, but don't do the same with men, you are probably not doing that out of malignity, but because you don't see many women at tech conferences who are actually developers. Nevertheless, to the receiver, this seemingly harmless and neutral question doesn't come across like that at all. She has probably heard this question many times, and constantly hearing doubts about whether you are really a programmer doesn't exactly make you feel welcome, or confident. Show some empathy when you talk to other people at tech conferences. Imagine what it would be like to constantly be doubted, for example. If you don't see a need for being inclusive, that's probably because you had no problem being included in the community. This likely means that you are a man, and probably white. Since most people around you are like you, chances are you don't even know any women or other unprivileged people who are developers. The problem of being privileged is that you don't notice it. Talk to women on conferences and let them tell you about their experiences. By showing empathy, you can create a more welcoming environment of inclusion and foster diversity.
Summary
These are my two cents about empathy, and lack thereof, in the tech community, and how it relates to inclusion and diversity. Empathy is important not only at the workplace, when interacting with co-workers, but also when we are participating in the tech community, as conference visitors, open source developers, and users of open source libraries. Only by showing empathy, we can create an inclusive and open community. Let's try to be more aware of the effects we have on each other, and act accordingly. Thanks!
Top comments (3)
It would be a great title for the book, Daniel!
A book about this with that title is actually something I am seriously thinking about. :)
great read!
I believe being empathic goes beyond workplaces, conferences, etc.
It is a way of life a person needs to consciously choose upon to follow.