Rule 34 of 38 · Chapter VI — Shipping Is Part of Engineering
Small changes, often
Why this rule exists
Small changes are easier to review, test, and reason about, and when one breaks, the cause is obvious because there's little else in the change. Large batches hide bugs among unrelated edits, make reviewers skim, and turn every rollback into surgery. Shipping little and often shrinks the blast radius of any single mistake and gives you feedback while the work is still fresh in your head.
In practice
Break work into increments that each stand on their own and merge within a day or two. Separate refactors from behavior changes so each commit says one thing. Use feature flags to land unfinished work safely behind a switch, and integrate with the main branch constantly instead of hoarding on a long-lived branch. If a change feels too big to review, it's too big to ship.
When it doesn't apply
A few changes are atomic by nature: a schema migration with its code, or a security fix that only works as a whole. Don't artificially slice something whose parts are meaningless or unsafe apart. Ship it as one reviewable unit and say why.