There’s a phrase I often tell my developers, half in jest, half in resignation, but still entirely true:

“Working published code covers all sins.”

It’s not a license to write garbage. It’s not a rejection of testing, security, or design patterns. But it is a recognition of what ultimately matters: shipping software that works. Software that users can touch, product managers can demo, and customers can rely on.

In the end, our industry is obsessed with potential. With ideals. With chasing the cleanest implementation, the most efficient solution, the perfect architecture. These are good things to pursue. But there’s a danger in perfectionism. A trap in waiting for code to be flawless before calling it done. I’ve seen great features die in the sprint backlog because they were never quite “ready.” I’ve seen months lost to rewrites, while the competition quietly won the market by shipping a slightly worse, but actually usable, version.

The Code That Ships Is the Only Code That Matters

This phrase, working published code covers all sins, isn’t about cutting corners. It’s about prioritizing impact. If your code is beautifully written but never merged, it’s just art. And art has its place, but our job as developers is not to paint. It’s to solve problems, tangibly, in production, with buttons people click and APIs that respond and background jobs that actually run.

Working code, even when it’s rough, gives you something to stand on. It becomes the platform for conversation, iteration, and eventually, improvement. You can refactor a working system. You can optimize it, test it, document it. But you can’t improve what doesn’t exist.

How It Ties Into Agile and OKRs

Agile, when practiced well, values working software over comprehensive documentation. It’s one of the core tenets of the manifesto, but also the one teams forget when they’re knee-deep in grooming sessions, burn-down charts, and endless story points.

In a healthy agile rhythm, every sprint should yield something tangible. A feature that lives in production. A bug that’s been fixed. Momentum. That’s the spirit behind incremental delivery. Not perfection, but progress.

OKRs follow the same logic. They’re not about effort, they’re about outcomes. “Refactor the authentication module” is not a Key Result. “90% of users complete login in under 2 seconds” is. The first might be necessary, but the second is what moves the business. OKRs reward impact, not intent.

So when a junior dev quietly admits, “I know it’s not the cleanest, but it works,” I don’t correct them. I thank them. Because they’ve moved the needle. They’ve taken a vague idea from a ticket and turned it into a real experience someone else can use.

The Path Forward

Shipping is not the end. It’s the beginning. I still expect us to return to the rough edges. We write tests. We measure performance. We optimize queries. But we do that after we’ve proven value, not before we’ve shipped a single line.

There’s a rhythm here. Ship first. Polish second. Show the world something real. Then show them something better.

Because in the end, we are judged not by the elegance of our code, but by the usefulness of our systems.

So yes, working published code covers all sins. And more than that, it lights the path to real excellence, one commit at a time.