Get your code reviewed faster with these tips

Solve your user's pain point faster by getting faster code reviews

As engineers, we’re paid to deliver value to business.

And one of the best ways to do that is by speeding up code reviews. Faster code review leads to faster deployment, which leads to solving customers' pain points sooner.

Even though code review is a small fraction of delivering value to business, a good engineering team should aim to achieve efficiency in even the smallest area.

The delay in code review doesn’t always happen due to slow reviewers but also due to the Pull Request(PR) author’s preparation and the team’s practices and processes.

In this post, I’ll provide effective strategies to speed up code reviews for engineering teams, PR authors and reviewers.

For the author:

1. Keep small and focused Pull Requests (PR)

   When I created PR for the first time, it was something like this:

   Files changed 25, +673 additions, -433 deletions, commits 1

   Not only the PR was huge, but I made the mistake of adding all changes in a monolith commit. I still remember the pain of having to revert the changes and commit them based on specific purposes at the tech lead’s request. But I learned an important lesson that day i.e., make PR small and focused.

   Aim for less than 200 lines of code per PR. If the change gets bigger, break it into multiple smaller PRs. Smaller PR are easier to review and revert if anything goes wrong.

2. Write a clear description with context

   A PR should have two sections at a minimum — Context (why is this change needed) and Change description (what’s the actual change). You can add how (to test) when applicable. Here’s the link to the ideal PR template by Ryan Peterman.

   The reviewer may not have any idea about the reason behind the change. So, the clearer the description you add, the faster the code can be reviewed.

3. Respond to feedback quickly and engage actively in discussions

   Aim to respond to the feedback within 2 hours during work hours to get code reviewed quickly. I made a mistake a lot in the past; creating a PR and hiding in the cave. Well, not actually hiding in the cave but moving to other tasks and forgetting about the PR.

   When you create a PR, it’s crucial to actively respond to the comments and resolve them ASAP.

4. Promote your PR for hot bug fixes

   Promoting your PR is a good idea to get it reviewed quicker, especially for a hotfix. You could drop a link to the PR in a relevant Slack channel, mention it on standup or directly message the reviewer.

   However, directly messaging reviewers too often could disrupt their flow (in case they’re doing deep work) and may annoy them. I usually prefer to wait for 4-6 hours max before I ping the reviewer.

For the reviewer:

1. Allocate time in your Calendar daily for code review

   You might be working on your task when a teammate requests for code review. It’s acceptable to delay code reviews (non-priority ones) when you’re in a flow state as context switching is expensive.

   I usually allocate 20 minutes in the morning and evening for code review. This scheduling helps me to preserve my deep work session and also avoid missing out on any PR from my sight.

2. Invite author for peer code review

   When reviewing code in an unfamiliar part of the codebase, schedule a short pair review session with the author. These live sessions help you understand the context faster, ask questions immediately, and provide feedback more effectively.

   A 15-minute sync conversation can often replace hours of back-and-forth comments. Plus, it's a great opportunity for knowledge sharing across the team.

3. Pass comments and approve PR for minor issues

   You might have experienced how much time and energy it takes to communicate back and forth while fixing PR feedback. While it may be worthy for critical issues, it’s a time killer for minor issues such as renaming variables to meaningful names.

   For minor issues, simply pass comments, approve the PR and move on. You should trust in your team enough that they’ll do their job well.

For the team:

1. Build a coding style guide for your team

   I didn’t learn this early enough in my career but having some coding standards or style guidelines is crucial to build a strong engineering culture. Or at least follow some widely adopted style guide (ex. JavaScript style guide by Airbnb).

   A standard style guideline helps to eliminate debate and conflicts in code review leading to faster reviews.

2. Implement CI/CD to run tests and linter in every PR

   A minor bug or typos can be quickly caught by running tests and linter in the CI/CD pipeline. This helps to cut back code review time by alerting the author about the issue before PR is assigned to the reviewer.

3. Build a strong culture to bypass tidying code reviews

   I love the idea of bypassing code reviews related to tiny structural changes (refactoring) by Kent Beck in the book Tidy First. He suggests that tidying (tiny refactoring) doesn’t require code review in a team with trust and a strong engineering culture.

Code reviews are important for maintaining code quality, but they shouldn't become a bottleneck.

We can significantly speed up our review process by:

• Keeping PRs small and focused

• Writing clear descriptions

• Responding quickly to feedback

• Establishing good team practices like style guides and CI/CD

Remember: faster reviews → faster deployments → faster value delivery to customers.