A colleague told me a story recently. A new architect joined his project. Experienced, credentialed, confident. And from day one, all he did was explain what was wrong with the existing system. The choices that were made, the patterns that were used, the technical debt that had accumulated. An endless inventory of flaws.
I've seen this before. And it always makes me uneasy.
Not because criticism is bad. Codebases do accumulate real problems. Patterns do become outdated. But there's a specific kind of criticism — reflexive, premature, delivered without curiosity — that reveals something troubling about the person offering it.
The most dangerous person in a technical team isn't the one who doesn't know enough — it's the one who arrives certain they know better.
Every system is a set of scars
Software systems carry history inside them. A module that looks over-engineered almost certainly went through a painful incident that demanded it. A seemingly arbitrary constraint probably has a business reason buried three layers deep. A workaround that offends your sensibilities was likely someone's pragmatic solution to a real deadline under real pressure.
When you arrive somewhere new and start cataloguing what's wrong, you are, maybe unintentionally, dismissing the judgment and effort of everyone who came before you. You're saying: I, having spent two weeks here, see things more clearly than the people who spent years building this.
Before you tear down a fence, find out why it was built.
This principle has a name in software engineering circles: Chesterton's Fence. It's the idea that you should understand the reason a thing exists before you remove or change it. The fence wasn't put there randomly. Someone had a reason. Your job, before anything else, is to find out what it was.
Applied to software: if a pattern, constraint, or design decision seems wrong to you, that's a signal to ask questions — not to start rewriting.
Amazon made it a leadership principle
This isn't just philosophy. Amazon codified something close to this in one of their original Principal Engineer tenets: respect what came before. The core idea is that senior technical leaders, precisely because they have more power to change things, need to carry an acute awareness of what they're changing and why it came to be.
A principal engineer who walks into a codebase and immediately starts advocating for a rewrite isn't demonstrating strength — they're demonstrating impatience. The real signal of seniority is knowing when to slow down, ask questions, and sit with the discomfort of not yet understanding something.
Curiosity is the prerequisite
The attitude I actually want from a new architect, in fact from anyone joining a mature system, is curiosity first. Before opinions, before recommendations, before assessments: questions. Why is this structured this way? When was this decision made, and what were the constraints at the time? What has been tried before and didn't work?
Those questions aren't just polite. They're how you build an accurate mental model of the system. And without an accurate mental model, your architectural opinions are just guesses dressed up in confidence.
There's also a human dimension that's easy to overlook. The people who built the existing system are often still on the team. When you criticize the code, they hear you criticizing their past selves — the choices they made when they were doing their best with the information they had. Earning the right to critique means first demonstrating that you've taken the effort to understand.
None of this means you can't change things
Respecting what came before doesn't mean defending every legacy decision forever. It doesn't mean paralysis or uncritical deference. Systems do need to evolve. Bad patterns do need to be replaced. Technical debt does need to be paid down.
The difference is in the posture. There's a meaningful gap between "this is wrong" and "I notice this pattern. Help me understand the tradeoffs behind it." One closes doors. The other opens a conversation. And most of the time, the conversation reveals something important that changes, or at least sharpens, your original assessment.
The architects I've admired most over the years all had this quality: they moved carefully. They asked more than they told, especially early on. They accumulated understanding before they accumulated opinions. And when they did advocate for change, it landed. Because everyone could see they had done the work to earn it.
That's a standard worth holding ourselves to.