Synopsis

while true; do ship; question; adapt; done

Description

There are two tribes and they hate each other.

One says move fast and break things. Ship daily, ship ugly, momentum is the only moat. The other says measure twice, cut once. Slow down, think, don’t make a mess you have to clean up later.

Both are half right, the way a person can be half-smart. Not good either way.

Ship fast with nothing else and you build the wrong thing at high speed. Be careful with nothing else and you die slowly while someone less careful learns faster than you. The two camps are arguing about the wrong axis. Speed isn’t the opposite of rigor. Rigor at speed is the point, and it only works when you know where you’re going. You can drive 200mph, but you have to know the direction.

The loop I run: ship fast, adapt faster, question everything.

Everyone says AI made them ship faster. Be honest: it’s net faster, not way faster. The real shift isn’t speed per feature. It’s that a feature that used to need a team of ten to spec, crowd-write, and review, you can now hold in your head and build alone. So the pile of things you could build exploded. And that’s what killed “we’ll fix it later.” When MVP and MVP+1 land in the same PR, fully unit-tested, every time, “later” stops being a phase. It’s just a lie you tell to ship a mess.

Ship fast

The point of shipping fast is to give users the thing and get feedback fast. It’s not a race to the finish line.

Unshipped code is a theory. It’s a thing you believe is true about the world that the world has not yet confirmed or denied. Every day it sits on your machine, you pay interest on a guess. Shipping is how you turn the guess into a fact. Good or bad, but a fact you can act on.

So ship before it’s ready, because “ready” is a feeling and feelings lie. Ship the embarrassing version that’s true over the polished version that’s hypothetical. The embarrassing one teaches you something this week.

Adapt faster

This is the verb everyone in the move fast camp forgets.

Shipping fast is worthless if you won’t change course faster. Defend every decision like it’s load-bearing and you might end up good, but slow. The speed that counts is how fast you drop the calls that turned out wrong.

The most expensive bug is building the wrong thing perfectly. You don’t fix that bug with better code. You fix it by being willing to throw the code away the moment the feedback says you bet wrong. Don’t marry the build. The build is a hypothesis you’re trying to kill, and the faster you kill the bad ones, the faster the good one survives.

Everyone agrees the hard part now is knowing what to build. The catch: the answer usually shows up after you build it, not before. So the moat isn’t a great idea. It’s the speed at which you can destroy your own. Killing your ideas faster than you make them used to look like overthinking. Now it looks like an edge.

Question everything

Ship fast and adapt faster are the engine. Questioning is the steering.

A few weeks ago my own site was lying to people. www.yankovs.com loaded with a clean padlock. yankovs.com, the bare domain, threw a browser security warning. Same site, two doors, one of them screaming insecure.

The fast fix is obvious: the certificate is stale, click renew, move on. That fix would have failed, and I’d have clicked renew again, and again, and learned nothing.

So before touching anything: why is only the apex broken? That one question did all the work. The apex was serving the wrong certificate because the certificate authority could never verify the domain. And it couldn’t verify because the domain was quietly resolving to three different IPs, two of them stale parking records injected by a forwarding setting I’d turned on years ago and forgotten. The renew button was never the problem. The actual problem was somewhere else entirely, and the only way to see it was to refuse the obvious fix and ask why first.

Shipping fast gets you to the bug. Adapting fast gets you off the bad approach. But question everything is the part that points you at the right wall before you start banging your head on it. Small steps, lots of questions. The most expensive debugging session is the one solving a problem you don’t actually have.

Exit status

Run all three at once, each at its own speed. Ship at the speed of “good enough to learn.” Adapt at the speed of the feedback. Question constantly, in the background, especially when something is working. Especially then.

And none of it counts until someone else uses it. You can ship and adapt at light speed and still hit the one limit that won’t move: a human needs time to live with the thing before their feedback means anything. The only shortcut is building it so their AI uses it too. Then even validation speeds up.

The joke at the end of it: if everyone moves at light speed, nothing is fast. It’s all relative. We sped everything up and landed right back at normal. Running flat out, standing still.

See also

ls ~/blog, building-a-terminal-blog(1)