The Importance of Being a Code Reviewer

Code reviews are something from the past. In an agile world we use TDD to write the code and the test in one swoop, ideally in a pair programming setting so another set of eyes has already validated the code. Furthermore, the CI pipeline has proved that there is no interferences with other parts of the codebase and a linter has ensured that we have written our code to the standards that we have agreed upon. So why not just merge and deploy to production without the extra manual labour step of a code review?

The code review process for me is most of all a knowledge sharing mechanism. This goes beyond understanding how the given problem (in the form of a ticket) has been solved, but also gives a deep look inside into the author’s ways of thinking and organizing a problem. It also provides a learning opportunity within the language and framework that is used in the team, maybe some quirks have been used in the code that you are reviewing that you don’t know about yet? Furthermore, as an engineer, you can:

• Understand a new codebase faster
• Do networking (not talking about TCP/IP here), especially if teams are geographically distant
• Find potential overlapping and duplication in work
• Enforce best practices in the codebase
• Strengthen your communication skills
• Make friends!

How to do all of these? It’s all about how you give feedback about the piece of code that you are looking at.

The effectiveness of a code review hinges on the quality of the feedback provided. Effective feedback is not just about pointing out mistakes; it’s about providing constructive suggestions for improvement. It’s about focusing on the code, not the person, and approaching the process with empathy and understanding.

Here are some tips for giving effective feedback during code review sessions, but as you know, this also applies to giving feedback in general: Focus on the code, not the person: Separate the code from the developer. Avoid making personal attacks or criticizing the developer’s skills. Be specific and actionable: Provide concrete examples and suggestions for improvement. Instead of saying “This code is inefficient,” explain why it’s inefficient and suggest a more efficient approach.

• Be respectful and constructive: Acknowledge the developer’s efforts and approach the feedback with a positive attitude. Avoid being condescending or dismissive.
• Consider the context: Understand the purpose of the code and the constraints under which it was written. Don’t suggest unrealistic or impractical changes.
• Encourage open dialogue: Create an environment where developers feel comfortable asking questions and seeking clarification.
• Take your time and see it as an investment into growing and learning from each other

Especially for the relationship between more junior and more senior developers, code reviews pose an excellent platform for mentoring and teaching.