两个工程师，同一个需求，三周与两天的差距
假设你是个旁观者，站在绩效评估的现场。
左边是工程师A。她接了一个需求，捣鼓两天，写了50行代码，搞定了。简单、干净、好读。后来者接手一看，10分钟就能上手。零bug，零事故，平稳运行半年。
右边是工程师B。他接了类似的需求，花了三周。引入了新的抽象层，写了pub/sub系统，加了配置框架，光PR就开了七八个。设计文档写得漂漂亮亮，演示时满屏emoji。
现在问题是：这俩人一起来评职级，你猜谁会赢？
说实话，答案可能让你有点无语。
工程师B的晋升材料基本是给自己写的："设计并实现了可扩展的事件驱动架构，引入跨团队复用的抽象层，构建了支持未来扩展的配置框架"。这不就是Staff+的模板吗？
工程师A呢？"实现了功能X"。
没了。
三个词。她的代码更好，但没人能看到。你没法为"没写的东西"写出一份漂亮的汇报材料。
这就是问题所在。我们嘴上说"简单是美德"，但系统诚实地在奖励复杂。
面试教会你的第一课：简单不酷
你以为这只是公司文化的问题？不，这事从面试就开始了。
想象一下，你在系统设计面试里。面试官问："设计一个消息通知系统。"
你心想，这不简单吗？一个数据库，一个API，加个缓存层，齐活。
面试官听完，面无表情："嗯，如果用户量到一千万呢？"
你心里咯噔一下。得，加服务。加队列。加分片。 whiteboard上画满了方框，线密密麻麻。
面试官终于点头了。
你学到了什么？简单等于无聊。复杂等于专业。
但说实话，那个简单方案根本没错。它只是不够"性感"。
有个评论说得特别准：有个面试官问两个人来回发邮件改表格怎么办，候选人说我给他们换成Google Sheets。然后全场沉默了五分钟。
因为面试官期待的是你设计一个协作工具，而不是解决实际问题。
设计评审里的"未来-proof"恐惧症
如果说面试是开胃菜，那设计评审才是主菜。
你提了一个干净利落的方案。会议室里有人举手："但我们是不是应该为未来考虑一下？"
这话听着合理，其实是个陷阱。
"未来"是谁？"未来"需要什么？没人知道。但"未来-proof"这个说法像魔咒一样，让所有人瞬间进入备战状态。
于是你回去加了三层抽象，加了配置项，加了灵活到没人能看懂的扩展点。代码确实看起来更"专业"了。但用户拿到功能的时间推迟了三周，下一个接手的人看了半天代码，决定还是重写吧。
有个评论说得特别扎心：
我见过工程师为了避免复制粘贴几行代码而造了个抽象，结果这破东西比当初的复制粘贴还难懂十倍。每次感觉都是对的。代码看起来更"工程化"了。但功能没变快，下一个改代码的人疯了。
复杂度是会上瘾的。它给你一种"我在做正事"的幻觉。
AI正在把这个问题搞得更糟
老实说，这事以前就有。但AI来了以后，情况变得更魔幻了。
现在，AI能在5分钟里生成一个"可扩展的事件驱动架构"。注意，AI不知道你需不需要这个，它只是知道这类词组合在一起看起来很厉害。
于是工程师B的产出更快了，方案更炫了，晋升材料写得更快了。
但维护成本呢？调试呢？凌晨三点的故障排查呢？新人上手的学习曲线呢？
这些成本一分没少，甚至可能更多了。
有个评论说得好：
AI是才华的放大器。如果你是个经验丰富的开发者，AI帮你更快做出好东西。如果你是个半桶水，AI帮你更快造出更难收拾的烂摊子——而且你可能根本意识不到。
复杂度生成的门槛降低了，但复杂度的代价从来没变过。
谁是真正的Senior？
文章里有句话我特别认同：
真正的进阶之路不是学更多工具和模式，而是不用它们。
谁都能往代码里加东西。加抽象、加层、加依赖。加了之后看起来多高级啊，好像自己懂了很多。
但Senior不是这样的。Senior是说"不用加"。是能在关键时刻拍桌子："这破玩意儿现在不需要，未来三年都不需要。"
有几个评论提供了另一种视角：
我在亚马逊2005年到2008年工作。公司有两种奖：一个是"Just Do It"奖，奖励那些解决眼前问题的人；另一个是"Door Desk"奖，奖励节俭到用门板当桌子的人。说白了，后者就是奖励简单。
我见过最长寿的项目，永远是最简单、最容易替换的方案。通常来自简单的测试场景，就是那种"能work"的东西。
简单不意味着简陋。简单是克制。
怎么让简单被看见？
好，抱怨完了。问题是怎么破？
首先，学会给自己的简单方案写文案。
"实现了功能X"是三个词。但你完全可以写成：
评估了三种方案，包括事件驱动架构和自定义抽象层。最终判断直接实现能满足当前和预估的全部需求，两天交付，六个月零事故。
看见了吗？同一个东西，后者写出了决策过程、权衡考量、结果验证。简单不是没话说，是话没说到点子上。
其次，在设计评审里学会接化发。
当有人问"要不要future-proof一下"的时候，别直接妥协，也别硬刚。
更好的说法是：
如果以后需要，加上这个功能大概需要X天。但现在加的话，我们要多花Y天，还会增加维护成本。我的建议是先不搞，等信号出现再说。
你不是在拒绝，你是在展示自己想过而且想透了。
第三，用业务结果说话。
有评论提供了一个思路：
简单本身不值钱。但简单的结果很值钱。"事故减少80%"，"成本降低40%"，"性能提升33%的同时服务器减少25%"。
把简单翻译成数字。数字不会骗人，数字也不会被忽略。
如果你的团队就是不吃这套呢？
说实话，有些公司的文化就是这样的。嘴上说简单好，实际上只看谁造的轮子大。
这种情况怎么办？
两个选择。
第一个，学会玩这个游戏。不是说你要造轮子，而是你得学会把简单方案包装成值得说的故事。你不一定要同流合污，但你得知道怎么让自己的价值被看见。
第二个，换个地方。这不叫逃跑，这叫信息收集。如果一个环境永远不奖励好判断力，那说明这个环境有问题。你没必要跟问题死磕。
至少，你现在知道哪个游戏自己在玩了。
写在最后
文章标题是"没人因为把代码写简单而升职"。
但我觉得还可以加一句：
也没人因为把代码写简单而被开除。
那些最后接手你代码的人，那些凌晨三点被叫起来修bug的人，那些看着你造的抽象层发呆的新人——他们可能不会给你鼓掌，但他们的沉默就是最好的评价。
复杂度是写给人看的。简单是留给未来的。
【MiniMax-M2.1锐评】：这篇文章说出了无数工程师心里清楚但说不出口的委屈——干得好不如写得漂亮，代码干净不如PPT复杂。系统奖励的是能见度，不是质量。
参考链接：
https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/