30岁以后的技术人，拼的不是代码量

如果你今年 28 岁，你的 GitHub 贡献图可以全绿，你可以在凌晨三点修完一个 bug 然后发到群里，你可以一个周末啃完一个新框架的文档并写出 demo。

但如果你今年 33 岁，还试图用同样的方式证明自己的价值，你会发现一个残酷的事实：你和 25 岁的人拼代码量，你一定会输。

不是因为你不努力，而是因为这场游戏的规则变了。你从新手村出来了，你面对的是一个完全不同的 boss。

不同阶段的竞争力，完全不同

我越来越清楚地意识到，技术人的职业生涯至少可以分为三个阶段，每个阶段的核心竞争力完全不同：

这个阶段，你的核心价值是把东西做出来。你能快速学习、能加班、能试错、能写大量的代码。你不需要做太多决策——你只需要高效地把分配给你的任务完成。

"这个功能你来做，三天能搞定吗？"——"能。"这就是 20 多岁的竞争力。

到了这个阶段，你的价值不应该再是"我能写多少代码"，而是"我知道什么代码不该写"。

你见过足够多的坑，你知道哪种架构方案在用户量增长到一定程度后会崩，你知道产品经理提的那个需求其实只解决了一个伪问题，你知道团队现在最缺的不是新功能而是重构那坨三年前的代码。

这些判断力，不是靠聪明能获得的，而是靠时间和经验的积累。一个 25 岁的天才程序员，他不可能拥有你踩过的坑。这就是你的不可替代性。

到了这个阶段，你写不写代码已经不重要了。你的价值在于你能影响多少人、能培养多少人、能做出多少个正确的关键决策。

你一个人写代码，一天最多写 8 小时。但你培养出 10 个优秀的工程师，他们的产出之和远超你一个人。你做出的一个正确的技术决策，可能为公司节省数百万的成本。

代码量衡量的是你作为个体的效率，而判断力和影响力衡量的是你作为系统的价值。

很多公司用代码量、commit 数、工作时长来衡量技术人——这些指标对 20 多岁的人勉强适用，但对 30 岁以上的人完全是误导。

我见过一个资深工程师，花了三天时间，写了 50 行代码，删掉了 2000 行。那 50 行代码替代了一个复杂的模块，让整个系统的维护成本降低了 80%。

如果按代码量衡量，他这三天是负产出。但如果按系统价值衡量，他这三天比很多人一个月的产出都高。

这就是为什么 30 岁以后，你不能再用"我做了多少东西"来证明自己，而要用"我避免了什么问题"、"我让什么变得更好"来定义自己的价值。

初级工程师面对的是"做还是不做"的问题，答案是二元的。但资深工程师面对的是"在 A、B、C 三个方案中选哪个，每个方案都有各自的代价"——没有完美答案，只有最优权衡。

技术决策力的核心不是选出"最好的"方案，而是：清楚每个方案的代价是什么，并能为你的选择负责。比如技术选型，别人说"用 Kafka"，你选 Kafka 是因为你觉得它火，还是因为你知道你的业务场景确实需要消息队列的持久化和分区特性，而 RabbitMQ 做不到？

培养方式：每次做技术决策时，强迫自己写出"为什么选 A 而不是 B"，列出至少三个理由。这个习惯会让你的决策从直觉变成方法论。

20 多岁时，你关注的是"这个函数怎么写"、"这个接口怎么设计"。30 岁以后，你需要关注的是"这个系统怎么设计才能撑三年"。

系统设计能力不仅是画架构图，而是：你能不能在需求还没完全明确的时候，设计出一个足够灵活的系统？你能不能在技术栈还没确定的时候，预判到未来可能出现的瓶颈？

培养方式：不要只关注自己负责的模块。每次有跨团队的技术方案评审，主动去旁听。看看别人是怎么做权衡的，为什么他们选了那个方案。你从别人的决策中学到的东西，往往比从自己的成功中学到的更多。

这是最容易被忽视的能力。很多技术人觉得"带团队"是走向管理，是放弃技术。但实际上，技术领导力不是管理，而是放大技术影响力的方式。

团队杠杆力的核心是：你能不能不说"你这样做不对"，而是说"我们试试这个思路"？你能不能把一个人的好习惯变成团队的默认行为？你能不能让你的经验变成团队的资产，而不是你一个人的秘密武器？

培养方式：从 Code Review 开始。不是找 bug，而是分享思路。每周花 30 分钟认真 review 一个同事的代码，写下你的建议，并解释为什么这样写更好。你会发现，教别人的过程，往往是你自己理解最深入的过程。

30 岁不是一个悬崖，而是一个转向灯。它提醒你，你不能再靠和年轻人一样的方式竞争了——但这不是坏事，因为你已经拥有了年轻人没有的东西。

代码量是你的昨天，它证明了你够努力。但判断力、系统思维和影响力，才是你的明天，它们决定了你能走多远。

从今天开始，试着用一个新的问题衡量自己：这周，我做了什么决策，让团队或项目变得更好？如果你答不上来，说明你可能还在用 20 多岁的方式工作。

是时候升级你的游戏了。