Architects Who Stop Writing Code Lose the Ability to Judge a System

In 2022, I attended a technical proposal review. The programmer responsible for the proposal was presenting his design when, halfway through, an architect suddenly interrupted: "Why not use a message center approach? Why call the third-party messaging interface directly in the code?"

My immediate judgment was: this is a PowerPoint architect, completely out of touch with reality.

This type of architect knows many industry best practices and is accustomed to saying "you should use this solution" during technical reviews, throwing out ideas that are entirely detached from the actual situation.

Why This Statement Exposed the Problem

The issue here is not whether the message center direction is correct. Some companies in the industry do build unified message centers that consolidate the sending of SMS, in-app messages, DingTalk messages, subscription messages, and so on. The direction itself is not wrong. The problem is that he didn't know three things.

First, the system had no message center at all. To build one, you'd have to start from scratch — interface protocols, reliability, monitoring, operations, workload, cost, and driving adoption. Every single aspect needs consideration. This is not something you can just casually mention in a review meeting.

Second, building a foundational service from scratch cannot be squeezed into a business requirement as a side task. Business requirements have their own boundaries and delivery timelines. The review is for the technical proposal of this requirement, not for the entire system's technical evolution roadmap.

Third, he hadn't touched code for a long time and had lost awareness of what currently exists in the system, what is truly missing, and which things need dedicated project initiatives.

I also thought of something else at the time: if he thought a message center was so important, why hadn't he planned for it himself? An architect who truly understands the system and has been involved in its construction long-term would either know this was already in planning or would proactively push for a project initiative, rather than casually throwing the problem at the programmer presenting the proposal during a review meeting.

The Foundation of Architecture Design Is Understanding the Code

Architecture design requires judgment and a deep understanding of the system's current state and where it should go next.

What the current system has, what it lacks, where coupling is severe, which areas change frequently, what historical baggage remains, and which problems need dedicated project initiatives. This information is often not visible in documentation; the truly valuable information is often hidden in the code.

For example, whether two modules can be split into independent services requires actually looking at how deeply the code is coupled, how many data tables are shared, and how much logic is intertwined. These things can only be clearly understood by someone who has actually written, modified, and read the code.

Therefore, for an architect to maintain judgment about the system, there is no shortcut — it requires continuously writing and reading code. What you hear from others is incomplete.

Architecture design is built on an accurate judgment of the current state, and that judgment ultimately comes from the code.

What Does Architecture Rely On After Leaving the Front Lines?

If you no longer write code and no longer frequently read code, what can architecture design still rely on?

What remains is usually two things: industry practices and past experience.

Industry practices are not wrong, but they are choices others made based on their own circumstances. Team size, how the business operates, what the code looks like, how much historical baggage there is — all differ. A solution that suits others may not necessarily suit your own system.

The same goes for past experience. Experience certainly has value, but it corresponds to the system at that time. Years later, the code has changed, the business has changed, the team has changed — what worked in the past may no longer apply.

So, referencing industry practices is not wrong, nor is using past experience. The problem is that you cannot use these things as a substitute for understanding the current code.

There's another interesting phenomenon: why do these kinds of suggestions often appear during review meetings?

Because for someone who no longer writes code, the review meeting might be the only place where they can still directly engage with system details. Not looking at code normally, when they see a proposal in a review meeting, the experiences and knowledge in their mind naturally surface.

The problem is often not that the suggestion is necessarily wrong, but that conclusions about the current system are drawn without sufficient understanding of it.

How to Maintain Awareness of Implementation

Here are a few practical approaches. Those involved in system design can check themselves against these.

• Persist in doing code reviews, especially for core modules. Code review is the most direct way to understand system changes. Many architectural problems are not visible just by looking at design documents. But speak less and listen more.
• Regularly check what has recently changed in core modules. You don't need to read everything from start to finish; pick areas with more changes and look at them. You'll quickly understand where the business is heading recently.
• For newly introduced technical components, build a small prototype yourself first. Only after actually running it will you know whether it's easy to use and whether it fits with the existing tech stack. Reading documentation and doing it yourself are completely different things.
• Participate in the development of some key modules.
• Participate more in troubleshooting online issues; this is an excellent way to understand the system's current state. When real problems occur, how the system behaves and where problems are most likely to arise — after handling a few incidents, the impression will be very deep.

Summary

This is not just an architect's problem. When programmers reach a certain stage, they will increasingly participate in design and reviews, and eventually become the person giving opinions to others in meetings.

At this stage, whether the things you propose are actually useful depends largely on whether you still know what the system really looks like now.

Code won't do the architecture design for you, but it will tell you the true state of the system.