文章指出，在工程团队中，过度设计的工程师往往比追求简洁的工程师更容易获得认可和晋升。简洁方案虽高效可靠，却因缺乏"故事性"而难以在晋升评估中凸显价值，导致企业无意中鼓励了复杂化倾向。

标题：无人因简洁而晋升

原文链接：https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/

发布时间：2026年3月3日

核心问题：过度工程化被奖励，简洁设计被忽视

荷兰计算机科学家Edsger Dijkstra曾指出："简洁是伟大的美德，但实现它需要艰苦努力，而理解它需要教育。更糟糕的是，复杂性反而更畅销。"这一观点揭示了工程团队中普遍存在的隐性问题——过度设计的工程师往往能获得晋升机会，而选择最简单有效方案的工程师却得不到认可。

典型案例对比

• 工程师A：用50行代码快速交付功能，方案简单易维护，但晋升材料只能写"实现了X功能"。
• 工程师B：花费三周构建"可扩展"架构，引入消息队列和抽象层，晋升材料充满"事件驱动架构""可复用抽象层"等术语。

系统性偏见的三重表现

1. 面试环节
   • 提出简单方案常被质疑扩展性，被迫添加分布式系统等复杂设计才能通过考核。
2. 设计评审
   • "是否需要未来验证？"的质疑迫使工程师提前添加未必要的抽象层。
3. 代码实践
   • 为消除几行重复代码而引入的抽象，往往导致更难维护的系统（参见"重复不是敌人"的案例）。

关键区分：必要复杂度 vs 过度设计

• 合理场景：处理百万级交易确实需要分布式系统
• 问题本质：提前为三年后可能的需求分库分表，就是典型的"未经验证的复杂度"

解决方案建议

对工程师：
- 用决策过程彰显价值："评估三种方案后选择最简单且满足需求的实现"
- 在评审中量化成本："现在添加该层需要2周，未来改造仅需3天"
- 主动与管理层沟通工作价值的呈现方式

对技术管理者：
- 改变评审问题："最简单的可行方案是什么？何时需要更复杂方案？"
- 在晋升评估中追问："这些设计是否真正必要？"
- 公开表扬删减代码、拒绝过度设计的工程师

本质矛盾

资深工程师的真正能力不在于掌握多少工具，而在于懂得何时不用它们。当前激励机制却反向操作：
- 复杂度自带"聪明光环"
- 简洁方案因"看起来简单"而隐形
- 晋升体系默认用"构建规模"衡量影响力

终极结论

当组织持续奖励复杂度时，就会得到复杂的系统。改变的方法其实很简单——而这正是本文的精妙反讽。

（注：保留原文核心论证结构，删减了部分重复例证，优化了中文表达节奏，关键术语如"unearned complexity"采用情境化翻译）

以下是评论内容的总结：

支持简单解决方案的观点

1. 简单方案更受认可

   • cyberax：因用简洁实现替代多个服务而获得晋升
   • ChadMoran：通过跨平台小改动实现9位数收入，初期被低估但最终因价值获认可
     > "I was promoted for getting rid of multiple services"
     > "It's a bit of marketing you have to do to help bring people along"

2. 简单方案的实际优势

   • rvz：复杂架构常因协作成本高而成为隐患
   • kstrauser：多次因提出数据库替代方案等简单方案而晋升
     > "architecture was built on a bad foundation, riddled with brittle parts"
     > "Why are we jumping through hoops...? Uh, can I introduce you to PostgreSQL?"

质疑简单方案受认可度的观点

1. 复杂方案更易体现价值

   • dfxm12：晋升关键是如何包装工作成果，而非方案本身
   • scuff3d：用GPT生成的"50行代码解决方案"套话就能满足管理层
     > "how well you promote your work is the most important metric"
     > "Any management nitwit would eat that up on a performance eval"

2. 组织机制问题

   • sssilver（前EM）：晋升取决于可量化的"战争故事"而非代码质量
   • losalah：复杂方案因有文档/演讲等更易体现"影响力"
     > "Their manager wants a war story with dramatic character development"
     > "Guess which one looks like 'impact' on paper"

中立/平衡观点

1. 经验与简单性的关系

   • danpalmer：资深工程师更倾向简单方案，但需数据验证
   • RevEng：面试中会主动寻找能平衡简单与扩展性的工程师
     > "more experienced engineers are the ones driving simplicity"
     > "YAGNI is a real consideration"

2. 实现简单的挑战

   • litchinn：简单设计需要丰富经验和持续重构时间
   • shevy-java：UNIX哲学虽简单但组合后仍会产生认知负荷
     > "You need sufficient experience and a deep understanding"
     > "Simplicity is great but it is orthogonal to features"

其他重要观点

• 组织文化差异：semiinfinitely指出优秀组织会奖励工程卓越（"culture rewards engineering excellence"）
• AI影响：cube00担忧AI可能加剧过度设计（"I worry this is the kind of boiler plate they'll be creating"）
• 行业差异：jjmarr称竞争性行业更看重实际业务影响（"we cannot afford to waste time on unnecessary complexity"）

总结：评论普遍认为简单方案在技术层面更优，但在组织晋升机制中常处于劣势，核心矛盾在于价值呈现方式与现行评估体系的不匹配。