How to Scale Code Reviews 🔥
#78: How Great Software Engineers Do Code Reviews (4 Minutes)
Get my system design playbook for FREE on newsletter signup:
This post outlines tips for reviewing code. You will find references at the bottom of this page if you want to go deeper.
Share this post & I'll send you some rewards for the referrals.
Once upon a time, there was a 2-person startup.
Yet they had a tiny website and only a few customers.
So they merged the code directly into the main branch.
But one morning, their site became extremely popular.
And the number of customers and feature requests started to skyrocket.
So they hired more developers and implemented extra features.
Yet each developer wrote code with their personal preferences.
Thus worsening the code quality and standards. Also increasing the number of bugs.
So they started doing code reviews before merging new code into the codebase.
A code review means someone other than the author reviews the code.
Although it temporarily solved their code quality problem, there were newer issues.
Here are some of them:
1. Developer Velocity
They followed a strict review process and spent time on minor issues.
Put simply, they asked for low-priority changes on a tight deadline ticket.
It means delayed pull requests and slow developer velocity1.
Besides having teams across different time zones worsened the situation.
2. Personal Conflict
They didn’t have set guidelines for code reviews.
So developers forced their personal preferences during reviews.
It means unnecessary disagreements and demotivated developers.
Also feedback with a toxic and mean tone made things worse.
3. Miscommunication
There’s a risk of misunderstanding feedback in remote or asynchronous reviews.
Also a reviewer must understand new code and how it works with the codebase.
So the reviewer might get overloaded with code reviews and parallel development tasks.
Besides the reviewers might miss bugs even with thorough reviews, especially in large pull requests.
Onward.
I’m happy to partner with CodeRabbit on this newsletter. I’ve seen code reviews delaying feature deliveries by days and overloading reviewers. I genuinely believe CodeRabbit solves this problem.
How to Do Code Review
Let’s dive in:
1. Best Practices
Both the author and the reviewer should respect each other’s time and efforts.
Here are some guidelines for the code author:
Follow the project's style guide2.
Keep the changes small to make the reviews easy.
Review the code yourself before asking others to save time.
Use existing code patterns, and not personal preferences, if a style is unspecified.
Tag only the fewest number of reviewers to save everyone’s time.
Write a clear message about the changes for the reviewer to understand easily.
Use facts and data to resolve design debates, rather than opinions.
Code reviews are each software engineer's responsibility.
Here are some guidelines for the reviewer:
Respond to a review request within 24 hours.
Reserve at least one calendar slot each day for code reviews.
Keep the reviews polite and constructive; don’t criticize the author.
Document common review points and use a review checklist for consistent reviews.
Discuss the issue directly with the author when there’s a disagreement. Then document the solution for future reference.
Share the documentation in review comments if necessary to encourage knowledge sharing.
Approve the pull request when it’s good enough and allow minor issues to be fixed later.
Remember, code reviews are about making progress and not perfection. So just make sure each change maintains or improves the codebase's health.
Let’s keep going!
2. Code Review Flow
Version control platforms, such as GitHub and GitLab, include pull request features for code review. They allow inline comments, approvals, and automated checks. Also there is peer review software, such as Gerrit, for advanced workflows.
Here’s the code review workflow from a developer perspective:
Pull Request
Write code on a separate Git branch to isolate changes.
Get instant feedback and fix suggestions with code editor extensions, such as CodeRabbit. Thus catching problems even before creating a pull request3 and saving infrastructure resources.
Commit code with a clear commit message and push it to the remote repository.
Open a pull request from the current branch to the target branch.
Continuous Integration
Run automated checks on the code, such as unit tests, static code analysis4, security scans, and linting5, to ensure code correctness. It finds style issues, code smells, or security vulnerabilities, so reviewers can focus on high-level feedback.
Find issues and get auto-fix suggestions using CodeRabbit. This approach improves developer velocity.
Code Review
Tag one or more relevant team members to ask for review.
Generate a summary of code changes using CodeRabbit. It helps reviewers understand complex changes quickly. And assess the impact on the codebase.
The reviewer checks the changed files and leaves constructive feedback via comments.
Code Update
Fix the code based on the reviewer’s comments.
Upload changes to the same pull request and make sure automated checks pass again.
Reply to the reviewer's feedback and resolve comments.
Deploy
At least one reviewer approves the pull request.
Merge the pull request into the target branch and trigger continuous deployment (CD).
CD pipeline builds and deploys the change to the staging environment.
Once the staging tests pass, the change gets released to production.
Continuous integration means merging code changes regularly into a central repository. While Continuous deployment is about automatically releasing changes that pass checks into production.
CodeRabbit is an AI code review tool to reduce developer workload.
Here’s how it helps with code review flow:
Do routine checks and reduce the time spent on reviews from days to minutes. Thus improving developer velocity.
Do consistent reviews without getting tired or biased. Thus reducing the risk of missing important issues from human mistakes.
Provide mentorship to junior engineers through detailed feedback.
Put simply, CodeRabbit complements human reviewers. It serves 1+ million repositories and has reviewed over 10 million pull requests. And it remains the most installed app on GitHub and GitLab.
Subscribe to get simplified case studies delivered straight to your inbox:
Want to advertise in this newsletter? 📰
If your company wants to reach a 160K+ tech audience, advertise with me.
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
References
Speed and efficiency of delivering high-quality software.
Proposal for merging code changes into the main branch.
Checks code for errors, bugs, and style issues without running it.
Checks code for style errors and formatting issues.











Solid breakdown, Neo.
I think everybody should approach code reviews as a tool for learning or teaching.
Loved the emphasis on small, clear changes and respectful feedback.
One thing I’d add: don’t skip reviewing tests; well-written tests can catch issues early and explain intent better than comments.
Great read, thanks for sharing