工程师的第二曲线：从写代码到设计系统

有一阵子我很焦虑。

翻自己的提交记录，发现一周里真正写代码的时间不到三成。剩下的七成在干什么？画依赖图、定接口约定、写文档、和自己吵架决定某个东西该不该做。

那种焦虑很具体：我是不是在退化？

后来我把那半年的产出摆出来看，发现一件反直觉的事——代码写得少的那几个月，系统的实际能力增长反而是最快的。

写代码解决的是「怎么做」，设计解决的是「做什么」

我复盘了几次返工最惨重的经历，发现它们有个共同点：没有一次是因为代码写得不好。

全部是因为一开始就做错了东西。

• 花两周做的批量预生成，后来发现根本不需要预生成
• 精心优化的某个环节，在改了架构之后整个被删掉
• 为一个「将来可能需要」的扩展点写的抽象层，两年没被用过一次

这些代码本身质量都不差。但它们从被写出来的那一刻起就是浪费，而这个浪费在写代码的阶段是看不见的——你只会觉得自己很高产。

设计阶段多花的一天，经常能省掉后面两周。这笔账我算了很久才算明白。

但设计不是「想清楚再动手」

这是我要澄清的一个误解。我不是变成了那种「先出完整方案再写第一行代码」的人——那样更糟，因为很多问题不动手根本发现不了。

我现在的做法更像是用最小的代价把不确定性打掉：

• 拿不准某个模型能不能做某件事 → 花二十分钟直接试一次，不要在会上讨论一小时
• 拿不准两个方案哪个好 → 各写一个能跑的最小版本，用真实输入比一次
• 拿不准需求是不是真需求 → 手工做一遍，看看到底有多痛

探针要小、要快、要用真实输入。这跟「写完整实现」是两码事。我一天可以打三四个探针，但一天写不完一个完整实现。

第二曲线上真正难的部分

不是技术判断，是接受你的产出不再可见。

写代码的时候，你的价值是具体的：这个功能是我做的，这个 bug 是我修的。转到设计之后，你最大的贡献往往是没有发生的事情——那个没被做出来的错误功能、那次没有发生的返工、那个因为提前定好契约而根本没出现的线上事故。

没人会为「没发生的事」鼓掌，包括你自己。

我花了很长时间才习惯这一点。现在我会有意识地给自己留一点「看得见的产出」——每周至少有一段时间是真正在写代码的，不是为了产出，是为了手感，也是为了别把自己变成一个只会指指点点的人。

离手艺太远的判断会开始失准。这不是矫情，是实实在在的：有几次我做的架构决策不合理，回头看都是因为我很久没亲手碰那一层了，对代价的估计已经不准了。

一个我用得最多的判断

从写代码转到设计之后，我最常问自己的一句话是：

这件事如果不做，会怎么样？

绝大多数时候答案是「也没怎么样」。那就不做。

工程师的本能是解决问题，看到一个问题就想动手。第二曲线上更值钱的能力是判断哪些问题不值得解决——因为你的时间总量没变，做了 A 就做不了 B，而 A 和 B 的价值往往差一个数量级。

写这篇的时候我又翻了一次那半年的记录。焦虑的那几周，其实是我做得最对的那几周。

只是当时我用错了尺子。