small-change: A Practice That Speeds Up Code Review

Why Code Review Always Lags Behind

Code review is a critical step in ensuring software quality, yet it often becomes the most easily stalled part of the development process. A large Pull Request (PR) often means reviewers must spend hours or even days to complete a full read-through, and during that time, the author's context is continuously lost, and merge conflicts quietly accumulate.

A discussion thread titled small-change recently appeared on Hacker News, with the title pointing directly at "Speeding up code review with small-change." Although the post itself has only 6 points and 2 comments—a typical small technical share—it touches on a rather universal problem: the bottleneck in review speed often lies not with the reviewer, but with the granularity of the change itself.

The Core Idea of small-change

As the name suggests, small-change advocates an engineering habit of "small-step changes." Its core proposition is not complex: rather than submitting a giant PR containing hundreds of lines of changes spanning multiple modules, break the work into several semantically complete small changes that can be reviewed independently.

This idea is not new—Google emphasized "small, frequent CLs (Changelists)" in its engineering practices years ago. But the value of small-change lies in turning it into a tool and process, so that "breaking things down" no longer depends on individual discipline but becomes a default constraint at the submission stage.

Why Small Changes Are Faster

Small changes accelerate review for three reasons:

• Lower cognitive load: Reviewers only need to understand one logical unit at a time, without switching back and forth between multiple abstraction layers.
• Shorter feedback loops: Smaller changes mean shorter validation cycles for builds, tests, and deployments, exposing problems earlier.
• Lower rollback costs: When a small change goes wrong, the cost of locating and reverting it is far lower than for a giant commit.

Developers in the Hacker News comments pointed out that what really slows down review is often not the number of lines itself, but "a PR that mixes refactoring, new features, and formatting adjustments"—commits with impure motives. The discipline of small changes precisely forces authors to separate changes of different natures.

The difference between Pull Request (PR) and Changelist (CL): PR is the merge request model on platforms like GitHub and GitLab, typically organized by branch, where reviewers can see the complete diff, comments, and CI status; CL is Google's internal change unit based on Piper, emphasizing "one CL does one thing" and requiring strict automated testing and approval from at least one reviewer before submission. The two are similar in philosophy, but the CL model places more emphasis on the atomicity and rollback-ability of changes. Although the small-change discussion uses PR as its vehicle, its "small-step change" discipline is in line with CL culture—both aim to make every change easy to understand, verify, and undo.

Cognitive Load refers to the amount of information reviewers must process simultaneously when reading code. When a PR mixes renaming, formatting adjustments, new logic, and deletion of old code, the reviewer's brain must constantly switch between judgment frameworks of "is this a style issue or a logic issue," making it easy to miss real defects. Small changes reduce this switching cost by limiting the context scope of a single review. The psychological theory of "limited working memory capacity" also supports this: humans can only process about 4 to 7 information chunks at a time, and error rates rise significantly beyond that. Therefore, controlling change granularity is not just process optimization but also respect for reviewers' cognitive resources.

Common Pitfalls in Implementation

Breaking changes into smaller pieces sounds simple, but resistance arises in practice. The most common challenge is: feature dependency chains are naturally continuous—won't forced splitting create a bunch of intermediate states that cannot run independently?

Splitting Is Not Fragmentation

Here we need to distinguish "small" from "fragmented." A healthy small-change should be semantically self-consistent: it can pass tests independently, and reviewers can clearly judge after reading it whether it should be merged. If a split change must depend on the next PR to compile, it degenerates into a fragmented commit, which反而 increases review burden.

A feasible practice is: first merge refactorings that do not change behavior (such as extracting functions, renaming), then merge behavior changes. This way, each PR's review focus is clear, and reviewers do not need to evaluate "is the logic correct" and "is the style good" simultaneously.

Tool Constraints Are More Effective Than Verbal Agreements

An insight implicit in the post is that if engineering standards are only written in documentation, execution rates are often poor. The real value of practices like small-change is that they can be integrated into the submission process—for example, setting reminder thresholds in CI for the number of changed lines or files in a PR. Once constraints are automated, teams no longer need to repeatedly emphasize discipline in meetings.

CI (Continuous Integration) threshold reminders are a common automated constraint. For example, a lightweight script can be configured in GitHub Actions or GitLab CI to automatically add a "large PR" label and remind the author to consider splitting when a PR exceeds 400 changed lines or involves more than 10 files. Such constraints do not block merging but create a visible feedback loop, making "breaking things down" the default expectation at submission. Compared to repeatedly emphasizing standards in team meetings, automated reminders have higher execution rates because they embed discipline into the toolchain rather than relying on personal memory or discipline.

Implications for Teams

The speed problem in code review is essentially a collaboration granularity problem. The answer given by small-change is simple but effective: make changes smaller, so that each review becomes a quick, focused judgment rather than a marathon reading session.

For teams struggling with PR backlogs, start with a low-cost experiment: tally the distribution of changed lines in the last 20 PRs and see how long those commits exceeding 500 lines take on average to merge. Data is often more persuasive than any methodology.

Of course, this approach has its boundaries. For scenarios involving cross-module interface refactoring or large-scale migrations, forced splitting may introduce more coordination costs. Tools and discipline serve efficiency, not the other way around—they should not constrain engineers' judgment.

One-line Summary

small-change advocates semantically self-consistent, small-granularity changes to accelerate code review and reduce collaboration costs.

Paragraph Summary

Starting from a small discussion thread about small-change on Hacker News, the article explores how the root cause of slow code review lies in change granularity rather than the reviewers themselves. The core proposition of small-change is to break large PRs into semantically complete small changes that can be reviewed and merged independently, thereby reducing cognitive load, shortening feedback loops, and lowering rollback costs. In implementation, it is important to distinguish "small" from "fragmented" and ensure each change can pass tests independently; it also recommends replacing verbal standards with tool-based constraints such as CI threshold reminders. Finally, the article suggests teams first tally the distribution of changed lines in recent PRs and use data to drive improvement, while acknowledging that judgment space must be preserved in scenarios like cross-module refactoring.