Code-review is not about avoiding bugs.
It’s about learning and sharing.
In the last few years of my career, I have been working for companies where code review is an important step of the delivery process. Some people love code review, while others find it tedious or unnecessary.
I believe that code review is essential for ensuring the quality and reliability of software. This text is not about proving any point, it is about sharing my thoughts about it and trying to convince you that code review is essential.
It’s about teaching and learning
Code-reviews has a different impact depending on the seniority of the team.
When working with a more junior engineer, code reviews can help to raise the bar and help your team to grow. Reviewing the code of a more junior engineer is about teaching them how to write better code and how to write code that others can read.
On the other hand, when working with a more senior engineer, the chances are that you’re going to learn. In general, senior engineers will not commit simple mistakes (or shouldn’t) choosing week names, forgetting silly tests or piling the code with code-smells. This is a good opportunity to learn and understand how others think and work to solve problems.
It’s about asking questions
When I write code, I always keep in mind the following thought: “Is this code clear enough? Will I understand this change a year from now?”. When you are working on a task, you are deep in the context and some details can be left behind.
When reviewing a code, you may not have all the context of the changes, which gives you a superpower: “Is this approach clear enough?”.
If the answer is “I dunno what’s happening here,” just ask the question. Review it without blaming yourself for not knowing everything, and that will certainly be seen as a positive thing and brings some positive outcomes for you.
Sometimes even the writer won’t know the answer either, and your question could save the project from future problems.
It’s not about being accountable
When you add the responsibility of avoiding bugs to code review, you create an entry obstacle: Why would a junior/mid-level engineer care about reviewing a pull request if they can be blamed for problems?
It’s clear that code review helps, and having another team member reviewing your code means you’re creating a more resilient solution. However, it’s important to remember that this is not the best tool to avoid problems. Writing automated tests, creating better documentation, sharing knowledge, doing whiteboards, and talking about code patterns and best practices are all examples of how code review is just one part of the process.
It’s about being wrong (and that’s ok)
I still remember my first pull request with over 100 comments. I was a back-end engineer centralizing a modal with a DIV tag in the front-end. You can imagine the mess.
Having comments about your work will hurt your ego in the beginning, and sometimes you will be sad about it. It’s all part of the process. Being a more senior engineer is about being able to have these kinds of discussions and opinions about your work, and knowing when you’ve “lost the battle.”
And the most essential part: It’s not a contest. Sometimes, teammates you not agree with your comments and that’s totally fine. Learn when losing a battle is better than extending an usuless discussion for days just to “win” it. Accept other people's opinions and don’t be a brilliant jerk.
I believe that the benefits of code review significantly outweigh the costs.
Code review is a powerful tool that can help to improve the quality and reliability of software. It can also help your team to grow, share knowledge, and create simple solutions.
