I've shipped a lot of software over the years. Some of it I'm proud of. Some of it I'm not.
The difference usually comes down to one thing: whether I had the discipline to do it properly, or whether I let pressure push me into cutting corners.
I care about how it's built, not just that it ships. Cutting corners creates future problems.
The pressure to ship
Every project has pressure. Deadlines. Budgets. Stakeholders asking "is it done yet?" The temptation to just get it out the door is constant.
And sometimes shipping fast is the right call. Not everything needs to be perfect. Some things just need to exist.
But there's a difference between:
- Intentionally scoping down to ship something solid faster
- Cutting corners to ship something fragile on time
The first is a legitimate tradeoff. The second is borrowing from the future — and the interest rate is brutal.
What corners actually cost
Every shortcut has a price. You don't always pay it immediately, but you always pay it.
Skipped tests mean bugs that surface in production instead of development. Each one costs more to fix than it would have to prevent.
Unclear code means the next developer (often you, six months later) spends hours understanding what should have been obvious. That time compounds with every change.
Hardcoded values mean manual work every time something changes. What saved five minutes once costs hours over the lifetime of the system.
Missing error handling means silent failures that corrupt data or confuse users. The cleanup is always worse than the prevention.
Quick fixes mean layers of patches that obscure the original design. Eventually the system becomes unmaintainable — not because of any single decision, but because of hundreds of small ones.
Craftsmanship isn't perfectionism
I'm not arguing for gold-plating everything. Perfectionism is its own failure mode — endless polishing instead of shipping, optimizing for imaginary requirements.
Craftsmanship is different.
Perfectionism asks: "Is this flawless?"
Craftsmanship asks: "Is this solid enough to trust?"
Craftsmanship means:
- Writing code that's clear enough to maintain
- Handling the errors that will actually happen
- Testing the paths that actually matter
- Building foundations that can support what comes next
It's not about making everything beautiful. It's about making things durable.
The speed trap
"Move fast and break things" made sense for early Facebook. It doesn't make sense for most of what I build.
When you're experimenting — testing whether something should exist at all — speed matters more than durability. Throw it together, see if it works, throw it away if it doesn't.
But most software isn't an experiment. It's infrastructure. It's going to be maintained, extended, relied upon. The decisions you make in week one affect every week after that.
Fast code that's hard to change isn't actually fast. It just front-loads the speed and back-loads the cost. The total time is often higher than if you'd built it properly from the start.
What I actually do
I scope aggressively. If we can't build it well in the time we have, we build less of it. A smaller feature done properly beats a larger feature done poorly.
I push back on artificial deadlines. Some deadlines are real. Many aren't. I try to understand which is which before accepting pressure that compromises quality.
I build the foundation before the features. Data models, error handling, logging — the unglamorous stuff that makes everything else possible. It's not exciting, but it's what separates systems that last from systems that collapse.
I leave code better than I found it. Not always dramatically — sometimes just a renamed variable, a clarified comment, a small refactor. But consistently. Quality compounds.
I say no to work I can't do well. If the timeline or budget doesn't allow for quality work, I'd rather not do it than do it badly. My reputation is built on what I ship, not what I attempt.
The consulting angle
In consulting, this matters in a specific way.
Clients often push for speed. They have their own pressures — investors, deadlines, competitors. They want it yesterday.
My job isn't to simply comply. It's to help them understand the tradeoffs.
"We can ship this in two weeks, but it'll be fragile. When you want to change it later — and you will — it'll cost more. Or we can take three weeks and build something you can actually build on."
Sometimes they choose speed anyway. That's their call. But they make it with open eyes, not false expectations.
The clients I work with long-term are the ones who've learned to trust my judgment on these tradeoffs. They know that when I push back, it's not because I'm slow — it's because I've seen what happens when corners get cut.
The principle
I take professional pride in how things are built.
Not vanity — utility. Clean architecture makes teams faster. Correct logic prevents silent failures. Proper foundations support future growth.
Cutting corners isn't actually faster. It just moves the cost from now to later, with interest.
I care about how it's built, not just that it ships. Because what ships today is what someone maintains tomorrow.
If it's worth building, it's worth building properly.