Notes on shipping small

Every team I have worked on agreed that small pull requests are better. Very few of them actually shipped small pull requests. The gap is not about knowing; it is about habits that make small the default instead of a discipline you have to remember.

Separate the refactor from the change

The most common reason a change balloons is that the code was not ready for it. You wanted to add a flag, but the function was 300 lines long, so you cleaned it up on the way. Now the reviewer has to read a refactor and a behavior change at once, and cannot tell which line caused which effect.

Do the refactor first, in its own pull request. It should be boring. Boring refactors get approved in minutes.

Make the new path unreachable

Ship the new code with no way to reach it. Then ship the switch. This sounds like more work, but it means the risky part, the deploy, happens when nothing can go wrong.

export function shouldUseNewCheckout(user: User): boolean {
  // Stage 1: always false. Stage 2: a percentage. Stage 3: delete this function.
  return false;
}

The comment is the plan. Anyone who reads the code knows what happens next.

Review your own diff before asking

Open the diff as if you were the reviewer. Almost every time, you will find a debugging line, a rename you forgot to finish, or a file that should not be there. Fixing those first saves a round trip and makes the reviewer’s first pass count.

Keep a list of things you did not do

While working, you will notice five other things worth fixing. Write them down in the pull request description under “Not in this change” and move on. It tells the reviewer you saw them, and it gives you a ready-made queue of small follow-ups.

What this buys you

Change size	Typical review time	Rollback cost
Under 50 lines	Minutes	Trivial
50 to 300	Hours	Manageable
Over 300	Days	Painful

None of these habits are clever. They are just cheaper than the alternative, and once they are automatic, “small” stops being something you have to argue for.