Code Review Done Right: A Field Guide to Small PRs and Fast Reviews

Imagine you're a senior developer at a mid-sized SaaS company. It's 9:30 AM on a Tuesday, and a junior dev, Priya, has just posted a pull request titled "Add user profile page." You open it, and the diff is 1,200 lines across 14 files. Your first instinct is to sigh. You know this review will eat your morning. But here's the thing: it didn't have to be this way. At Google, the median change size is just 24 lines (Modern Code Review: A Case Study at Google, ICSE-SEIP '18). That's not a typo. So why is your team reviewing 1,200-line monsters? Let's walk through how to fix this, one step at a time.

The Anatomy of a Small PR

Your first move is to stop the madness at the source. Google's engineering practices are explicit: a pull request should be kept small and focused, ideally under 400 to 500 lines of meaningful change (Google Engineering Practices). And they're not just talking about the number of lines – they say a 200-line change in one file is fine, but the same change spread across 50 files is usually too large (Google Engineering Practices - Small CLs). So when Priya posts a 1,200-line PR, you don't review it. You push back. You ask her to split it into logical pieces: one PR for the database schema, one for the API endpoints, one for the UI. It's not about being pedantic – small changes are reviewed more quickly, more thoroughly, and are less likely to introduce bugs (Google Engineering Practices - Small CLs). The data backs this up: at Google, over 35% of changes modified only one file, and about 90% touched fewer than 10 files (Modern Code Review: A Case Study at Google, ICSE-SEIP '18). That's the reality of a healthy codebase.

Speed Is a Feature, Not a Luxury

Now imagine you've convinced Priya to split the PR into a 300-line change. You get a notification. What do you do? You respond within a day – Google's rule is that one business day is the maximum time to respond to a review request (Google Engineering Practices - Speed of Code Reviews). And they're not just being polite: slow reviews decrease team velocity and make developers protest the process (Google Engineering Practices - Speed of Code Reviews). But here's the nuanced part: you shouldn't interrupt yourself mid-task to review it. Google notes that interrupting your coding flow is more expensive to the team than making a developer wait a bit (Google Engineering Practices - Speed of Code Reviews). So you finish the function you're writing, then you review. And when you do, you aim for that first response to come in under an hour – at Google, the median time to first feedback for small changes is under 1 hour (Modern Code Review: A Case Study at Google, ICSE-SEIP '18). That's the gold standard.

What to Actually Look For

When you open that 300-line diff, your job isn't to nitpick variable names. Google says the most important thing is the overall design of the change (Google Engineering Practices - What to look for in a code review). Then you check functionality, complexity, tests, naming, and comments – in that order. Don't get bogged down in style; that's what linters and formatters are for (Google Engineering Practices - Code Review). Your human brain is for spotting real issues: edge cases, concurrency problems like deadlocks and race conditions, and whether the change is over-engineered (Google Engineering Practices - What to look for in a code review). And yes, you should check for security basics – input validation, SQL injection, hardcoded credentials (Google Engineering Practices - Code Review). But remember, finding bugs isn't the primary purpose of review. At Google, the four key expectations are education, maintaining norms, gatekeeping, and accident prevention (Modern Code Review: A Case Study at Google, ICSE-SEIP '18). So you're there to teach Priya, not just to catch her mistakes.

The LGTM with Comments Technique

Priya's PR looks good. There are a few minor things – a typo in a comment, an unused import, a suggestion to refactor a tiny helper. Do you request changes? No. You use the 'LGTM with comments' approach: you approve the PR while leaving unresolved comments, because you're confident Priya will address them (Google Engineering Practices - Speed of Code Reviews). This is a game-changer for velocity. It signals trust and keeps the momentum going. Of course, if there's a real issue, you request changes – but only when it's genuinely blocking. And when you do leave comments, make them specific: file paths, line numbers, and a suggested solution (Google Engineering Practices - Code Review). Priya's first response to your comments should be to clarify the code itself, not just explain it in the review thread – because an explanation in the review tool doesn't help future readers (Google Engineering Practices - Handling reviewer comments). So you guide her to add a comment to the code.

Automate the Boring Stuff

You can't manually check every style rule, and you shouldn't. Google says linters, formatters, static analysis, secret scanners, and dependency scanners should handle the mechanical checks so you can focus on logic and architecture (Google Engineering Practices - Code Review). So set up your pipeline: use ESLint for JavaScript (ESLint Docs), Bandit for Python (Bandit Docs), gosec for Go (gosec Docs), and Semgrep for cross-language security patterns (Semgrep Docs). And don't forget SonarQube – it can analyze reliability, security, maintainability, coverage, and duplication (SonarQube GEANT KB). The key is to integrate these tools into your CI so that a PR can't merge if it fails the quality gate. SonarQube's quality gate, for example, can block a merge if new code coverage is below 80% or duplication is above 3% (SonarQube Server Docs - Understanding quality gates). That takes a huge burden off you as a human reviewer.

The One-Reviewer Rule

Now, who should review Priya's PR? Just you. Google's data shows that fewer than 25% of changes had more than one reviewer, and the median number of reviewers is 1 (Modern Code Review: A Case Study at Google, ICSE-SEIP '18). Over 99% had at most five. So don't ask for a committee. One competent reviewer is enough for most changes. If you need extra eyes, use GitHub's CODEOWNERS to automatically request review from the right people (GitHub Docs - About code owners). And if you're using GitLab, you can require approvals from specific categories – backend, frontend, QA, database (GitLab Docs - Merge request approvals). But for most changes, one reviewer keeps things fast and focused.

Quick tip: Before you start reviewing, check the PR description. Google requires a clear, imperative summary of what and why – not "Fix bug" (Google Engineering Practices - Writing good CL descriptions). If it's vague, send it back.

Bottom Line

The single best move you can make for your team's code review is to enforce small pull requests – under 400 lines, ideally under 100 (Google Engineering Practices - Small CLs). Then review them within a day, use LGTM with comments for minor issues, and let automation handle the rest. That's how you turn code review from a bottleneck into a routine that improves code health every single day.

Sources

• Google Engineering Practices (code review) - https://google.github.io/eng-practices/review/
• Google Engineering Practices - Small CLs - https://google.github.io/eng-practices/review/developer/small-cls.html
• Google Engineering Practices - Speed of Code Reviews - https://google.github.io/eng-practices/review/reviewer/speed.html
• Modern Code Review: A Case Study at Google (ICSE-SEIP '18) - 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