程序员的悲哀：为何你最引以为傲的效率最难被度量

一、一个值得停下来想一想的场景

有一种说法流传很广：早年的资深工程师隔着机房走廊，仅凭调制解调器拨号音的音色就能判断波特率配置有误，喊一嗓子就解决了问题。这类故事之所以动人，是因为它浓缩了一种理想化的技术形象——经验深到可以绕过工具，判断快到不需要流程。

但如果把浪漫滤镜摘掉，用工程管理的视角重新审视这个场景，会发现一件不太舒服的事：这位工程师真正创造的价值，并不是“听出波特率错了”这个瞬间，而是“避免了一次长时间的排查和停机”。 而后者，在任何一张工时表、任何一个绩效系统里，几乎都不会被记录。

这就是本文想讨论的核心问题：程序员的悲哀到底是什么？

我的回答是：悲哀不在于技术会过时，而在于你引以为傲的那个东西——效率与速度——恰好是整个工程体系里最难被准确度量、也最难被长期留存的维度。

---

二、你以为是水平之争，其实是可测量性之争

2.1 救火者被记住，防火者被遗忘

在大多数研发组织里，最容易被看见的行为是“故障响应”：

• 系统在凌晨两点挂了，谁爬起来定位、回滚、修复，谁的名字就会出现在事故复盘的第一行；
• 一次紧急扩容、一次线上热修、一次数据修复脚本，都会留下明确的操作记录和时间戳。

相反，那些提前三个月把连接池上限调对、把重试策略加上抖动、把慢查询在业务低峰期干掉的工程师，做了什么？什么都没发生。 而没有发生的事故，是无法被归因到具体某个人的。

这是一个典型的激励结构错位：

行为类型	可观测性	归因难度	绩效可见度
线上救火	高（有告警、有记录）	低（直接对应到人）	高
隐患预防	低（没有事件发生）	极高（无法证明因果）	低
架构简化	中（代码变更可查）	中（收益滞后）	中偏低
效率提升	低（省下的时间不可见）	高（基线难以确定）	低

在某些赏罚不够透明的组织里，甚至会出现一种逆向激励：先让问题暴露出来，再申请资源去解决，这样才有“功劳”可记。 这种做法在道德上值得商榷，但在激励逻辑上却完全自洽——因为体系只奖励“可见的修复”，不奖励“不可见的避免”。

2.2 连当事人自己都估不准自己的效率

如果只是“别人看不见”，问题还不算致命。更冷的一层是：连你自己都测不准自己。

有一类随机对照实验专门研究过这个问题。实验设计大致如下：让一批资深开发者在他们平均已经工作五年以上的成熟项目上完成数百个任务，每个任务随机决定是否允许使用智能编程辅助工具。在开工之前，参与者预测使用工具可以将完成时间缩短大约四分之一；完成之后，他们自评认为确实缩短了约五分之一。

而实测结果是：整体完成时间反而变慢了接近两成。

同一份研究里还记录了另一组预测：经济学领域的专家预测能快近四成，机器学习领域的专家预测能快近四成——方向全部相反。

这组数字放在一起，说明的不是“智能工具不行”，而是一个更根本的问题：

当你的主观效率估计与客观测量之间能差出三十多个百分点时，任何“我很熟练”“我很快”的自我评价，在组织账本上都是不可采信的。

这不是个人能力问题，而是人类对自身认知负荷的 introspection 本身就不可靠。你以为你在加速，实际上可能只是在把时间从“写”转移到了“读、改、验证”。

---

三、为什么“速度”这个维度天然不可靠

3.1 速度没有稳定的基线

“快”是一个相对概念，但软件工程里几乎不存在稳定的参照系：

• 任务难度不同：修一个空指针和重构一个状态机，不可比；
• 代码库状态不同：新项目和十年老项目，不可比；
• 依赖环境不同：本地能跑和线上能跑，不可比；
• 定义不同：是“写完代码”还是“合并到主干”还是“上线无故障”？

没有稳定基线，就没有可比的度量。没有可比的度量，“效率高”就只是一种叙述，而不是一种事实。

3.2 速度不可留存

更麻烦的是，速度是一种消耗型资源：

• 你今天花两小时修完的 bug，明天不会因为“你曾经很快”而自动消失；
• 你这次用某个技巧省下的半天，下次换一个人、换一个场景，未必能复现；
• 你熬夜赶出来的进度，往往以技术债的形式，在三个月后以更高的利率还回去。

速度不像资本，更像现金流——花掉就没了，而且不产生利息。

3.3 速度容易被工具平权

当智能编程辅助工具逐渐普及，纯粹“敲得快”“记得住 API”的优势正在被快速拉平。真正拉开差距的，不再是手速，而是：

• 知道该不该做这件事；
• 知道做到什么程度可以停；
• 知道哪里会出问题、为什么出问题。

这些都属于判断力，而不属于速度。

---

四、另一种活法：把判断力做成别人能接着用的东西

4.1 一个存活了二十多年的参照

有一个非常经典的嵌入式数据库项目，其源码仓库在说明文件开头就写明：这份源代码可以追溯到 2000 年 5 月下旬，代码本身放入公共领域，版本控制使用的是一个专为它编写的系统。

这个项目的存活方式，和“某个人很能写”完全是两回事：

• 它不依赖任何单个开发者的手速；
• 它不依赖任何一家公司的持续投入；
• 它靠的是结构清晰、文档完整、任何人可以接手继续维护。

二十多年过去，参与编写的人换了好几茬，它仍然在被使用、被移植、被嵌入到各种各样的设备里。

代码会过期，判断力不会。但判断力只有在“别人能接着用”的形态里，才算资产。

4.2 判断力的三种可留存形态

把判断力从“脑子里的直觉”转化为“工程资产”，通常有三种形态：

第一，写进结构。

不好的做法：
  if (config.get("timeout") == null) {
      timeout = 3000; // 这个 3000 是当年某个人拍脑袋定的
  }
更好的做法：
  // 超时默认值的选择依据：
  // 上游 P99 延迟为 800ms，留 3 倍余量以避免级联超时；
  // 若上游 SLA 变更，此处需同步复审。
  const DEFAULT_TIMEOUT_MS = 3000;

结构不只是代码结构，也包括模块边界、接口契约、配置分层。好的结构会把判断固化下来，让后来者不需要重新判断一次。

第二，写进文档。

不是写“怎么做”，而是写“为什么这么做”和“什么情况下这个决定会失效”。决策记录（decision record）比使用手册更有长期价值，因为它保留的是约束条件和权衡过程。

第三，写进可运行的东西。

一个能跑起来的测试用例、一个可复现的基准脚本、一个自动化的检查规则，都比一段文字描述更能传递判断。因为可运行意味着可验证，可验证意味着可继承。

4.3 一个简单的自检清单

你可以用下面几个问题，判断自己手上的工作是否具备“可留存性”：

1. 如果我明天离职，接手的人能否在不问我的情况下理解这段逻辑的边界条件？
2. 我做的这个优化，有没有一个可复现的测量方式，证明它确实有效？
3. 我踩过的这个坑，有没有变成一条测试、一条规范或一条告警规则？
4. 我脑子里的那个“凭直觉就知道”，有没有至少一部分被写进了结构或文档？

如果四个问题里有两个以上回答“否”，那么你当前投入的时间，很可能正在流向一个既测不准、也留不住的维度。

---

五、悲哀的另一面：从消耗速度转向积累判断力

回到最初的问题：程序员的悲哀是什么？

悲哀不是“技术更新太快”，因为判断力不会因为框架换代而作废。悲哀也不是“年纪大了写不动”，因为工程价值本来就不应该建立在手速上。

真正的悲哀是：你把大量时间投入在一个既无法被准确度量、也无法被长期留存的维度上，而真正能产生复利的判断力，迟迟没有变成别人能接着用的形状。

但悲哀的另一面，恰恰是出路：

• 速度会被工具平权，判断力不会；
• 救火会被记住，防火可以被结构化；
• 代码会过时，决策记录和可运行资产不会。

所以，与其继续在“我很快”这个不可验证的维度上竞争，不如换一个问题问自己：

我做的这件事，离开我之后，还能不能继续产生价值？

如果答案是能，那你就不是在消耗速度，而是在积累资产。而这，可能是对抗“程序员悲哀”最实际的一种方式。