Introduction: Thought Patterns That Interfere With Architectural Decisions
When working in system architecture without external guidance, decision-making depends entirely on your ability to stay clear-minded and focused. Yet clarity is constantly challenged. Certain thought patterns — recurring, subtle, and often embedded in team culture — can undermine productive action.
They don’t announce themselves. Instead, they show up as familiar hesitations, internal arguments, or inherited habits:
- “What if we need this later?” — defers important clean-up decisions and feeds technical debt.
- “Abstraction for abstraction’s sake” — adds complexity without increasing clarity or value.
- “We must do it the right way” — slows momentum under the weight of imagined ideals.
This article is a practical snapshot of recurring thought patterns encountered by architects working in high-autonomy environments. In such contexts, clarity isn’t pre-approved — it’s earned through thoughtful, independent decision-making. Identifying these patterns helps build stronger judgment, reduce friction, and support more confident architectural choices.
Demon 1: “What if we need it later?”
The main supplier of useless layers, DI wrappers, and microservices.
What it says:
- “Make it flexible now. Otherwise, we’ll rewrite everything later.”
- “What if we scale to millions of requests?”
- “What if we have 7 teams next year?”
🛡️ How to fight it:
- Ask: “What do we need this month?”
- Motto: “When ‘later’ comes — we’ll build it. For now — go straight.”
Demon 2: Abstraction for abstraction’s sake
“Add an interface, just in case the class changes.”
What it says:
- “You can’t call a class directly — abstract it.”
- “Add a layer on top of the layer, just in case.”
🛡️ How to fight it:
- Practice: “Use interfaces only when there are real alternatives.”
- Principle: “Keep it simple until it hurts.”
Demon 3: “This is how enterprise does it”
“If Google does it — we must too.”
What it says:
- “Clean Architecture is the only way.”
- “Without CQRS, DI, EventBus — you’re not a real architect.”
🛡️ How to fight it:
- Realize: “Their scale ≠ your scale.”
- Practice: “Write for your reality, not for a mythical industry.”
Demon 4: “Let’s make it perfect — then release”
The guardian of eternal refactoring and dead MVPs.
What it says:
- “Just a bit more — then it’ll be perfect.”
- “It’s embarrassing to show it like this.”
- “We need to rethink the architecture…”
🛡️ How to fight it:
- Test: “Can you show this to a user tomorrow?”
- Motto: “Done > Perfect”
Demon 5: “We must do it right, no mistakes”
The source of decision paralysis.
🧟 What it says:
- “What if this is the wrong approach?”
- “If it’s not SOLID, they’ll laugh.”
- “Check 4 more options before choosing.”
🎯 How to fight it:
- Mindset: “Decisions are not sacred — you can change them.”
- Phrase: “Wrong is okay. Useless is not.”
- Clarification: You always have the right to make a mistake. The real issue is repeating the same mistake three times.
Practices of Liberation
1. Morning Focus Protocol
Before diving into code — remind yourself why you’re doing this.
- Why am I writing this? (Who is it for? What problem does it solve?)
- What can I do simply today?
- Where can I stop overthinking?
🧭 Shift from “engineer of engineering” to “creator of meaning.”
2. Task Mirror
Before adding a layer — ask:
- Does this abstraction solve a real pain — or a hypothetical one?
- Am I complicating out of fear or necessity?
- Can I solve this right now in a simpler way?
📌 Put this in your IDE as a snippet or sticky note.
3. Release Pressure from Perfectionism
“Code doesn’t need to last forever. It needs to work now — clearly and usefully.”
| ⛔ Not Needed | ✅ Enough for Today |
|---|---|
| Perfect | Useful |
| Architecturally fancy | Architecturally clear |
🧭 Designing for eternity is a trap. In fast-moving environments — where frameworks shift, APIs deprecate, and teams evolve — even well-crafted code can become legacy within 2–3 years. Your product doesn’t need to last forever. It needs to be clear today, useful tomorrow, and replaceable when the world moves on.
4. Log of Useful Traces
At the end of the day — not “what I did,” but “what became useful.”
Examples:
- Simplified generator template — less confusion
- Added examples to README — easier to use
- Removed extra DI layer — easier to read
🧠 Why it's useful to log what became useful: You’re training your brain to notice value — not just effort. By shifting focus from “what I did” to “what helped,” you build mental patterns that prioritize clarity, contribution, and self-trust. This reduces stress in high-pressure situations. You’re not just working — you’re learning. Not just how to deliver outcomes, but how to shape your way of being. Each log is proof that progress can be simple, even when circumstances aren’t.
Top comments (9)
In your Morning Focus Protocol, it's interesting that you recommend shifting to "creator of meaning" rather than "creator of value". From your perspective, what does "meaning" mean in this context?
It’s a bit abstract and philosophically twisted, of course 😊, but the main idea here is that value means focusing on results, while meaning is more like a direction — something connected to a movement vector.
When you’re not chasing a specific outcome, but instead following a direction and living in the present — not just in a dream of the future — this kind of approach helps you avoid burnout.
That’s what I mean.
Sounds similar to how I've started differentiating between goals and intentions. Intentions are flexible guides that allow daily adjustments while still going in a, dare I say it, meaningful direction :-) Good article, my friend.
This post feels like a parent scolding a child for no appeared reason, and then giving the child chores to do.
The teams can be trusted to make their own decisions, but not without the need of an architect?
Demon 1: most developers know the YAGNI acronym
Demon 2: writing more code without benefit is for beginners and AI
Demon 3: the opposite is more likely to happen, it works lets ship it. And it can be as bad as perfection.
If you need more than one DI layer you are doing DI wrong.
When teams experience those problems I think the mix of developers is off. And that should be fixed instead of adding a new role.
“The teams can be trusted to make their own decisions, but not without the need of an architect?” Yes, they can. And they should. But this article is not about teams — it’s about the autonomy of the individual programmer.
When you're a developer, not just a technical writer, and you're asked to build a something module, make decisions, or choose a structure — you are already acting as an architect. And in that moment, you face certain patterns:
fear of “what if we need this later”
desire to “make it look professional, like in enterprise”
habit of “adding another layer because it’s common practice”
Many people talk about how not to violate YAGNI, KISS, TSTTCPW, APOP — but few explore why it keeps happening in the first place. If you already recognize these demons and you actively resist them when they whisper complexity, that’s architectural thinking — not because you wear the badge, but because you’ve learned to think that way.
This is not a scolding. I’m simply sharing what I wish I had at the beginning of my journey.
If it is about an individual programmer, I would replace we with I/you where you added it.
What is wrong being a technical writer?
Enterprise code is more a derogatory term when I talk to other developers.
No developer likes layers because they make debugging harder. Adding a layer is not a light decision.
If you don't ask questions about common practices, AI is replacing you.
If that is not underestimating developers, I don't know what is.
I understand you want to share your knowledge. I think the way you communicate can be improved. That is why I'm commenting.
There’s nothing wrong at all. My text doesn’t judge the role — that’s your interpretation.
A technical writer doesn’t usually make architectural decisions, and that’s not a flaw. In fact, sometimes it’s a relief not to carry that responsibility.
If you’re curious to explore this more deeply, I’d recommend reading about cognitive biases.
That’s exactly what this article is about — how these patterns show up in our work, not because someone is “bad,” but because they’re human.
You wouldn’t blame yourself for feeling hungry, right?
Thanks — that’s really helpful. I’ll keep working on it.
P.S. I don’t believe AI will replace developers. In fact, it might not survive if we keep feeding it endless layers of legacy code and the versioning chaos of modern frameworks. Right now, AI is chasing a horizon it may never reach.
How does your text not judge a technical writer as you put that role next to a developer role and added the word just? What other interpretation is there in that sentence?
The whole technical writer part is unneeded to prove your point.
So you keep hammering on those patterns, avoiding the elephant in the room.
So only a few people are not biased? What do you consider to be a few?
I don't believe that either. My comment about AI has to do with challenging common practices. AI thrives when you want to use it for common practices, because it learned that is the output that is wanted. And you can't generate code as fast in that case. So that is why in that case you can be replaced.
You're right: the phrase “not just a technical writer” can sound reductive. The goal was to highlight a shift in responsibility — not to diminish any role. I’ll be more precise going forward.
When I say “few explore why,” I’m pointing to a pattern I’ve observed — not a judgment. In fast-moving environments, it’s common to rely on what’s familiar or proven. That’s not carelessness, it’s survival. But sometimes, a moment of reflection — asking why this pattern, why now — can reveal deeper options. The goal isn’t to elevate anyone, but to open space for that kind of questioning.
Thanks again. This kind of critique doesn’t weaken the message — it strengthens it. I’ll keep refining.