Code reviews can be a huge source of learning and personal growth, for both the author and the reviewer. This is not just in terms of learning from and improving code that’s written, but also in the way that you can practice and actively improve your emotional intelligence and, through this, build better teams.

A key component of emotional intelligence is empathy. Empathy is defined as “the ability to sense other people’s emotions, coupled with the ability to imagine what someone else might be thinking or feeling". If we apply an empathetic mindset to code reviews, it can make them much more productive and worthwhile: it not only opens up space for the reviewer to initiate an honest discussion, but it also helps get the right kind of feedback you want (or need) as the author.

How we approach communication in code reviews is important because this ripples into other areas of our day-to-day teamwork as engineers. I’ll be going into this idea a bit more and how it feeds into "psychological safety" in teams, which I will explain below and give pointers on what we can do to achieve this.

How does empathy help us build a better team?

There are many articles written about what makes a great team. The one that has stood out to me the most is a bit of a long one, but a key point in it has stayed with me throughout my software engineering career. The article is What Google Learned From Its Quest to Find the Perfect Team by Charles Duhigg if you fancy a read over a cuppa. To summarise the most important part of it: Google put together a study of hundreds of their teams with the goal of finding out how to form the most effective team. This led to identifying five key dynamics, where "psychological safety was by far the most important”. You can also find the completed guide on team effectiveness by Google.

How I understand psychological safety is, in simple terms, feeling no fear to speak up, share ideas and bring your true self to work. In the original paper by Amy Edmondson, which first identified the concept of psychological safety, she describes it as "a shared belief that the team is safe for interpersonal risk taking" and "a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up. This confidence stems from mutual respect and trust among team members”. To get to this place, having empathy is a key behavioural aspect of creating psychological safety in a team.

In Edmondson's Tedx talk, she mentions three simple things that you can adopt to help create a psychologically safe environment. In my opinion, empathy underpins all three, and these points can be adopted in code reviews too. These are:

1. Frame the work as a learning problem, not an execution problem.
2. Acknowledge your own fallibility.
3. Model curiosity and ask lots of questions.

Frame the work as a learning problem, not an execution problem

We are all just at different stages of our learning journey. If you think about it, what you know about programming today boils down to a combination of what you've had a chance to work on (and read about) so far and your own memory and learning capabilities. Code reviews provide the perfect opportunity to learn from and grow with each other, rather than having code as purely a means to an end.

As the reviewer, if there's something you think could be done differently, first think about where they are coming from and why they've done it in such a way. Is there a time-constraint on this piece of work? Might they already know of a different solution and there's a reason they chose this one? Is there a way you can help them learn, maybe by not giving the full answer but rather asking questions around it? These kind of questions help frame the way that we empathetically communicate with each other, and therefore lead to more open conversations, where we can learn more from each other. A comment on a PR that just states the code is "wrong" is a great example of possibly valid feedback that will likely be poorly received due to the lack of empathy shown by the reviewer.

On the author's side, if there's something you're not sure about and would like feedback on, one way to empathise with the reviewers point of view is to simply point out these areas. You could leave a comment on the line(s) of code to be specific, or write a short description in the Pull Request, which explains where you think something could be improved. This helps the reviewer be more productive and focused in any feedback, and maybe you'll have answered questions that help them understand where you're coming from.

Acknowledge your own fallibility

Even the most experienced engineers can't know everything and will make mistakes along the way. No matter your level of experience, acknowledging the possibility of mistakes and what parts of the code you would most like to be reviewed gives space for others to know it's OK to get things wrong (isn't that how we really learn anyway?). I've personally found it very relieving to hear a more experienced engineer tell me about their past learning struggles. It makes others relatable and supports a growth mindset by bringing on thoughts like, "well if they've made lots of mistakes and have achieved so much where they are now, why can't I achieve all that too?".

If you're reviewing code of someone that is less experienced than you and notice a mistake, think about how you felt back then and what you'd like to hear in that position. Even if you aren't more experienced the same thought process should apply. It's less helpful to say something like "you should have done it this way", rather than something like "I've tripped up on this kind of thing a few times in the past because ... I think you could do it like this ... What do you think?". You'll find in a lot of code reviewing cases sharing mistakes won't be or feel like something that needs to be done, but being open to discussing your own mistakes makes room for others to feel comfortable about not holding back their own.

In Edmondson's paper, she writes, “most members of a team will conclude that making a mistake does not lead to rejection when they have had team experiences in which appreciation and interest are expressed in response to discussion of their own and others' mistakes”. Any opportunity to express that mistakes are more than OK is beneficial to growing an effective team.

Sometimes as an author you might feel like you don't need a code review (maybe it's really small or you're really confident on that kind of thing). But it's always good to be open for feedback and acknowledge that you could have missed something. And from the empathetic side of things, a less experienced engineer could learn from it!

Model curiosity and ask lots of questions

On both author and reviewer sides, there's a lot of context that gets missed. We don't always know if the author has struggled and faced many roadblocks to get to that point, and maybe they are really happy to have finally just got it working. If this is the case, receiving a blunt bit of criticism isn't going to be what they want to hear after all that hard work.

Of course feedback is essential in growth, so another way of bringing out improvements to be made is by asking questions around it and opening it up for discussion. Are you correct in thinking that it is wrong? Could you be missing something? As I mentioned in the section above, you could ask what they think about a different solution. Would they prefer to pair on it? Or do they want to tackle it again on their own because that's how they personally learn better? By framing feedback as a question, it gives them a chance to give any context that is missed, or to argue their point, rather than commanded to do things that may miss context. This can come across negatively (possibly even insulting), which could cause the author to disregard the reviewer’s other potentially valid points.

Then, as the author, you can ask yourself questions like: do the potential reviewers know enough about the feature to review my code in the way that I need? How busy are they? What can I do to make this PR easier to review? Can I keep this PR small? Or if it has to be a big PR, have I got clear commit messages? Providing more context in the PR description would be really useful, especially if you're getting reviews from other engineers who aren't working on the same project. You can also use this space to ask questions yourself, like "Can you think of a better solution for this?". This helps the reviewer know you are open to more critical feedback, and also helps continue to model curiosity from all angles in a team.

Raising the value of code reviews

Showing empathy through how you communicate in code reviews can lead to a more effective team because you're essentially showing each other that you care, and therefore helping to foster that all-important psychological safety in teams. By thinking about how you can all learn more (frame the work as a learning problem, not an execution problem), opening up to mistakes (acknowledge your own fallibility) and asking questions rather than making statements (model curiosity and ask lots of questions), you can get so much more value out of an area of the job that can often be overlooked.