Spend enough time around engineering discourse and you'll notice how often it turns absolute. This is the only correct architecture. You should never use that pattern. Every project should follow these principles. Anything else is bad engineering. It's a comforting way to talk, because certainty is easier to hold onto than nuance — but it doesn't match how the discipline actually works. There's no SI unit for software engineering. No formula that outputs the correct architecture. No checklist that, followed precisely, guarantees good software. What there is instead is a long list of trade-offs, made by people with incomplete information, under constraints that mostly aren't visible to whoever judges the decision later.
It's easy to look at an old system and ask why anyone would build it that way. It's a much more useful question to ask what constraints existed when the decision was actually made. Cloud infrastructure that's now assumed by default might not have existed. The framework in use might have lacked capabilities considered basic today. Regulations, performance envelopes, organizational priorities, and the collective knowledge available to that team were all different, often in ways that are invisible from the outside once enough time has passed.
This is essentially Chesterton's Fence applied to code. G.K. Chesterton's original parable is about a reformer who comes across a fence in a field, sees no obvious purpose for it, and wants to tear it down — met by a more careful response: don't remove what you don't understand until you've gone and found out why it's there. The point isn't that every old decision was correct. Some genuinely weren't, and understanding the reasoning sometimes confirms that a change is exactly right. The point is that "I don't see why this exists" is a starting question, not a finished argument — and legacy code criticized without asking what it was solving for gets exactly the same treatment as a fence torn down by someone who never checked what it was keeping out.
Engineering communities have a well-worn habit of piling onto old systems — who designed this, what were they thinking, this architecture is terrible. It's worth remembering that plenty of these systems were built by experienced people: technical leads, architects, principal engineers making calls under deadline pressure, budget limits, and information nobody in that room had the benefit of yet. It's entirely possible that anyone doing the mocking, dropped into that same room at that same time, would have made the same call. Humility isn't a soft skill tacked onto engineering — it's a pretty direct consequence of taking seriously how much of any decision depends on context nobody outside the room can fully reconstruct later.
Every system accumulates technical debt, and not because the team building it was careless. Business requirements shift. Technology moves. Security guidance changes — sometimes formally and publicly, the way NIST deprecating certain authentication patterns does, and sometimes just by attackers getting better at exploiting what used to be considered safe. Customer expectations move. Every design decision is a compromise struck at a specific moment against a specific set of constraints, and none of those constraints hold still. Fred Brooks made a version of this argument decades ago in his essay "No Silver Bullet", arguing that no single technique or technology eliminates the fundamental difficulty of building software — there's no tool, pattern, or methodology that, adopted once, keeps a system optimal indefinitely. Brooks was writing about a different set of tools than we use today, and the argument hasn't aged out of relevance at all; it's arguably proven itself again with every subsequent "this changes everything" technology since.
A lot of engineering energy goes into searching for the definitive way to structure a project — the correct folder layout, the correct pattern, the correct stack — as though the search just hasn't concluded yet. It has concluded, in the sense that matters: it doesn't resolve to a single answer. Two experienced teams can solve the same problem in genuinely different ways and both end up with something correct, maintainable, and successful. That's not a sign that one of them is wrong and just hasn't been found out yet. It's a sign that the problem had more than one valid solution, which is true of almost every non-trivial engineering problem worth having an opinion about.
A lot of the certainty in engineering discourse is personal preference wearing the costume of objective law. "Every project must use Clean Architecture." "Microservices are always better." "Every class needs an interface." These are opinions shaped by real experience, which is exactly why they're worth listening to — and exactly why they're not universal. A pattern that worked well in one organization, under one set of constraints, can introduce nothing but unnecessary complexity in another. Ask ten experienced engineers how to solve the same problem and it's entirely plausible to get ten different, all-defensible answers, because they're optimizing for different things: simplicity, scalability, delivery speed, operational maturity, developer experience. None of those priorities is inherently wrong. They're different axes in a genuinely multi-dimensional problem, and optimizing hard for one usually means accepting a real cost on another.
Every engineering team develops a philosophy shaped by what's actually worked for them — minimalism, abstraction, explicitness, speed, long-term maintainability. Team leads naturally trust the approach that's succeeded in their environment, and that confidence is earned, not arbitrary. The mistake isn't having that confidence. It's assuming it should generalize automatically to teams operating under a completely different set of constraints, where the same approach might solve nothing that's actually wrong there.
There's a real difference between the two, and it's worth being precise about it instead of using them interchangeably. Principles — reduce coupling, improve cohesion, design for change, protect business rules, avoid unnecessary complexity — hold up across contexts because they describe trade-offs rather than prescribing specific answers. Dogma collapses that into "there is only one correct way," which sounds like confidence and functions like a shortcut around actually engaging with a problem's specific constraints. Engineering that's actually good at what it does tends to hold principles firmly and hold specific implementations loosely — because every abstraction adds cognitive load, every simplification trades away some flexibility, every dependency is a small bet on someone else's future decisions, and no optimization is free. Understanding those trade-offs, specifically, for the problem in front of you, is what separates an engineering decision from a preference asserted with enough confidence to sound like one.
Software engineering was never a competition to discover the one true architecture. It's the ongoing work of making the best available decision under conditions that keep changing, using information that's always incomplete. Legacy systems deserve context before criticism. Current systems deserve humility before certainty, because they'll be someone else's legacy sooner than anyone building them expects. The goal was never to build something that satisfies every engineer's aesthetic preference. It's to build something that solves the problem it exists to solve — and there's no SI unit, no formula, and no universal blueprint that gets to skip the part where you actually understand the problem first.
Hard Skills Get You in the Room. Ownership Is What Keeps You There.
Technical depth gets an engineer into the room. What determines whether they thrive over years is how well they collaborate, absorb feedback, and own outcomes nobody assigned them.
Experience Is Earned, Not Downloaded
Credentials, tutorials, and AI compress the time it takes to encounter an idea. None of them shorten the years it takes to develop judgment about which ideas actually hold up once reality gets involved.