Stop Hunting Bugs: The Real Code Smell is Your Review Process

We've all been there: a pull request sits for three days, the author pings you, and you finally open it with a sigh. You skim, spot a missing null check, leave a comment, and approve—or worse, you nitpick a naming convention and hold the whole thing hostage. This is the real code smell, and it's not in the codebase; it's in your review workflow.

I'm going to say something unpopular: most code review advice is backwards. It tells you to hunt for bugs, to be the gatekeeper, to find every flaw. But the research—and my own experience—says that's the wrong lens. At Google, where they've studied this at scale, the primary purpose of code review is not to catch defects; it's to make sure the overall code health of the codebase is improving over time (Google Engineering Practices - Standard of Code Review). And a landmark Microsoft study found that reviews are less about defects than expected; they're about knowledge transfer, team awareness, and alternative solutions (Modern Code Review: Expectations, Outcomes, and Challenges). So if you're spending your review hours playing bug-hunter, you're missing the point.

This article is for anyone who's ever felt that code review is a chore, a bottleneck, or a source of tension. It's for developers who've been burned by a review that took a week, and for leads who want their team to actually ship faster without sacrificing quality. I'm going to walk you through five concrete moves to turn your review process from a smell into a strength.

1. Make Reviews a Conversation, Not a Verdict

The golden rule of code review is to critique the code, not the author (Google Engineering Practices - Code Review). That means your comments should be labeled by severity—nit, suggestion, blocking—and should offer solutions, not just point out problems (Google Engineering Practices - Code Review). But here's the twist: you don't have to win every argument. Google's 'LGTM with comments' technique lets you approve a change while leaving unresolved comments when you're confident the developer will address them, or when the comments are minor (Google Engineering Practices - Speed of Code Reviews). This is a game-changer. It tells the author, 'I trust you to handle this,' and it keeps the review moving.

I used to think every comment had to be resolved before I hit approve. That's how you end up with a 20-comment thread on a 50-line change, and a developer who dreads your name. Instead, I now ask myself: 'Is this change better than what was there before?' If yes, approve and let the minor stuff go. You can always follow up in a later change. This doesn't mean you rubber-stamp everything—you still block on real issues. But you stop being a perfectionist, because as Google says, 'there is no such thing as perfect code, there is only better code' (Google Engineering Practices - Standard of Code Review).

2. Speed Is a Feature, Not a Bug

Slow reviews are a code smell in your process. They decrease team velocity, make developers protest the review process, and can hurt code health (Google Engineering Practices - Speed of Code Reviews). Google sets a hard target: one business day is the maximum time to respond to a review request (Google Engineering Practices - Speed of Code Reviews). And they prioritize fast individual responses over fast overall completion, because quick responses ease developer frustration (Google Engineering Practices - Speed of Code Reviews). At Google, the median time to first feedback is under 1 hour for small changes (Modern Code Review: A Case Study at Google). That's the bar.

But here's the counterintuitive part: you shouldn't interrupt your own flow to do a review. Google explicitly advises against interrupting yourself mid-task, because it takes a long time to get back into a smooth flow (Google Engineering Practices - Speed of Code Reviews). So what do you do? You batch reviews at set times—say, first thing in the morning and right after lunch—and you make sure the queue is empty by end of day. This way, you're fast, but you're not destroying your own productivity. And if you're the author, use that time to make your change small enough that it's easy to review.

3. The 100-Line Rule (and Why It's Not About the Number)

Small changes are easier to review, less likely to introduce bugs, and faster to merge (Google Engineering Practices - Small CLs). Google's research shows that a median change is about 24 lines, and 90% touch fewer than 10 files (Modern Code Review: A Case Study at Google). But I'm not going to give you a magic number, because the real rule is about focus. Google says 100 lines is usually reasonable, and 1000 lines is usually too large (Google Engineering Practices - Small CLs). But a 200-line change in one file can be fine, while a 200-line change spread across 50 files is a nightmare (Google Engineering Practices - Small CLs).

So here's my concrete advice: when you're about to submit a PR, ask yourself, 'Can I describe this change in one sentence?' If not, split it. And when you're reviewing, if a PR is too big, don't try to review it—ask the author to split it. This isn't about being lazy; it's about thoroughness. A smaller change gets a more thorough review because you can actually keep it all in your head. Plus, it's easier to roll back if something goes wrong (Google Engineering Practices - Small CLs). I've seen teams adopt a hard limit of 400 lines per PR (Google Engineering Practices - Code Review) and watch their review quality go up. Try it.

4. Automate the Boring 90%

If you're spending your review time on style, formatting, or missing imports, you're wasting the one resource that matters: your attention. Linters, formatters, static analysis, secret scanners, and dependency scanners should handle all that mechanical stuff (Google Engineering Practices - Code Review). I'm not saying you should trust them blindly—but you should let them do the heavy lifting. For JavaScript, ESLint is pluggable and catches patterns that cause bugs (ESLint Docs). For Python, Bandit builds an AST and runs plugins for common security issues (Bandit Docs). For Go, gosec does taint analysis for SQL injection, path traversal, and more (gosec Docs). And for security at scale, Semgrep can scan any codebase (Semgrep Docs).

Set up a quality gate: SonarQube's built-in 'Sonar way' gate, for example, fails if new code has less than 80% test coverage or more than 3% duplication (SonarQube Server Docs - Understanding quality gates). That way, the machine catches the obvious stuff, and you can focus on design, logic, and architecture—the things that actually need a human brain. This is what Google means when they say automation should handle style and mechanical checks so human review focuses on logic and architecture (Google Engineering Practices - Code Review).

5. Design First, Bugs Later

When you open a PR, what's the first thing you look at? If you're like most people, you scroll to the diff and start hunting for bugs. Stop. Google says the most important thing to cover in a review is the overall design of the change (Google Engineering Practices - What to look for in a code review). Look at the big picture before you zoom into the details. Does this change fit the architecture? Is it over-engineered? Google warns to be vigilant about code made more generic than it needs to be, or functionality added that isn't needed now (Google Engineering Practices - What to look for in a code review). That's a code smell that no linter can catch.

And don't forget the tests. Tests are not optional; they should be added in the same CL as the production code (Google Engineering Practices - What to look for in a code review). But here's the thing: tests don't test themselves. You need to review the tests too—are they correct, sensible, and useful? (Google Engineering Practices - What to look for in a code review). I've seen plenty of tests that pass but don't actually assert anything meaningful. That's a smell.

What can go wrong: You might think you're being efficient by skipping the design review, but you'll pay for it later. I once reviewed a PR that added a new endpoint to an API. The code was clean, tests passed, but the design was wrong—it duplicated logic that already existed in a service layer. We merged it, and two weeks later we had to refactor it out. If I'd spent five minutes on the design first, I'd have caught it.

Bottom Line

The single best move you can make is to change your mental model: code review is not a bug hunt, it's a conversation about code health. Slow down on design, speed up on response, keep changes small, and let machines do the boring stuff. Do that, and your reviews will stop smelling.

Sources

• Google Engineering Practices - Standard of Code Review - https://google.github.io/eng-practices/review/reviewer/standard.html
• Google Engineering Practices - Speed of Code Reviews - https://google.github.io/eng-practices/review/reviewer/speed.html
• Google Engineering Practices - Small CLs - https://google.github.io/eng-practices/review/developer/small-cls.html
• Modern Code Review: A Case Study at Google - https://www.papercache.org/papers/mlsys/system/2026/03/25/modern-code-review-a-case-study-at-google
• SonarQube Server Docs - Understanding quality gates - https://docs.sonarsource.com/sonarqube-server/2026.1/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates
• Modern Code Review: Expectations, Outcomes, and Challenges - https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/