Why Reducing Absolutism Boosts Engineering Judgment

I have written many pieces urging programmers to avoid blindly following trends and to develop their own judgment; long‑time developers who still cling to the idea that one technology is always superior are missing the point. Real‑world development experience—hitting pitfalls and learning from them—cultivates this judgment.

Software engineering rarely has absolutely correct answers; it is about making reasonable choices under various constraints.

First, architecture matters far more than code tricks. Younger developers often focus on code details such as naming conventions, proper use of design patterns, and elegance. While important, the long‑term viability of a system hinges on a sound overall architecture. As I often say:

In architecture design, ensure system stability first, then worry about code details.

For example, in a payment system each payment channel is treated as an independent unit; early on we guaranteed that a failure of WeChat would not affect Alipay. If we had not done this, even perfectly written WeChat‑payment code would be useless because a WeChat outage would cascade and potentially bring down the entire payment platform. The more core a system is, the more critical its architectural design becomes.

Second, clear and simple code usually beats clever, complex code. Developers should not showcase their skill by writing overly clever or intricate code that they think looks advanced. Experience shows that the primary value of code is that others can quickly understand it. The person who writes a module today may not maintain it months later, and the new maintainer may lack the same background. Therefore readability and simplicity often outweigh sophisticated tricks.

Third, do not adopt technology merely because it is advanced. Many real‑world problems do not require complex solutions. For instance:

If a monolithic architecture satisfies the business, there is no need to chase the micro‑service trend.

If a relational database solves the problem, blindly introducing NoSQL adds unnecessary complexity.

Excellent engineers dislike unnecessary complexity and know when to avoid it.

Fourth, best‑practice guidelines must be applied in context. Principles such as DRY, SOLID, and design patterns are valuable strategies for specific problems, not absolute laws. Every principle has applicability boundaries and hidden costs. Blindly eliminating duplicate code can introduce unwanted coupling; forcing complex design patterns on simple scenarios makes problems harder. Mature engineering ability lies in understanding the intent behind these principles and balancing benefits against costs.

Ultimately, engineers should think, judge, and choose the most suitable solution given the current business, team, resource, and time constraints.