Code Reviews: Balancing Speed and Precision for More Successful Deployments
You’re in the zone. The code is flowing. Then—bam. In the background of the stellar programming music playlist you’ve got on, you think you hear the clickety-click of a Slack message. And, of course, it’s the one thing you don’t want to see right now.
“Hey! Are you available for a code review?”
Code reviews are a crucial part of a software development process, but they can also be the most time-consuming, especially for dev teams that are already stretched. Sitting at your desk for three hours at the end of the day, painstakingly trying to review 1,000 lines of code (LOC), isn’t the best use of your time.
So, what’s the solution? Well, 31% of devs say they actually want to do more code reviews. But there’s a difference between checklist reviews and a genuinely valuable process that gets you to LGTM faster.
So, what does an efficient process look like?
The Classic Code Review Process
We can boil down code review to just six words: fix it now or delete it. In reality, though, it’s never that simple.
Your job as a code reviewer is to check for functionality, complexity, and style aspects (such as consistent naming conventions.) The author’s job is to make sure all reviewers understand the context of the changes and how they will affect the codebase.
While the fundamentals of a code review are the same in any dev team, no two teams will conduct a code review in the same way.
For some organizations, even the concept of a “code review process” is far removed from the way things actually work. This may look like the code author casually asking for permission to merge, nobody objecting, and, bingo, bugs galore.
Generally, though, the code review process might look something like this:
- The author submits a pull request (PR), providing context to the changes.
- Reviewers are assigned.
- They read the code and submit feedback/suggestions.
- The author follows up and makes changes.
- When the author has reviewed and implemented feedback, merge.
Informal code reviews for more trivial changes might happen via Slack back-and-forths or a short pair program session, while more significant changes will likely require a more coordinated process.
However, even teams with a code review process that is (more or less) followed can experience bottlenecks. And that’s because traditional code reviews, like the above example, aren’t particularly efficient.
According to Microsoft research, the median time between submitting a PR and implementing all changes is 24 hours, but they note that some reviews can take days or weeks. Individual contributors might spend six hours reviewing code in an average week—that’s a lot of time not writing code.
So, there’s a natural incentive for everyone in the engineering team—junior devs to project leads—to ensure the code review process is as quick and painless as possible. That way, you’ll find bugs faster (happy dev team) and increase your deployment frequency (happy managers).
Where do Slow Downs Arise?
In any project, there’ll be friction between those who just want to get on with writing code and the nitpickers who need to ensure that every single LOC is accurate.
Maybe the nitpickers submit PRs of a, frankly, ridiculous size, or when acting as a reviewer, spend too much time adding passive-aggressive comments (“Have you considered doing it my way?”).
The challenge for dev teams is to balance the need for comprehensive code reviews—which successfully find and correct defects—with limiting stoppage time in code writing as much as possible.
Whenever an author waits for devs to review their code, that’s dead time. Likewise, too many PRs (each containing perhaps 500+ LOC) can be overwhelming for devs, drawing them away from critical work for hours.
But the longer the delay between the PR and receiving feedback, the harder it is for the code author to return to where they were and implement changes without re-reading everything to recall their own work.
This can become a sort of never-ending code review nightmare: you’re yanked from a critical task to review code, and your delays will inevitably delay someone else. Then, the longer you spend on the code review, the more defects you’ll find, further delaying your return to the original task.
Most devs agree that inefficient code reviews are a likely factor in delaying software deployment. In that case, you’re probably struggling with one (or more) of the following issues in your code review process:
- PRs are too large.
- PRs lack context.
- Reviewers don’t provide feedback quickly enough.
- Feedback isn’t relevant or doesn’t prompt a change.
- Your code review process isn’t transparent, making it harder for reviewers to understand the context.
And if you haven’t got a formal code review process already, now’s the time to implement one. 82% of dev teams who are satisfied with their code reviews have formal guidelines, including clearly defined responsibilities and checklists.
How to Optimize the Code Review Process
There’s really no one-size-fits-all approach to code reviews. The process that works for you might depend on where your dev team is based and how many people you’ve got working on a particular project.
However, there are best practices that you can draw upon; Google has extensive code review guidelines that are worth looking at.
Once you have a code review process, below are our suggestions for fully optimizing to make it as painless as possible for all involved and achieve the ultimate goal of better code merged to main, faster.
Pre-Code Review
In a study of code review practices at Cisco, researchers found that when PR authors added annotations to their code reviews before reviewers examined them, the number of defects in the code was lower (and, in some cases, zero).
Authors who reread their own code before submitting a PR aren’t just more likely to find bugs. It’ll also improve the code review process by limiting the time reviewers might spend getting to grips with changes or asking for clarification, reducing the overall review time.
Pull Requests
PR authors: take note. An ideal pull request description isn’t a quick, two-sentence breakdown of what you did, and neither is it a lengthy, novel-worthy explanation of the file’s history and your heroic work.
Simplistically, a pull request contains two critical pieces of information:
- What change did you make?
- Why did you make that change?
However, additional context and explanation is highly beneficial (see this example), especially if your reviewers are unfamiliar with the file or a feature of the codebase. After reading your PR, they should have all the information necessary to review your code and give constructive feedback.
If you’re unable to describe your change succinctly, chances are your PRs are too big. Smaller diffs (ideally up to 200 LOC) are easier to review and reduce the risk of reviewers missing defects.
Providing Feedback
When a PR comes through, authors don’t ask you to drop everything, leave your issue half-finished, and immediately start your review. However, building an efficient code review process requires everyone to understand that faster is better.
So, if you really don’t have time at this precise moment, wait for a natural break in your work pattern to reduce context switching. Ideally, you shouldn’t review for longer than 60 minutes anyway, as your focus wanes.
For this reason, many developers schedule blocks for code review to keep them focused on tasks. This also saves code authors from the pain of waiting hours for feedback only to realize a reviewer has been in ‘focus mode - DND!!!’ all morning.
As we’ve already mentioned, passive-aggressive or nitpicky feedback isn’t helpful for anyone, even if your underlying intention is to improve the code quality. If you still want to leave a non-urgent suggestion, preface it with nit: so the author knows they can return to it later or choose not to accept it.
It’s also important to remember that anyone can make mistakes, even a senior-senior dev who’s worked for prestigious software companies (and likes to believe they don’t). Honest feedback helps everyone improve, including other devs.
Likewise, positive feedback is as welcome as negative feedback, even if it’s not strictly about improving the code. Code reviews are also a lesson in collaboration and mentorship, helping junior developers learn faster.
Implementing Changes
The ultimate responsibility for implementing changes lies with the PR author. As an individual contributor, you shouldn’t really be doing extensive rewrites just to understand a portion of the code. If this does happen, there’s a chance the PR was too complex in the first place.
As the PR author, you’ll generally be responsible for merging the PR unless these responsibilities have been assigned to others as part of your code review process. If there’s any confusion about this, it’s a sign that your process isn’t as straightforward as it should be and is probably contributing to bottlenecks in getting code approved. Talk to your team about it.
Evaluating Your Process
Since there’s no universal agreement on the code review process, it’s pretty likely that each of your devs has experienced different ways of conducting code reviews. So, understanding the metrics you’re using to evaluate the code review process is essential.
A common metric to start with is Time to Merge (TTM), measuring the time it takes from the PR request submission to merge. If you’re actively working on streamlining your code review process (…and hopefully you are if you’re reading this…), then you should see this value fall.
Other metrics include the defect density or reviewer load (how many open PRs each reviewer has). Whichever metrics you choose to track will only give you a part of the whole picture; code reviews are collaborative processes, and only with open and honest communication within your dev team will you actually accomplish any improvement in the process.
Squire AI: Making Manual Code Reviews a Thing of the Past
Code reviews have been a staple of the software engineering process for decades, and unless we all decide to give our jobs over to the robots tomorrow (I’m sure they’ll love that), they’re not going anywhere, either.
An inefficient code review process can seriously inhibit your ability to push changes out and will undoubtedly impact your team’s overall quality control and speed.
But you don’t have to do everything manually.
It’s why we built Squire AI: a context aware agent who works with you to write pull request descriptions, review PRs, and matches how you like your code reviewed.
Squire can standardize your code review process with AI-generated PR descriptions that are contextual and descriptive, making it easy for you to get up to speed and start reviewing code.
And, with a complete understanding of your codebase and style, Squire can conduct code reviews for you, saving you precious coding time.
Interested in discovering how an AI agent like Squire can help optimize your code review process? You can get started for free right now:
