Ankur Tyagi
Aravind Putrevu
March 03, 2025
|7 min read
Good code reviews take thoughtful, unambiguous communication. This can be a big challenge as a team grows. Each developer creates additional lines of code. This is why well-documented code review guidelines, processes ,and principles are so important.
Code review is a critical step in the software development lifecycle that you shouldn't omit. However, how code review should be done has been debated for a long time.
Every organization approaches code reviews in their own way.
In some organizations, everyone reviews the code. Others prefer to assign code review to one team member (usually a more senior engineer than the author).
Big tech companies usually have an internal code review tool to manage the entire process. Google has Critique & Gerrit, and Meta has Phabricator. Also, since Generative AI and AI Code Assistants became very popular, many organizations have adopted them to automate code reviews.
Similar to how organizations approach code review in their way, software engineers also have opinions on how they want code review done. These opinions might differ from their reality at work. This shows a difference between how engineers would like to do code reviews and how their workplace makes them do it. We came across some opinions from engineers on X about code review.
We think these are worth looking at.
Every one of these engineers has a valid reason for their opinion. And some with real-world experience to buttress why they hold such opinions.
Based on the diverse takes we have seen on the subject of code review, we pretty much grouped them into:
The “I like code review” group consists of people who want code review regardless of the pass threshold set. They will adjust to any code review process structure set at their workplace.
The “I like code review but” group. Folks in this group want code review but with certain conditions, such as “I like code review but don’t force me to write in your code style,” “I like code review, but we should automate with an AI agent,“ etc.
The “I don’t think code review is necessary” group (not a popular group). Some people in this group believe that code review is just a way for someone to make you conform to their standards.
Again, each group has a good reason for their choice. Our focus in this post is to share tips on thoughtful code reviews. First, let’s quickly detour to the code review blame culture.
It is a known fact that the code review process can be a tedious exercise involving multiple back-and-forths between an author and a reviewer. If not properly managed, it can create an environment where the focus shifts to finding faults in code and apportioning blame when a bug escapes review. we call it the blame culture.
Code review is about ensuring code quality, consistency, and best practices.
Authors should not view code reviews as antagonistic. Similarly, feedback from reviewers should be issue-based. The blame culture thrives when teams behave contrary to these—personal attacks, nitpicking, defensiveness, etc.
If a bug manages to escape code review, what comes to mind should not be “Whose is to blame?” but “What went wrong and how can we fix it?.” We call it the team mindset.
The blame culture is toxic and should have no place in code review.
Now that we have established that, let’s move on to how to do code reviews thoughtfully.
There is no one-size-fits-all approach to code review. However, teams should approach it with transparent processes and standards. A thoughtful code review goes beyond finding errors to promoting knowledge sharing, collaboration, and empathy.
The following are some elements that we think a thoughtful code review should have:
You should first self-review your code. Before clicking “Create Pull Request,” give your work a second look. No, this doesn’t mean you don’t trust or believe in yourself. It means that you understand that you can make mistakes. More importantly, it means you value the reviewer’s time and effort.
Check your code and tests for errors and bugs before submitting it for peer review.
Additionally, focus on high-risk vs. low-risk changes during self-review.
High-risk changes—those affecting critical business logic, security, or performance—deserve extra scrutiny.
Low-risk changes- such as minor refactors or docs updates, can be reviewed with a lighter touch. By prioritizing your review efforts, you help ensure that major issues are caught early while keeping the process efficient.
It is hard (almost impossible) to thoroughly review a codebase with large changes.
Nobody wants to review 1,000+ lines of code in one go. It’s exhausting, error-prone, and delays feedback. Break big changes into small, logical PRs—it keeps things moving faster. Big tech like Google, Facebook, and every well-run engineering team encourages the small commits culture and prevent merge hell.
Rule of thumb: If a PR takes more than 10-15 minutes to review, it’s too big.
Consider the feelings of others when you write or review code. Following best practices and writing clean code means you care about who takes a look at your work. Empathy is putting yourself in the shoes of the other person.
For example, feedback such as “I find this function a bit unusual. Do you mind giving it a second look?” is more empathetic than “This is a bad function. You should do a rewrite.”
PR comments shouldn't be personal, or vague.
❌ You didn't check for a null value.
✅ This input value could be null, causing a server error. If null, a client error should be thrown.
The second: - targets the code, NOT the person - is clear about a suggested improvement.
Good code reviews aren’t just about finding bugs. They’re about helping your team write better code. If your feedback sounds like an attack, nobody will listen.
No one likes going through the same thing over and over again. You easily get bored and frustrated doing so. Frankly speaking, code review cycles can get you into that bored and frustrated spot. This is why you should try to abstract away redundant manual steps.
Use automation tools to streamline your workflows. Linters are great for automating parts of your code review process.
You could also employ AI Code agents to automate certain levels of code review.
The human element will always be important in code review (at least for the foreseeable future). While linters and formatters have helped us follow agreed practices by teams, using AI-based Code Review automation tools, you can further leverage AI-powered Linting to suppress noise and bubble up impactful issues.
Note: AI based tools prone to hallucinations. Fine-tuning or instructing the LLMs on how you want the code to be reviewed may be essential in some cases, for a desired output.
We all have our own biases as humans. Each of us has a certain way we like things to be like. And that’s okay. However, we should not impose our biases (or preferences) on others.
Do not impose your code style on others.
Approving code should not be “as the reviewer wishes.” Your team should set a clear pass threshold.
Set the minimum standards code submissions must meet to merge in the main codebase.
Examples of the pass threshold you could set are: performance benchmark, security, and readability.
GitHub Checks can help you automate and enforce pass thresholds. By requiring specific checks to pass before a pull request can be merged, you ensure consistent code quality and speed up the code review process.
Provide specific and actionable feedback. Where you don’t have the right context, ask questions and don't make assumptions. A good code review isn’t just criticism. it’s a collaboration**.**
Be specific, actionable, and ask questions when you’re unsure.
Bad: This is wrong. Fix it.
Better: This approach might have a race condition. Could we use a lock here instead?
You don’t have to solve every problem—just help the author think through their solution.
Code review is a time-consuming process.
Approaching it thoughtfully makes it easier for all parties involved. If done right, it can help your team improve code quality, ensure consistency, and promote collaboration, openness, and a learning culture.
How does your organization do it? And how do you want it done?
