👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
“Architects don’t code.”
I’ve heard this sentence too many times.
And every time, I worry.
Because the moment someone thinks coding is beneath them, they are already moving away from the thing they’re supposed to understand.
The code.
The good ones
The best architects I’ve worked with never stopped writing code.
They reviewed pull requests.
They paired with developers when something got stuck.
They built the first few features of what they designed.
They understood the pain developers faced because they experienced it themselves.
"Coding is below me"
In many companies, an “architect” is what you get when there is nowhere else to go except management.
The architect stops coding. Not because the job doesn’t need it, but because the title says they’ve outgrown it.
Then the calendar fills up. Meetings, roadmaps, steering committees.
A year later they are deciding how the system should be built, without knowing how it is built.
“But nobody writes code by hand anymore”
This is where someone brings up AI.
If developers are generating most of the code, why should an architect write any?
Because typing the code was never the point. Knowing how the system is actually built was.
You can know that without writing every line yourself. You can’t know it without reading any of it.
Someone still has to notice that logging is now done three different ways in three different places. Or validation. Or error handling. Nobody told the model how this codebase does any of it, so it picked something reasonable each time.
What you want is consistency in the design itself: the same kind of problem solved with the same structure everywhere, so that a developer who has read one part of the codebase can predict what the next part looks like. No diagram gives you that. It comes from someone reading the code and saying, we already have a way of doing this, use that one.
That work is closer to the code than a diagram ever gets you. An architect who only reviews the design, and never looks at what came out the other end, is exactly as far away as before. The tooling is just newer.
If anything, AI makes it worse. More code arrives, faster, and less of it has been thought about by anyone. Judging whether it fits the system is more work than it used to be, not less.
Don’t become an ivory tower architect
The dangerous architect is the one who designs a system they would never have to maintain.
There is no way to find out what a design costs except to build something in it. Add a feature. Change one that already exists. Fix a bug in it six months later. That’s when you find out which parts of your own design fight you — the layer you have to touch every time, the abstraction nobody can extend without asking you first, the test that takes ten lines of setup before it can assert anything.
And don’t expect anyone to report it back to you.
Developers mostly won’t tell you the design is painful. You’re the architect, you decided it, and to them it’s a given — something to work around, not something to question. The more junior they are, the less likely you are to hear about it at all. What comes back is “it took a bit longer than we thought.”
If you haven’t opened the codebase in months, you’re not designing the system anymore.
You’re describing one.
Join the live training session:
Clean Architecture for Backend Developers
🗓 Aug 26
⏰ 5:00–6:30 PM (CEST)
The worst architects are the ones who stop being developers.
I never understood why some architects and technical managers view coding as some sort of "peasant" activity.
It's an activity that requires high skills and good cognitive ability. I'm proud of my coding skills and I still do a lot of it.
I can't imagine myself ever thinking it's "beneath" me.