Building well is not slower than building fast

There's a false dichotomy that persists in software development: you can build fast or you can build well, but not both at the same time.

That's not true. Most of the time, building badly is slower.

What we confuse with speed is frequently deferral. Skipping tests, hardcoding a value, copying code without understanding it: all of this gives speed in the moment and takes it away multiplied later. Technical debt isn't a metaphor; it's literal. It has interest.

What actually accelerates development is clarity: knowing exactly what you're building before you start building it. A well-designed system is easier to change. A well-written test gives you confidence to move it. A clear API reduces the error surface.

When I start a project, I take the time it would take to design the structure correctly. Invariably, that time comes back to me with interest two weeks later, when I need to add something that wouldn't have fit in the first version.

I don't always manage to build everything well. But recognizing when I'm choosing speed over quality — instead of doing it without noticing — is already half the problem solved.