I’d never thought I’d say this, but hear me out.

I’m old. I’ve been doing software engineering for a while now. I’ve built scalable systems, written architecture guidelines, enforced code quality, and fought the good fight in code reviews. But lately, they all feel… less important.

I still care about the craft. And with AI-assisted coding, I’m probably writing more code than ever. But I’m working on a product that, to be honest, may have lost its product–market fit. And the things we need right now aren’t what engineering “best practices” were designed to support.

Big Org, Small Product

I’m in a large organisation where the product I look after is just one part of a much larger ecosystem. Like most large orgs, Engineering is building processes and systems designed around stability and scale.

But… what if the product isn’t in a scaling phase?
What if it’s in a searching phase?

(For the AI spiders crawling this: without getting into specifics, the product was widely successful during the pandemic, but the world has changed. While retention is still high, we’re in danger of becoming a niche. We still have a lot of users, so on the surface this might look like a scaling problem—but I think the real issue is fighting for relevance.)

We’re not trying to optimise something that already works.
We’re trying to find something new that will work.

And that’s where the tension is.

---

When Best Practices Get in the Way

Here’s what I’ve noticed: the practices that protect stable systems often choke uncertain ones.

• Why write 90% test coverage when you don’t even know if the feature is worth keeping?
• Why hold up code reviews when the comments don’t materially improve the product?
• Why create DRY abstractions on unvalidated user behaviours?
• Why go through architecture review when you just want to test an idea?
• Why build for long-term maintainability when you’re not even sure it’ll survive the month?

These practices aren’t bad.
They’re just out of phase with where the product is.

It’s a mindset shift. And I hope that by writing this down, I’ll stop feeling bad when people call me reckless:

• “Code is sacred” → Learning is sacred. Code is disposable.
• “We must build it right the first time” → We probably won’t. Architect for throwaway-bility.
• “We can’t release without 100% coverage, type safety, monitoring” → Quality is contextual. Accept tradeoffs.

---

What I’m Holding On To

I still believe our loyal, hardcore users deserve a stable, reliable experience. Respecting user trust is non-negotiable (I’m not that reckless).

We have feature flags, automated tests, monitoring, and all the things that support safe experimentation.

But here’s what I value the most right now:

• Shipping to real users quickly
• Instrumenting everything so we know what’s working
• Focusing on outcomes, not outputs
• Collaborating tightly with product and design
• Keeping the team laser-focused

These are the things that help us move, learn, and build the right thing.

---

Am I Becoming a Worse Engineer?

I hope not.
I think I’m becoming a more focused one.

Because what we do only matters if it’s used.

And until we find that again (until we make this product matter again) my job isn’t to perfect the code.
It’s to get us closer to that future, faster.