Photo by NESA by Makers on Unsplash

Plenty of articles have been published here, and here, and also here as to why code reviews are great. I’m not going to repeat that. Instead, I’m going to share what I think are reasons engineers and project managers may be opposed to code reviews and why they should embrace it instead.


Often times, introducing a code review process to a software organization triggers a wide range of emotions among individuals.

There’s the ones who’ve had positive experiences in the past. These are your supporters and for the sake of this article, we’ll assume they’re on board and support the initiative.

Then, there’s the ones who’ve either had negative experiences or no experiences at all. Let’s look at each role individually and see what might go through their mind and how we can implement a code review process that works well.

The engineer: “No time, I’m busy writing code”

The situation

Engineers are busy, very busy bees flying all over the code adding new features, fixing bugs, or taking care of technical debt.

The assumption

Adding yet another task, reviewing someone else’s code, is simply too much to deal with. More tasks equals to less coding, hence fewer new features and fewer releases. Also, there’s less time to fix bugs or improve code quality.

The facts

When an engineer asks a team member for a code review, what she really asks for is a favour, a favour for someone else to learn about her code. This takes pressure off her shoulders because at least one other team member is able to answer questions or fix bugs related to that code.

Equally, if not more important though, she’s asking for another favour, a favour to get feedback on her code, to learn what other approaches might be possible, to improve her skills and become a more experienced developer.

Over time, this leads to better, more maintainable code that can be worked on by a number of people without the need for a so called “knowledge transfer”. This topic is worth a post in itself…

The sooner someone’s code gets reviewed, the sooner that engineer can move on and work on new code, applying what she learned in her last code review and hence, write more solid code. Over time, code reviews will take minimal effort and help everyone to level up.

The project manager: “We have no time allocated for that”

The situation

None of the companies I’m aware of takes code reviews into account when estimating a project’s total effort.

The assumption

Given that situation, it is a PM’s natural reaction to worry. To develop a feature, we suddenly require at least two engineers, more communication, more context switching and oh boy, there’s no budget for any of that.

The facts

As a project manager, there’s no need to worry. There’s not even a need to do anything about code reviews.

A well organized engineering team deals with code reviews so well, a project manager doesn’t even notice it’s happening.

What a project manager does notice in the long term though is the reduced number of bugs, fewer refactoring tasks and smaller technical debt.

How to roll out code reviews

In order to implement a code review process that runs as smooth as butter, a few things have to happen:

1. Find the “code review leads”

Most importantly, code reviews are not a “one fits all” solution. Every company has their own tools and workflows already in place; code reviews are an extension of that.

What has worked well for me is to find “code review leads”, a group of engineers from each team. This ensures all varieties of workflows can be taken into account in the next step.

2. Define the process

This phase is where the code review leads meet, discuss and document the code review process. What? Why? How?

Maybe a team or two trials the process and provides feedback before the next step.

3. Education

It’s important to educate everyone. This includes engineers, QA and PMs. You could even consider to invite HR so they can update a job description’s “What you’ll be doing” section and talk to candidates about code reviews.

4. Practise and refine

Keep a recurring code review leads meeting for a while to check in with the group. If there are problems or new scenarios, discuss it and update the documentation accordingly.