Code Reviews

4 minute read

How can you improve your team’s productivity with code reviews?

There are quite a few things in life that you only truly see the importance after experiencing, and code reviews are definitely one of those. By talking to my colleagues who apply it frequently in their workflow I could see that it improves a lot the efficiency of the team, but at the same time, talking with the colleagues who had never used it before (including me) it’s hard to identify the value of this tool.

In a code review, basically, after a developer finishes writing a new piece of code (it can be a new feature, a bug fix, anything), another developer checks the code and covers some questions that may vary according to the company’s standards. A few examples are:

  • Can the logic of the code be improved? Does it cover all cases proposed?
  • Are all requirements implemented?
  • Does the new code conform with the company’s guidelines?
  • Are the tests enough for the new code or do they need to be modified?

Well, clearly there are benefits, and lots of them. So it might be good giving it a try and evaluate if it suits the team’s needs and if it fits their style style.

How to begin

The first step, in my opinion, should be proposing it to the team. In this moment, the benefits of this practice can be explained to the team, such as:

  • It facilitates knowledge across everyone in the team, which means that all members know what’s going on with the code base.
  • Helps to establish or reinforce coding standards.
  • It’s a wonderful tool to onboard new developers. By having their code reviewed, new developers can learn quickly about the guidelines, and easily adapt in conversations regarding the code. Also, by reviewing veteran’s, new developers can contribute with a fresh pair of eyes, which often helps a team to tackle a problem in a different way.
  • Code reviews produce software with fewer defects.
  • Ensures that necessary documentation is being written.

The time issue

Some of the most popular counterargument used by developers new to code reviews are the time spent to do it. Indeed, it’s an additional step into the development process, which means it takes some time. But it’s not time wasted and there are some ways to make sure it’s optimised.

  • Review before merging. Sounds a bit obvious, but it can help discover mistakes and improve the code before it reaches the development branch.
  • Set an appropriate timeframe to perform the reviews. Eg.: no more then one hour.

Now, when it comes to introducing this practice into the development process, there are is a key aspect that may help: starting slowly. Sometimes, working in a fast paced environment, means thats one needs to be very thoughtful in this part, because the introduction of a new step might be slow in the beginning.

It can be useful to begin by implementing pull requests after small tasks were done, just to get the hang of it, and after some time evolve into reviewing bigger tasks until the point where the whole team is comfortable with it, in which reviews can be performed for every new code written for production.

A few tips to take the most out of code reviews

  • Begin the review with a fresh mind and without any expectations on what the code should be like.
  • Review your own code before submitting it to review. It may sound as basic advice, but you may find some things to improve.
  • If there are special places where you want feedback, make them explicit.
  • In case there’s something not very clear, ask questions to the author.
  • Explain why there’s room for improvement in the code reviewed and if possible, propose a solution.


Code reviews are relatively simple to include in the workflow, and can greatly improve software quality.

Depending on your team, it can good fit, and although it may bring some changes in the process, the benefits for sure outweigh the cost of adaptation.

It is something that combines technical and non-technical skills, and, as most of things in life, the more you do it, the more you get better at it. It is super important to be open to feedback and being able to offer proper feedback as well.

What are your thoughts on this? Do you do code reviews in your team?