There’s a version of “move fast” I believe in. And one I don’t.
The one I believe in: ship early, gather real signal, and let actual use shape the direction. Don’t polish what nobody’s asked for. Get it in front of people.
The one I don’t: sprint past thinking, accumulate debt, and call it velocity.
The problem with permanence
We talk about shipping as if it ends something. It doesn’t. It starts something. The moment code is in production, it begins a different kind of life — people depend on it, build around it, assume it.
The things I’ve regretted most aren’t features I launched too slowly. They’re decisions I didn’t think about carefully enough before they became load-bearing.
The argument for slow
I’ve built in industries where change is expensive — automotive, embedded systems. When you’re programming microcontrollers going into production cars, “move fast and break things” is genuinely not an option.
What that taught me: clarity before commitment. Spend the time on the thinking. Write it down. Question it. Then build it.
That habit doesn’t slow you down. It makes what you build more durable.
What Emma is teaching me
My daughter arrived in March and she is doing something I didn’t expect: she’s resetting my timeline intuitions.
She doesn’t care that I have things to ship. She grows at exactly the rate she grows. And watching that — something so fundamental proceeding so completely outside of my control or preferences — is making me recalibrate what “urgency” actually means.
Some things need to be rushed. Most things benefit from being built carefully.
I’m still figuring out which is which. Probably always will be.