I spent a week trying to ship as many pull requests as I responsibly could, partly as an experiment and partly because the backlog had gotten personal. Fifty merged PRs later, the lesson wasn’t what I expected. The constraint on throughput was never how fast I could write code. It was everything around the code — review latency, branch hygiene, the half-hour tax of context-switching, and the slow accretion of work-in-progress that nobody had finished.
Velocity, it turns out, is mostly a property of your workflow, not your fingers. The teams that ship fast aren’t typing faster. They’ve removed the friction between “this change is done” and “this change is live,” and that friction lives in surprising places.
Three habits did the heavy lifting. Keep every diff small enough to review in five minutes. Keep every branch to a single task so work never piles up half-finished. Trust the tests enough to stop hand-checking each change. None of it is about working harder.
Small diffs are a velocity technology
The biggest single change was shrinking my pull requests. A 600-line PR sits in review for a day because no reviewer wants to start it; a 40-line PR gets reviewed in the gap between two meetings because the cost of looking is low. Review latency is a function of diff size far more than diff difficulty, and review latency is the real bottleneck in most teams.
Small diffs compound. They merge faster, so they conflict less, so rebasing is cheap, so you ship the next one sooner. They’re easier to revert, so shipping them is less scary, so you ship more readily. They isolate failures, so when something breaks the bisect is short. The whole system gets faster because each unit of work is small enough to flow through it without clogging.
The fastest way to ship more is to ship smaller. A diff small enough to review in five minutes is a diff that’s already half-merged. — the rule that ran my whole week
One task, one branch, one PR
The second thing that mattered was refusing to let work pile up in the working tree. Every task got its own branch off the latest main, did exactly one thing, and opened exactly one PR. No “while I’m in here” detours, no two features sharing a branch, no half-finished experiment blocking a finished fix.
# start clean off the latest main, every single time
git fetch origin main
git switch -c fix/specific-thing origin/main
# ... one focused change ...
git push -u origin fix/specific-thing
gh pr create --fill # one task, one PRThis sounds rigid and it’s actually liberating. When each branch is one task, an in-progress change never blocks a finished one — you just switch branches. When a review comes back with comments, you address them in isolation instead of untangling them from three other things you’d started. The discipline of one thing per branch is what let me have a dozen changes in flight without any of them stepping on the others.
Speed is safe only when the safety net is automatic
None of this would have been responsible without tests and CI doing the worrying for me. Shipping fifty changes by hand-verifying each one would have been reckless; shipping fifty changes where every one ran the full suite and couldn’t merge red was just fast. The thing that makes velocity safe is automation you trust enough to not double-check.
That trust has to be earned. A flaky test suite is worse than no suite, because it teaches you to ignore red, and a team that ignores red eventually merges something genuinely broken. The week worked because the suite was fast and honest: green meant safe, red meant stop, and there was no third state where I had to use judgment about whether a failure was “real.”
The real takeaway is almost anticlimactic. High throughput didn’t come from working harder or cutting corners. It came from making each change small, each branch isolated, and each safety check automatic — and then letting the system do what a well-built system does, which is get out of your way.