How we made our code reviews stress free

Code reviews can be stressful for both parties. The person being reviewed is putting their code out there for everyone to see and potentially judge, while the person reviewing feels the pressure to maintain quality without coming across as harsh.

There is a lot of advice on the interwebs about how to conduct effective code reviews. A lot of it is focused on avoiding nitpicking. It's good advice and has resulted in a cottage industry of automated tools to enforce code standards. However, computers are still not good at some things like suggesting good variable names. By only talking about blockers in a code review we can lose out on some good suggestions. It's a classic case of throwing out the baby with the bathwater.

Inspiration

For a long time, I thought there was no good solution to this problem but then I came across an article on Feedback Ladders by the team at Netlify. If you don't feel like reading the linked article, the gist is that they use metaphorical names describing the inconveniences of living in a house that is still being built (mountain, boulder, pebble, sand and dust) in their code reviews. This encodes the severity of the feedback.

Make it ours

We started by changing the number of levels and reduced it to [boulder], [pebble], [dust]. We added a new one for [question]. We are a small team and our code reviews involve asking a lot of clarifying questions.

There was still a problem though. They were difficult to parse.

The solution was easy — Let's use emoji.

But which ones

⛰️ [mountain] , 🥌 [curling stone] 💨[dash], ❓[question] is a good start. Uh oh, GitHub does not have 🥌. Back to the drawing board ☹️

This is also when the slack thread exploded and the team's personality started to shine through.

Some of the options we considered

Animals 🐘 [elephant], 🐑[sheep], 🐜[ant], ❓[question]
Vehicles 🚑[ambulance] 🚗[car] 🚲[cycle]⛽[fuelpump]
Shapes 🔴[circle]🔶[diamond]💚[heart]❓[question]

After a really serious and rigorous debate, we had a winner - animals.

There was one other change we made at a much later time. Someone mentioned how they love taking pictures of goats and we replaced the 🐑 with a 🐐. Baa Bye Sheep

What do the levels mean?

Elephant 🐘

Blocker. The Pull Request cannot be merged till the issue is addressed. Examples of this would be where the solution doesn't fix the issue or has unintended consequences or missing tests.

Goat 🐐

Non Blocking but important. The Pull Request can be merged but the comment should be addressed in a future PR. Examples of this would be addressing tech debt or enhancements.

Ant 🐜

Take it or leave it. For all those other things that are suggestion or a personal opinion and might be considered as nitpicking. Examples of this would be suggesting a different variable name.

Question❓

A clarifying question. Can be used to get more context on the changes in the review or to gain more understanding of the domain.

Conclusion

Code reviews can incite endless debates between developers. Using emojis to encode the severity of the feedback can help avoid this problem. As a reviewer, you can give suggestions without feeling as if you are being harsh. As the person whose code is being reviewed, you can concentrate on the feedback that matters i.e answer the questions, ignore the ants, address goats or create tickets for them in the backlog but discuss and address the elephants

If you plan to use this approach, make sure to add your personality to it. Remember there is no such thing as the only way.