Ask someone why a project is moving slowly and you’ll usually hear about the size of the work — too many features, not enough hands, a hard problem. Those matter, but they’re rarely the thing actually setting the pace. Most of the real speed of building software is set by something quieter: how long it takes to go once around the loop of making a change, seeing what that change did, and learning enough from it to decide the next change. Everything you do passes through that loop many times, so its cycle time multiplies across the whole project. Shorten the loop and everything gets faster at once; leave it long and no amount of effort inside it helps.

The loop is easy to overlook because each turn of it feels like overhead rather than progress. You made the edit — that was the work. Waiting for the build, running the thing, poking at it to see whether it did what you meant, reading the output to figure out what actually happened: all of that feels like tax on the real work. But it isn’t tax, it’s the mechanism by which you find out if the work was right, and you cannot skip it — you can only pay it quickly or slowly. A change you can test in three seconds and a change you can only test by waiting ten minutes for a deploy are not the same change. The second one is dramatically more expensive, not because the edit is harder but because every time you’re wrong — which is often — you pay the ten minutes again.

This is why the length of the loop compounds so brutally. Being wrong is the normal case in programming; you rarely get a nontrivial change right on the first try, and you shouldn’t expect to. So the number that governs your speed isn’t how long a correct change takes, it’s how long a wrong change takes to reveal itself and get corrected. If the loop is fast, being wrong is cheap — you try, you see, you adjust, and the wrongness barely costs anything. If the loop is slow, every wrong guess is expensive, and since most guesses are wrong at first, the slowness lands on nearly every step. Two developers of equal skill can differ enormously in output purely because one is going around a ten-second loop and the other a ten-minute one.

The practical consequence is that shortening the loop is often the highest-leverage thing you can do, and it’s usually undervalued because it doesn’t look like feature work. A test that isolates the thing you’re changing so you can check it in isolation, a way to run the code locally instead of waiting on a shared environment, a faster build, a REPL, a script that reproduces the bug in one command instead of twelve manual steps — each of these attacks the cycle time directly, and each one pays off on every future turn of the loop, which is to say constantly. Time spent making the loop faster is almost never wasted, because you’re not saving one step, you’re saving a fraction of every step you’ll ever take in that code.

So when something feels slow, it’s worth asking a different question than “how do I do this work faster?” Ask “how long is my loop, and why?” Often the honest answer is that you’re spending most of your time waiting to find out whether the last thing worked — and that the fix isn’t to think harder or type faster, but to make finding out cheaper. The developers and teams that feel fast usually aren’t doing less work or making fewer mistakes. They’ve just built themselves a loop so short that mistakes barely slow them down, and that short loop, more than talent or effort, is what the speed is made of.