The 24-Line Pull Request: Why Small Reviews Win

Imagine you are a staff engineer at a mid-sized SaaS company. It's Tuesday morning, and you open your pull request queue to find a 2,000-line monster titled "Refactor auth service and add new billing API." Your heart sinks. You know this review will eat your day, and by the time you finish, the author will have moved on to three other branches. This is the moment when code review either becomes a bottleneck or a force multiplier.

Here's the thing: we've been doing code review wrong. We've been seduced by the idea that bigger changes are more efficient, that one massive review covers everything, and that thoroughness means reading every line. But the evidence says otherwise. Google's own internal data, from a study covering about 9 million reviewed changes, shows that the median change is just 24 lines (Modern Code Review: A Case Study at Google). More than 35% of changes touch only one file. And yet, in many teams, we're still asking reviewers to digest 1,000-line diffs. That has to stop.

The Case for Small, Focused Pull Requests

Let's follow a concrete example. You're reviewing a change to add a new endpoint to a Python Flask app. The author, Maya, has split her work into three pull requests. The first one, which you're looking at now, is 120 lines: it adds a new route, a simple input validation function, and two unit tests. She's followed Google's guidance that 100 lines is usually a reasonable size for a change, and 1,000 lines is usually too large (Google Engineering Practices - Small CLs). As a reviewer, you can actually read this in fifteen minutes. You check the logic, you see the edge cases, and you can give meaningful feedback on the design before you ever get to the minutiae.

Contrast that with the old way: a 1,500-line pull request that mixes a database migration, a refactor of the auth service, and a new billing API. You can't review that thoroughly. You'll skim, you'll miss bugs, and you'll spend hours just trying to understand the context. Small changes are reviewed more quickly, more thoroughly, and are less likely to introduce bugs (Google Engineering Practices - Small CLs). And when something goes wrong, a small change is easier to roll back. That's not just convenience; it's a fundamental part of keeping your codebase healthy.

Speed Matters, But Don't Interrupt Yourself

Now, Maya has posted her PR and she's waiting. You know the drill: the longer the wait, the more context she loses, and the more frustrated she gets. Google sets a clear target: one business day is the maximum time to respond to a review request (Google Engineering Practices - Speed of Code Reviews). That means you should aim to get first feedback within 24 hours, ideally sooner. But here's the nuance: you shouldn't drop everything to review it the second it lands. Google's advice is to review shortly after it comes in if you're not in the middle of a focused task, but don't interrupt yourself mid-task—research shows that it takes a long time to get back into flow after an interruption (Google Engineering Practices - Speed of Code Reviews). So you finish your current coding session, then you dive into Maya's PR.

In the Google study, the median time to first feedback was under 1 hour for small changes (Modern Code Review: A Case Study at Google). That's fast, but it's achievable if you batch your review time. You set aside two or three blocks a day to process reviews. When you do open Maya's PR, you see it's small and well-formed. You leave a few comments: one on the input validation function where she could use a built-in validator, and one on the test where she's missing a boundary case. You use the 'LGTM with comments' technique: you approve the change even though you've left comments, because you trust Maya to address them (Google Engineering Practices - Speed of Code Reviews). This keeps the review moving, and Maya can merge without waiting for another round-trip.

What Actually Matters in Review

So what do you look for in that 120-line PR? The most important thing is the overall design of the change (Google Engineering Practices - What to look for in a code review). Does this new endpoint fit the existing architecture? Is it over-engineered? Google warns to be especially vigilant about over-engineering—code made more generic than needed (Google Engineering Practices - What to look for in a code review). Maya's validation function is simple, not a generic validation framework. Good.

Then you check for edge cases and concurrency issues. You think about what happens if the request body is malformed, or if the database is down. You also look at the tests. Google expects tests to be added in the same change as the production code, and they must be correct, sensible, and useful—tests do not test themselves (Google Engineering Practices - What to look for in a code review). Maya's two tests cover the happy path and a validation failure. You suggest adding a test for the case where the input is a string instead of a number. That's a concrete, valuable comment.

Security is also on your checklist. You check for input validation, SQL injection, path traversal, hardcoded credentials, and vulnerable dependencies (Google Engineering Practices - What to look for in a code review). For a Python app, you might run Bandit, which scans for common security issues by building an AST (Bandit). You also check if the dependency versions in the lockfile are up to date; Dependabot will alert you to known vulnerabilities, but it's not a magic bullet (GitHub Docs - About Dependabot alerts).

Automate the Mechanical, Humanize the Rest

One of the biggest time-wasters in review is arguing about formatting and style. Don't do that. Linters, formatters, static analysis, secret scanners, and dependency scanners should handle style and mechanical checks, so human review can focus on logic and architecture (Google Engineering Practices - code review). For Python, you'd run ESLint if it were JavaScript, or gosec for Go—but the principle is the same: let the machines do the mindless work.

In Maya's PR, you notice she has a line that's too long, but you don't comment on it because your CI has a linter that will fail the build if it's not fixed. Instead, you spend your time on the one design question: should this endpoint be a GET or a POST? You decide it should be a POST because it creates a new resource. That's a substantive comment that would be lost if you were buried in whitespace nitpicks.

You also check the commit message. Google requires the first line to be a short summary of what the CL does, written as a complete imperative sentence, because it appears in version control history (Google Engineering Practices - Writing good CL descriptions). Maya's message is "Add endpoint for creating billing accounts"—that's fine. If it said "Fix bug," you'd ask her to clarify, because a commit message is a public record of the change and should communicate both what and why (Google Engineering Practices - Writing good CL descriptions).

The Golden Rule and the Bigger Picture

Underlying all of this is the golden rule of code review: critique the code, not the author (Google Engineering Practices - code review). You're not Maya's enemy; you're her safety net. The primary purpose of review is to make sure the overall code health of the codebase is improving over time (Google Engineering Practices - Standard of Code Review). That means you should favor approving a change once it definitely improves the codebase, even if it's not perfect—"there is no such thing as perfect code, there is only better code" (Google Engineering Practices - Standard of Code Review).

So you approve Maya's PR, leave your comments, and she merges it. The whole review took you 20 minutes. She's happy, you're happy, and the codebase is a little better. Multiply that by 20 changes a day, and you have a team that moves fast without breaking things. The research shows that speed and stability are not tradeoffs (DORA). And the more you review, the more you learn—peer review increases the number of distinct files a developer knows about by 66% to 150% (Convergent Contemporary Software Peer Review Practices).

But what about the emergency? Sometimes you have to review a hotfix at 2 AM. Google defines an emergency CL as a small change that fixes a major security hole or lets a launch continue instead of rolling back (Google Engineering Practices - Emergencies). In that case, you prioritize speed over thoroughness, but you must go back and do a more complete review afterward (Google Engineering Practices - Emergencies). That's the exception, not the rule.

In the end, the single most important thing to remember is this: keep your pull requests small, and review them with the same urgency you'd want for your own. The 24-line median at Google is not a coincidence; it's a deliberate strategy that enables fast, thorough, and humane code review. If you take away one practice from this article, make it this: split your next big change into a series of tiny, focused PRs, and review each one with the care it deserves. Your future self, and your team, will thank you.

Sources

• Google Engineering Practices - Code Review - https://google.github.io/eng-practices/review/
• 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
• 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
• Bandit (PyCQA) Docs - https://bandit.readthedocs.io/en/latest/
• DORA - Software delivery performance metrics - https://dora.dev/guides/dora-metrics-four-keys/