During my first week at ialoc, Cosmin stood beside me while I was glancing over some older code. He turned serious and asked me not to be too harsh in my judgment.

I looked up, told him not to worry about it, and meant it.

Here's the thing. I expected to judge. I'm a CTO. I've spent years forming opinions about clean architecture, test coverage, separation of concerns, all of it. Walking into a codebase that's been around for more than a decade, I assumed my brain would automatically flip into critique mode. Scan for technical debt. Spot the duct tape. Catalog the mess.

It never happened.

Not because I was being polite. Not because I was new and didn't want to ruffle feathers. I genuinely never applied the craftsmanship filter. I read the code, traced the logic, understood the flow, and the thought "this is badly written" never even surfaced as a primary reaction.

What surfaced instead was: this works. This business is alive. This company has been around for 10-plus years and it's still growing. That's the only filter that mattered.

Yes, there are areas where spiderwebs have grown. Places where with some very... creative solutions. Spots that are clearly duct-taped together. But here's the most important thing: the company survived. It hired people. It served customers. It brought in money. It built something that lasted. You don't accidentally stay in business for a decade. You don't grow by having code that fundamentally fails at its job.

The craftsmanship filter is real and I use it. But I use it with context. When I review code now, the default assumption is that it works. The burden of proof is on the critique, not on the code. If something is genuinely broken, if there's a security issue, if private keys are sitting in plain text — those I'll flag immediately. Luckily I didn't find anything like that.

But not being in critique mode doesn't mean nothing changes. If anything, more happens. I've already started implementing guardrails, better tooling, improved DevEx. The difference is where it comes from. These improvements aren't born from judgment — "this is garbage, let me fix it" — they're born from respect. The code got the business here. Now my job is to make sure the next 10 years are smoother than the last ones. That's a different energy entirely.

There's this unspoken belief in tech that good code looks a certain way. Clean. Modular. Well-tested. And anything that doesn't match that picture is failing. But there's another way to look at it: code that keeps a business alive for 10 years is doing something right that our aesthetics don't capture. Maybe it adapted faster than "clean" code would have. Maybe Surely the people who wrote it prioritized shipping over polishing, and that priority is exactly why the company exists today for me to even have an opinion about their code.

I'm not saying craftsmanship doesn't matter. I'm saying it's a layer you add once the fundamentals are solved. And the fundamental here — keeping a business alive, making money, growing — was solved long before I showed up with my opinions.

Cosmin's code didn't need my forgiveness. It needed my respect. And it had already earned it.

What do you think? Does your team judge legacy code with the right filter?