How to Best Review Pull Requests (Without Governing Solutions)
In tech, we’re always working toward writing better, stronger, more maintainable code. Code reviews are an essential part of that process. Yet, it’s a skill we rarely focus on improving. Too often, reviews become something we stumble through, slowing teams down and hurting overall quality.
Becoming a quality reviewer can make you a real asset to your team, but it’s not easy. Many of us approach code reviews from the wrong angle or with misguided purposes. Learning to review the right things in the right way can transform your team’s dynamic and set you on a path for success.
The Purpose of a PR Review
As engineers, our primary job is to write code. To solve problems. To keep the world turning one bit or byte at a time. But what’s our role when reviewing code? That question can be jarring, especially the first time you’re asked to review someone else’s code.
So, let’s start with what you’re not expected to do:
- You’re not expected to solve the problem for the author.
- You’re not expected to rewrite their code to match your own vision.
So, what are you responsible for?
A team’s success often depends on the quality of code that makes it into production and how quickly critical issues are discovered and resolved. The main goal of a PR review is to ensure that:
- the problem posed has been solved,
- the solution is clean and testable, and
- the code is efficient and complete.
Often, the solution will look very different from how you would have solved it, and that’s fine.. That’s not relevant to the review. What matters is whether the code works, is maintainable, and can be tested effectively.
Another major benefit of reviews is knowledge transfer. Everyone solves problems differently, and reviewing code is an opportunity for the team to learn from one another. Approach reviews as a chance to expand your perspective, not dictate solutions.
So, let’s dive in a little more and talk about why you’re doing this.
Is This Done?
We’ve all been there: you start solving a problem, discover a cool tangential idea, and suddenly you’re building something completely different. You get to the end and you excitedly hold up your idea for all to see, only to realize that you didn’t actually solve the problem you set out to solve. You built something cool and amazing, but it doesn’t solve the intended purpose. That code may be useful someday, but it doesn’t solve the intended problem.
The PR review can help us avoid these little misdirections from making it into production and causing customer woes. The reviewer should focus on the problem at hand. Have a small familiarity with the tickets associated with this PR, have read the README or comments on the PR, and have a solid understanding of the problem being solved. We want to be sure that the engineer understood the problem as well and tackled the right issue. Mistakes happen, and that’s ok. We just need to correct them whenever possible.
Housekeeping
Most of us will write code in an iterative fashion, meaning that we solve the problem instinctually but then rewrite the code several times to make it as clean, clear, and efficient as possible. But sometimes, we don’t make quite as many iterations as we could have to get to the true bottom line. Here’s the tricky part: your job isn’t to judge whether the solution is the absolute cleanest possible, but whether it’s clean enough to be testable and maintainable. This is a very fine line that can be difficult to traverse. You don’t want to lose the forest for the trees, as they say.
A review should focus on whether this code is in a state where it will be easy to test and maintain; that’s it. Read the code and envision future bugs or changes that could arise, and how difficult will this code be to debug or change? If it seems confusing or complicated, we should probably simplify it. However, if the code seems easy enough to work with but you can envision an even better solution, it’s ok to call that out, but don’t let that block the review.
You’re not here to solve the problem for the author, but to make sure that they solved the problem themself. Tips and tricks help us learn and grow, so your advice is welcome, but don’t make it a blocking issue. You can’t dictate how the problem is solved.
Conclusion
Code reviews aren’t about proving you’re the smartest engineer in the room or forcing every solution to match your style. They’re about safeguarding quality, ensuring testability, and strengthening the team through shared knowledge.
If you approach reviews by focusing on what the code accomplishes instead of how it gets there, you’ll help your team move faster, build trust, and foster collaboration.
In the next part, we’ll dig into the how: the principles and practices that make a review effective, respectful, and productive. Because even if you know the purpose, it takes real skill to deliver feedback that elevates both the code and the coder.
Original posted: https://substack.com/@halexmorph
