8 Common Pitfalls in Code Reviews
How to make your feedback clear, kind, and effective.
As we discussed in Four Reasons To Have Code Reviews, code reviews are one of the most valuable tools for improving code quality and team collaboration. They help us spot issues early, share knowledge, and keep technical debt under control.
But while we often focus on what makes a good code review, it’s just as important to recognize what makes a bad one.
Even with the best intentions, reviewers can fall into traps that slow teams down, frustrate authors, or damage trust. Let’s explore eight common pitfalls—and how to avoid them.
Feedback Arrives Too Late
Timing matters.
A review that comes days—or even weeks—after a pull request is opened often lands with a thud. By then, the author may have moved on to other work or forgotten the finer details of the change.
Late feedback can also block merges and create frustration on both sides. The author feels pressured to context-switch or rush fixes, while the reviewer’s comments risk being ignored or dismissed as “too late to matter.”
Better: Aim to review while the context is still fresh for both author and reviewer. Even quick, early feedback beats a thorough but delayed one. Teams should prioritize reviewing pull requests, making it more important than writing new code in order finish ongoing development as soon as possible.
Focusing on the Nits
Let’s be honest—it’s easy to point out small issues.
Missing spaces, naming conventions, or brace placements are visible and safe to comment on. But they can also distract from what really matters: the overall design, correctness, and maintainability of the code.
Details are important, but they shouldn’t come at the cost of missing the big picture.
A well-named variable won’t save a poorly structured module.
Better: Start reviews with high-level questions—Is this the right approach? Does it integrate well with the rest of the system? Then zoom in on the details. In any case, many of those details should be validated automatically.
Watch Your Tone
Written communication lacks the cues of spoken conversation.
Without tone of voice or facial expression, even neutral feedback can come across as cold, harsh, or passive-aggressive. Remember, when you speak less than 10% of meaning comes from words, almost 40% of the meaning comes from your tone and more than half is delivered through your body language. In a code review, you only have that 10%.
Comments like “Why did you do it this way?” or “This doesn’t make sense” might feel direct to the reviewer but can sound dismissive to the author even if in person you could deliver the same comments in a welcomed way.
Better: Use phrasing that opens conversation, not confrontation. Try “Can you explain your reasoning here?” or “Would it work if we…?” Empathy in writing builds trust over time.
Reviewing the Reviewer
It’s easy to forget that we’re reviewing code, not people.
When feedback feels personal — “You made a mistake” (not to mention harsher comments) instead of “This code might break if…” — it can erode confidence and discourage openness.
Everyone’s learning. Even senior engineers make mistakes. Blame isolates; kindness multiplies.
Better: Focus feedback on the work, not the worker. We’re all trying to make the codebase better, together.
Bossy or Commanding Language
“Change this.”
“Do it this way.”
“Use X instead of Y.”
Commands like these shut down collaboration. They turn what should be a shared discussion into a one-sided instruction.
Even when you’re absolutely right, how you say it matters.
Better: Use language that invites input: “What do you think about using X here?” or “Could we simplify this by…?” Humility makes feedback easier to receive — and easier to act on.
Comment Lacks Priority
As we discussed in Five Categories of Feedback in Code Reviews, not every comment is created equal.
Without clear intent, authors can’t tell whether something is a must-fix or just a thought. That uncertainty often leads to confusion or wasted effort.
Better: Make your comment’s priority explicit.
Is it a ⛔️ blocker, a ⚠️ maybe, a 💡 nit, a ❓ question, or even a 🎉 kudos?
Comments Lack Explanation or Educational Value
A cryptic “rename this” or “bad pattern” barely teaches anyone anything.
Vague feedback frustrates authors and deprives them of context or reasoning. Without explanation, people may fix blindly or argue needlessly.
Better: Explain why something matters. Link to a guideline, a blog post, or an example.
Turn your review into a teaching moment — it makes your team stronger and your future reviews smoother.
When Everything Gets Commented
If every line gets a comment, the message becomes noise.
Authors can feel micromanaged, like they have no creative space or trust. It signals that there’s only one “right” way to code — and it’s yours.
Better: Choose your battles. Comment on things that truly matter for correctness, design, or readability. Perfection isn’t the goal — progress is.
Wrapping Up
Code reviews are not about asserting authority or proving expertise.
They’re about collaboration, shared ownership, and continuous learning.
Avoiding these eight pitfalls helps ensure your feedback lands as helpful instead of hurtful — and builds a healthier review culture in your team.
But it’s not all about the reviewers. Authors can also do — a lot — to ensure that code reviews go well. Next week, we’ll talk about what mistakes authors should avoid when submitting their code for reviews. Because great reviews start long before the first comment is written.