Skip to content

Aquent | DEV6

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Save time and money. Start doing code reviews now.

Written by: Rod Nolan

The team I’m currently working with is a well-oiled machine and the project is a lot of fun to work on. Our team consists of a healthy mix of senior and junior developers and one of our most valuable practices is doing code reviews. Teams I’ve worked with in the past have occasionally done informal code reviews when the obvious need arose (i.e. when bugs were discovered) but it was reactionary. My current team (indeed, the entire organization) takes a proactive approach. The code review process is used as a preventive measure and it is so deeply entrenched that no pull request can be merged until it is reviewed by at least one other developer. And that’s a good thing.

What is a code review?

A code review is a process whose ultimate goal is to increase code quality and decrease bugs. My current client uses Git for version control, so all code makes its way into the master branch via Pull Requests. Every addition and every deletion sits out in the open for everyone to see and critique. In GitHub, reviewers use the Pull Request page to comment on any and every line of code, including those that weren’t modified in the current PR. Comments can take many forms ranging from simple questions meant to clarify the author’s intentions to gentle suggestions (or direct demands) for specific code changes. Each comment spawns a conversation between the reviewer(s) and the author. Code with outstanding questions/concerns remains on the sidelines until all concerns have been addressed. Reviewers only approve the pull request when all conversations have been resolved.

Who should review code?

The short answer is, anyone but the person who wrote it, provided they have the knowledge needed to understand the code. When the team’s mix of senior and junior developers tips toward the junior side, the responsibility for reviewing the senior’s code falls to the juniors. The prospect of reviewing code written by a more experienced developer might make a junior developer feel somewhat uneasy but there are benefits to be had by both parties.

Junior developers can learn a lot about common patterns and techniques used by the team/organization. And, as a senior developer, I have often benefited from being questioned and challenged by junior developers with a fresh perspective. The simple act of explaining my rationale has led me to implement improvements during the review session. The key to making the process work to everyone’s benefit is to instill a sense of fearlessness in all team members. When everyone understands that no one is above scrutiny and that there are no dumb questions, everyone wins.

To ensure that everyone, including senior developers, gets a second set of eyes on their code, repositories can be configured so that PRs can’t be approved by the original author.

How much time should be spent on code reviews?

The time required to review code grows in direct proportion to the size of the PR. Small PRs are best because they contain fewer changes. I also encourage my team mates to tend toward frequent, small commits rather than fewer, larger commits and to use descriptive commit messages. This approach can give the reviewer the context required to understand the changes without having to engage the author.

Regardless of the complexity factor, the process will become more streamlined as the team gains experience. I recommend giving the team time, and trust that their speed will increase with experience. If the process catches and fixes bugs early, before they make it into a release, it will be time well spent. The cost of fixing production bugs is far greater than the cost of preventing them in the first place.


All team members can and should participate in code reviews, regardless of their experience level. As the team matures, the process becomes faster. When executed regularly and correctly, code reviews produce better code with fewer bugs. Reviews require more time in the team’s early days, but that time pays for itself multiple times over because bugs are detected and corrected earlier. If you’re not currently conducting code reviews, ask yourself why? There’s really no downside.