No More Excuses: The Power of Code Review

A lot of development teams I’ve interacted with over the years haven’t taken code reviews seriously. The code review process is one of the most effective tools I’ve found to level up a team. Below are the top four excuses I hear for not being attentive to the process and why you shouldn’t let your team subscribe to the same nonsense.

Over the years, I’ve done a lot of experimenting trying to figure out how to help my projects and teams run smoothly and efficiently. The resulting bag of tricks gives me a strong arsenal from which I can pull, but not every trick in my bag is applicable to every organization, team, or project — except for one. The code review.

I’ve been invited into dozens of teams, but more often than not I’ve found a lack of commitment to the code review process, whether it was treated as a pointless formality or forsaken altogether. While it’s always disappointing to see, as a consultant, it’s low-hanging fruit that makes me salivate because I immediately know I’m going to be able to earn my keep and radically transform this team and project.

That’s a powerful statement, and it might lead you to wonder,

“If it’s that powerful, why doesn’t everyone do it?”

There seem to be a few common “excuses” amongst the teams that don’t put any effort into code reviews:

• There’s not enough time
• The conversations become contentious
• No one participates
• They don’t add any value

If you’re reading this, perhaps you, someone on your team, or both have used or subscribed to one of these excuses. Let’s break each of them down and dispel the negative narrative so we can banish these for good.

Excuse One: There’s Not Enough Time

Teams always need more velocity, and it seems most teams tend to underestimate the effort required to complete large projects. Tossing a production bug into the mix is a bit like throwing a grenade right into the middle of the scrum board. So we end up burning the midnight oil while praying for an 11th-hour miracle so we can release on time. There’s no time for this pesky code review I speak of, right?

Code reviews make every member of the team better, stronger, more skilled developers through the knowledge share and coaching that happens as part of the process. The overall velocity of the team trends upward over time because your less experienced developers are getting feedback on every line of code they write, while your more seasoned developers are getting to see different approaches to solving complex problems, and being exposed to parts of the codebase they otherwise wouldn’t have any knowledge of. Sizing the tasks becomes a lot easier and more accurate because of this knowledge sharing that organically happens during the code review process. We’ve now effectively created a cycle in which the developer is getting better and has more exposure to the codebase on a daily basis. The result is a better codebase and better developers. It’s a win-win!

Excuse Two: The Conversations Become Contentious

We software engineers can be prideful, opinionated individuals. The most important thing to recognize and preach is that there’s no room for ego in the code review process. Everyone, no matter their tenure and skill level, can learn something from engaging in the process. This simple rule ends up cascading throughout the team culture and fosters a supportive environment that helps each member of the team grow on a daily basis.

Excuse Three: No One Participates

There’s nothing more frustrating than seeing a pull request sit there for days on end, which can ultimately lead to some pretty frustrating merge conflicts, or worse, the subsequent creation of functionality that doesn’t play nicely with that in the pull request. The bad news is that this comes down to team culture. The good news is that it’s easy to fix. Sit down with your team, explain the benefits and goals, outline the expectations and roles each team member plays as part of the process, and commit to the process as a team. The burden of holding the team accountable to the process doesn’t fall on any one person. It’s the responsibility of the entire team to facilitate this process.

Excuse Four: Code Reviews Don’t Add Any Value

Time for some tough love. If this is the stance you or your team takes, you’re doing it wrong. It’s that simple. We’d be here all day if I tried to list all the ways teams get the code review process wrong. Instead, I’m going to give you some quick tips that you can take and put into action with your team today. (And look for deep dives into some of these topics in upcoming articles.)

• No egos, no arguing, be helpful, learn and help others learn
• Tech leads should be on every code review, and their signature should be required to merge all pull requests
• A total of two signatures should be required on every pull request
• Post the link to pull requests into a common chat channel
• Everyone on the team should participate
• No one is ever “too deep in the code” to take a few minutes to look over a pull request
• Keep pull requests small, which can be facilitated through better task management
• Create a “code review playbook” that includes a list of things to keep an eye out for and that clearly documents your team or organizations code style rules (be sure to couple this with lint rules and auto-formatting)

Newton’s first law of motion says, “objects in motion tend to stay in motion”. Sometimes the hardest part of the process is simply getting started. Make the effort to get a solid code review process in place, and the rest tends to take care of itself. I’ve had so many developers come back to me months later with a completely different attitude toward the code review process, even the worst of skeptics.

If you want to see a dynamic and quick shift in the culture and velocity of your team, this is the easiest and most fruitful first step to radically transforming your team and creating an environment that fosters growth. The best time to plant a tree is 20 years ago. The second-best time is today.

This article originally appeared on the Rural Sourcing blog, where I am a Principal Consultant and the Web Practice Lead for our Augusta, GA dev center.