This is an edited version of an article I originally wrote for the First AML Product & Engineering blog.
Code reviews can be stressful for both parties. The person being reviewed puts their code out there for everyone to see and potentially judge. In contrast, 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
I thought there was no good solution to this problem for a long time, but then I came across an article on Feedback Ladders by the team at Netlify.
The gist of the article is that Nelify uses metaphorical names describing the inconveniences of living in a house still being built in their code reviews. This encodes the severity of the feedback.
Let’s start adapting
Netlify has 5 different levels - mountain, boulder, pebble, sand and dust.
I think this is overkill, and we can get away with just three - [boulder], [pebble] and [dust]. I feel it’s worth adding one more to indicate that it’s a clarifying question asked by the reviewer.
This is an improvement over the traditional review, but there is still a problem. Text is difficult to parse.
The solution is easy — Let’s use emoji.
We can use whatever emojis we like, but our platform of choice must support the emojis that we decide to use.
Some options that work in Github for inspiration
- Vehicles 🚑 [ambulance], 🚗 [car], 🚲 [cycle], ⛽ [fuelpump]
- Animals 🐘 [elephant], 🐑 [sheep], 🐜 [ant], ❓ [question]
- Shapes 🔴 [circle], 🔶 [diamond], 💚 [heart], ❓[question]
What level to use when
Let’s use Vehicles as an example and see what the different levels indicate.
🚑 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.
🚗 Non-Blocking but essential
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.
🚲 Take it or leave it
All those other things that are suggestions or a personal opinion and might be considered nitpicking. Examples of this would be suggesting a different variable name.
⛽ A clarifying question
It can be used to get more context on the pull request changes or understand 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, we can give suggestions without feeling as if we are being harsh. As the person whose code is being reviewed, we can concentrate on the feedback that matters.
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.
I am always curious to know how other people have adapted this in their workflow so let me know what you did :)
Top comments (0)