If the speed of building is set by how long it takes to go once around the change-see-learn loop, then the natural next question is what to do about a loop that’s too long. The common instinct is to get better at the work inside it: think more carefully before each change so you’re wrong less often, read the code harder, plan more. That helps a little, but it fights against a stubborn fact — you’re going to be wrong a lot no matter how careful you are, because the hard part of most changes is exactly the part you can’t fully reason about in advance. The higher-leverage move is usually not to reduce how often you’re wrong, but to reduce how much each wrong turn costs. That means attacking the length of the loop directly, before optimizing anything inside it.

The distinction matters because effort spent inside a long loop is capped by the loop. Suppose you get 20% better at writing correct code on the first try — genuinely hard to do — but your loop is ten minutes long because every check requires a full deploy. You’ve shaved a fraction off an already-small number of iterations while every remaining iteration still costs ten minutes. Now suppose instead you spend that same effort making the loop thirty seconds long: a local reproduction, a focused test, a way to run the one piece you’re changing in isolation. You didn’t get any smarter, but every single iteration for the rest of the project got twenty times cheaper. The second investment dominates the first, and it keeps paying while the first is a one-time bump.

This is why “make the loop shorter” should come before “make myself better at the loop,” and it’s a genuinely different kind of work. Shortening the loop is infrastructure work — it’s building the test harness, the local environment, the one-command repro, the fast build, the ability to poke at a running piece of the system without standing the whole thing up. None of it looks like progress on the feature, which is exactly why it gets skipped under pressure, and skipping it is how a team ends up permanently slow. The cruel irony is that the slower the loop, the more it feels like you can’t afford to stop and fix it — but the slowness is precisely the thing bleeding you on every step, and the pause to fix it usually pays back within the same day.

There’s a useful diagnostic for whether you’re in this trap: notice how you feel about making a small change and checking it. If verifying a one-line change is a chore — if it means a deploy, a wait, a manual walk through the UI, a re-run of something slow — your loop is too long and no amount of care inside it will rescue you. Healthy loops make the act of checking so cheap that you do it constantly, almost without thinking, which in turn lets you take smaller steps and stay oriented. Long loops push you the other way: because checking is expensive, you batch up many changes before testing, which means when something breaks you’ve got a large ambiguous surface to search, which makes each turn even more expensive. The loop length and the batch size feed each other, in whichever direction you’re already going.

So when things feel slow, resist the urge to just try harder inside the existing loop. Ask first whether the loop itself can be cut — and treat that cutting as the real work, not a distraction from it. Getting better at programming inside a ten-minute loop makes you a better programmer trapped in a slow process. Turning the ten-minute loop into a ten-second one makes everything you do faster at once, including all the future getting-better you’ll do inside it. Optimize the container before you optimize the contents, because the container multiplies everything you put in it.