简单，是一种被惩罚的美德

有些工程师，代码一眼能懂，方案简单自然，解决问题干净利落。但他们往往不是晋升最快的人。

因为行业里存在一套隐形规则：复杂代表能力，简单意味着普通。

设计分布式架构、引入消息队列、抽象工厂、微服务网关，看起来很有技术含量；而分析多种方案后，选择最简单的实现，两天上线、半年零故障，最后往往只被概括为一句：“完成了功能开发。”

复杂是可见的。它会留下架构图、文档、PR 和讨论记录。简单却常常没有痕迹。你决定不引入队列、不提前抽象、不为未知需求设计扩展点，这些判断才是真正的工程能力，却很难成为晋升材料。

这种倾向甚至从面试开始。你提出简洁方案，面试官追问百万并发，于是你不断增加缓存、队列和分片。最终大家学会的不是先判断问题规模，而是复杂更容易让人印象深刻。

复杂性本身没有错。真正的问题，是为不确定的未来提前支付成本，把当下的系统变得难以理解和维护。

工程师需要让简单变得可见。不要只说“完成了功能 X”，而应该说明：评估了哪些方案，为什么选择直接实现，交付用了多久，上线后运行效果如何。不做某件事，同样是一项值得记录的技术决策。

Leader 也应该改变评价方式。设计评审时，与其问“是否考虑扩展性”，不如问：“最简单可上线的方案是什么？出现什么信号后，才需要升级为更复杂的架构？”

一个长期奖励复杂、忽视简单的团队，最终只会留下没人敢动的系统、脱离用户的架构，以及越来越臃肿缓慢的产品。

这不是技术债，而是激励债。它比技术债更难偿还。