Back Empathy in Code Reviews
Empathy will define the great companies of the future that have truly figured out how to fulfill the needs of our diverse world. These companies of the future will have diverse work forces across gender, race, and ethnicity creating technology. They’ve realized that engineering with empathy can create happier and more productive teams, lead to better products, and create a culture of belonging where diverse team members can thrive.
Empathy is something that can be taught, and learned through daily practice. Even though most engineers focus solely on growing their technical skills, I think empathy can be one of the most valuable skills in your engineering toolkit. Engineers are constantly giving each other and other team members feedback and attempting to collaborate on projects, yet they usually aren’t encouraged to learn empathy. I’m here to change that, and today I want to focus on how we can really use empathy in code reviews to empower greater collaboration and productive discussions.
First let’s take a step back and define empathy. Brene Brown, a shame and vulnerability researcher, defines empathy as being made up of four components:
● Being able to see the world as others see it
● Being non judgemental
● Understanding another person’s feelings
● Being able to communicate your understanding of that person’s feelings back to them
Let’s see how each of these can be applied to code reviews.
Being able to see the world as others see it
What would happen if you started every code review with the following thought of positive intent: “My coworker who wrote this code tried their hardest and they have valid reasons for the way they wrote their code. It’s my role to be curious, ask questions, and share my knowledge and opinions with my colleagues. This is not a question of me being right and my coworker being wrong -- it’s a collaborative discussion and conversation to produce the best possible code and solution for our customers.”
A lot of the time we go into code reviews without this mindset, and unfortunately end up with less than ideal outcomes. However, if you really focus on a mindset of empathy, you can give constructive feedback in a way that can grow your coworkers instead of tearing them down.
Being Non Judgemental
Imagine getting the following code review:
“ anybody who thinks that the above is
(b) efficient (even with the magical compiler support)
(c) particularly safe
is just incompetent and out to lunch.” (http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html)
This was a rant by Linus Torvald and one of the more “polite” portions of his review. This is an extreme example of course, but I’m using it to make a point. When providing feedback, you need to take time to review it and ensure your language doesn’t sound judgemental. Make sure you are providing suggestions instead of giving orders. Remember that text can have a negative bias, so take a moment to reflect on the language you use in code reviews.
Understanding another person’s feelings
How many of you have ever gotten a code review comment that started with “Why didn’t you …”? For example: “Why didn’t you just remove this variable xyz?” Have you ever felt good being on the receiving end of a sentence starting with that phrase? Yet, it’s a common pattern I see engineers fall into. This is just one example, but what if instead you rephrase the question to be more curious and empathetic. “I don’t see the variable xyz being used elsewhere in the code. Should it be removed?”
Empathy isn’t just for the code reviewer though -- it’s on the requestor as well. I know this is a common feeling -- you’re finally done coding a feature and think you’ve fixed all the bugs, and you just want to commit it so you can get to solving the next exciting project on the list. However, remember your code reviewers weren’t on that coding journey with you and they need context about what you are trying to solve and how you are trying to solve it. Make sure you are leaving links to PRDs and architecture documents. Think of it as a fact gathering mission -- if in a year you had to go back and fix a bug in this code or someone else had to, what information would they need to be effective? Are there specific gotchas in the code that should be pointed out? Pull requests can become great artifacts for future history if created well.
Being able to communicate your understanding of that person’s feelings back to them
Sometimes a discussion should be had in person instead of as back and forth text in github. If a discussion has gone back and forth more than once in a review, especially if progress hasn’t been made, consider setting aside some time to talk in person about the code instead of continuing in text. When you meet in person to discuss the issue, again remember to phrase things from your point of view as an opinion. Take the time to listen to your colleague’s response and make sure to reflect back to them what you think you heard. This step does not mean you have to agree with what your colleague has to say -- you are just acknowledging that you understood what they said and heard them. Reflect on a time when a small disagreement turned into a huge issue, and afterwards you realized it was really just a miscommunication? By taking the time to make sure you are truly listening and reflecting other’s thoughts and feelings back to them, your colleagues will feel more listened to, and you will be able to provide constructive feedback.
These are just a few of many tips and tricks to adding empathy to your code reviews. While I focused on code reviews, you can apply a lot of these ideas to all of your communication. Empathy is something you build on a daily basis with practice, so think about how you can add one thing you learned from this article to your daily code reviews. It takes practice, and you won’t always feel you succeeded, but with a focus on empathy we can create the truly inclusive workplaces we need to really solve the challenges of a diverse world.