As a software engineering manager I believe that my main goal is to ship code. Shipped code falls into 2 categories: features and improvements.

When talking to The Business™ it’s easy to believe that they only care about the first type. And in a sense it is the most important type, how else will they be able to attract more leads, close those sales.

The faster you get to shipping, the better.

Often this pressure is not active, nor apparent. More like a cloud hanging on top of your development team’s operations, gently nudging you to finish what was started quickly before it develops into a storm^[1].

You’ll be tempted and encouraged to cut some corners. One of those corners being code reviews.

Code reviews at their core, are the process of letting a peer look at the changes you made to the code. Usually with the intention of making sure that it does what it’s supposed to do. Under that light, the review aims to be a sort of quality assurance work.

So why not let the QA team just test the feature instead?

First of all it’s of course more than just a test of the work from the functional point of view. In a code review the reviewer will make sure the the implementation is sane but it also enables so much more: builds shared knowledge and ownership of the codebase, it establishes trust within the team, and reinforces habits that produce high quality code.

Shared knowledge

When a feature requires implementing new technologies or techniques, it’s often impossible to get the entire teams to be part of building the solution. Code review is a way to ensure other team members are aware of these changes, this avoids knowledge silos.

Another type of knowledge that’s transferred in an code review is when a senior developer reviews a junior’s work. In this case the junior developer can learn how to write better code and often will be made seated of edge cases and scenarios they didn’t think of.

This builds your team into a more resilient group that can afford to have members take vacations without completely grinding to a halt.

Establishes Trust Within the Team

Code reviews sound like nitpicking your team mate’s work, but by having well established rules on politeness and disagreement resolution heuristics the team will begin to better know each other’s strengths and weaknesses. Refocusing the reviews as a way to build on the strengths and reinforcing the weaknesses the team starts to develop an internal trust that’s really important.

Reinforces Habits That Produce High Quality Code

Nobody likes to be nagged. When a team starts doing code reviews it is highly likely that each team member will start getting the same comments about their code on each review. That’s because their weaknesses are being pointed out, but that repetition with time helps the developer to make the necessary adjustments to stop getting those types of comments.

In the real world, where legacy code and tech debt exist, code quality can feel a bit like polishing a turd. But the alternative of a complete rewrite is often impossible. So slow and methodical progress towards a shinier future is the best compromise.

Establishing the values that define high quality code within the team is the first step, focus on readability, architecture/structure, logic, performance, and security. Using code reviews to reinforce these values will slowly but surely make the software easier to understand and maintain, which means development will become more efficient and will reduce rework.

So if you are to adopt code reviews, don’t do it halfheartedly.

Establish a process that’s easy to follow, focus the team on the values that you care about the most. Avoid any focusing on persnickety things like l tabs vs spaces, letter casing, preferred syntax style, etc. Offload those to automated tools.

Adopting code reviews but treating them like a rubber stamp is the worst option. You assume the delays and distractions that come from context switching without any of the benefits.

Hopefully your The Business™ understands why it’s important.^[2]

Here’s a funny image of code being rubber stamped because why not?