一、一句话惊醒梦中人

Kent Beck 在 2026 年 5 月 15 日的 newsletter 里写了一篇文章，标题就很直白：Hey, N00b, We Didn't Hire You to Complete Tasks。

开篇第一段他就把底牌摊开了：

没人关心你完成了多少任务。

这句话对新人来说，几乎是反直觉的。我们被招进来，领了一堆任务，每天在 JIRA 或 Linear 上挪卡片，难道不是以"完成任务"为核心目标吗？

Kent Beck 的回答是：不。如果我们只在乎今天的产出，我们根本不会招你——你的 tech lead 自己动手做比你快得多，也省心得多。

公司为新人付薪水，本质上是在为"你未来会成为什么样的工程师"付期权费。

这个视角的转换，对我触动很大。下面我会先梳理这篇文章的核心框架，再结合自己的思考，谈谈新人应该如何工作、如何学习、如何做职业规划。

二、核心框架：A、B、C 三类人

Kent Beck 把新人大致分成三类：

类别 描述 资深工程师的态度
A 能改变游戏规则的人，让周围所有人都变得更高效 全力支持
B 扎实的稳定贡献者 给予足够支持，帮助成长
C 一年内就会离开的人 尽可能少投入精力

资深工程师们自己也有日常任务要做，但他们同时在做一件更重要的事：判断你属于哪一类。

而你要做的，就是用行动向他们发送正确的信号，让自己进入想去的那个类别。

三、先保证自己不是 C

在讨论如何成为 A 之前，Kent Beck 先划了一条底线：怎么确保自己不是 C。

这些信号出奇地朴素：

1. 你的代码能正常工作。 这是最基本的，没什么好说的。

2. 你告诉了别人你在做什么。 闷头干活、最后扔出一个大 PR 是危险的。持续地让团队知道你的进展和思路。

3. 在合理的时间内完成。 不需要最快。Kent Beck 给出的标准很宽松——在实际用时的 3 倍以内就行（相对于估算）。这其实给了很大的容错空间，关键是你得有一个时间概念，而不是无限制地拖延。

4. 不要给其他人造成不合理的工作量。 这条非常关键，而且有严重程度的递进：

  • 你请教别人花了额外时间——没问题
  • 审阅者不得不花额外时间——不好
  • on-call 同事不得不响应你导致的报错——很差
  • DevOps 不得不处理你导致的生产事故——非常差

5. 不要试图钻制度的空子。 任何通过造假来显得自己完成了工作的行为，一旦被发现，直接标记为 C。而且 Kent Beck 的警告是："假定你钻不了这个空子。"

6. C 信号可以出现，但不要重复。 每个人都会犯错，都会偶尔发出一些 C 信号。这不可怕。可怕的是同一个 C 信号反复出现——这传递的信息是"你没有在学习"。

小结：做一个可靠的人，不要成为团队的负担。 这听起来门槛不高，但真正持续做到的人，已经是合格的 B 了。

四、A 与 B 的区别：你从每个任务中学到了什么

这是全篇我最受触动的部分。

很多人以为 A 和 B 的区别在于 A 完成任务更多、更快。Kent Beck 说完全不是——

区分 A 的不是他们完成了多少任务，而是他们从每个任务中学到了多少。

他用了一个数学比喻：新人当前的生产力本来就很低（这是正常的、被预期的），资深工程师真正在观察的，不是你当前的产出水平，而是你产出的一阶导数——也就是你的进步速度。

以下是他列出的 A 信号清单，每一条都值得展开想一想：

4.1 论证这个任务根本不需要做

最有价值的工作，有时是"不做"。如果你能通过数据或者逻辑令人信服地说明某个任务不必做，你节省的不是一个人的时间，而是一个团队的时间。

这需要你理解业务目标，而不是盲目执行指令。

4.2 挖出 10% 的工作产生 90% 的价值

大部分任务都有帕累托效应。找到那 10% 的核心部分，先把它做好，往往就能获得绝大部分收益。这是一种"先理解问题本质再动手"的能力。

4.3 用多种方式实现同一个任务

一个任务写一版代码就过了，你学会了一种做法。写三版不同的实现，你学会了三种做法，并且开始理解它们之间的 trade-off。这是刻意练习的思维方式。

4.4 在实现任务的同时，顺便改进了周围的设计

这被 Kent Beck 称为"额外加分"的行为：

  • 先让困难的改动变容易（重构），再做容易的改动（实现功能）
  • 不仅完成了任务，还顺带简化了代码库的其他部分
  • 每次不是扔一个大 PR，而是一串小的、有条理的 diff
  • 每天都有 diff 提交则更好

这种做事方式的本质是：你不是在完成任务，你是在持续改善整个代码库的健康度。 任务是入口，改善是出口。

4.5 写内部工具来简化同类任务

如果你发现某个模式反复出现，顺手写个小工具把流程自动化。但 Kent Beck 加了一个限定："如果没有同类任务，那就扣分。"——不要为了炫技而过度工程化。

4.6 跨团队贡献有用的 diff

在完成本职任务的前提下，如果你能在与你团队无关的领域也提交有用的改动，这会是一个非常强烈的 A 信号。说明你的视野不局限于自己被分配的那一小块。

4.7 把学到的东西写出来

写技术文档、学习总结、设计思路，而且要写得"有趣、有用、有说服力"。这和写代码是两种能力，但同样重要。好的写作者能让知识在团队中传播，放大自己的影响力。

4.8 成为有洞察力的审阅者

Code review 不只是挑错。一个好的审阅者能提出更好的设计方案、指出现有代码中可以被简化的地方、帮助提交者看到更大的图景。

4.9 写扎实的单元测试

Kent Beck 在括号里加了一句无奈的话——"我真希望这只是 B 信号，但一步步来吧……" 意思是，即使是现在，能认真写测试的人也不算多。把这件事做好，你已经领先了。

五、一个关键的认知转变

所有 A 信号有一个共同特征：

它们都比"以最短时间完成任务"要花更多时间。

但 Kent Beck 特意强调，这不是让你无限制地花时间在花哨的支线任务上。始终要在合理的时间内完成任务——只不是最短时间而已。

然后他抛出了一个新人很可能正在想的问题："但我已经很忙了，哪来的'额外'时间？"

他的回答是：你需要学习时间管理、任务队列管理、diff 队列管理……你会加速。用省下来的时间投资自己，以能惠及他人的方式。

这个逻辑链条是：

  1. 先把任务在合理时间内完成（不用抢最快）
  2. 用多出来的精力做那些"A 信号"的事
  3. 那些事会让你成长得更快
  4. 成长后你做任务会更快
  5. 形成正向循环

六、延伸到职业规划：我想成为什么样的工程师

读完这篇文章，我开始用 Kent Beck 的框架反观自己的职业规划。以下是我的一些思考。

6.1 前三年：建立"可靠性"底色

新人的第一要务不是惊艳，而是可靠。

  • 代码能跑，测试能过
  • 进度透明，有事提前说
  • 不给团队制造额外负担
  • 同一个错误不犯第二次

这听起来不够激动人心，但"可靠"是一个人在职场中最持久的信用。很多人做了十年工程师，仍然做不到真正的可靠。

6.2 三年后：从"完成任务"转向"改善系统"

当"可靠"成为肌肉记忆之后，衡量的标尺就应该变了。不再是"我完成了多少任务"，而是：

  • 我是否理解了这个任务背后的业务逻辑？
  • 我是否发现了代码库中可以改进的设计？
  • 我是否让团队的其他人工作得更顺畅了？
  • 我有没有把自己的学习成果传播出去（写文档、做分享）？

这其实就是 Kent Beck 说的"学习率"。你每天完成的任务数量可能变化不大，但你对系统的理解深度、你写出好设计的速度、你帮助他人的能力，应该呈上升趋势。

6.3 长期：选择留下来，还是选择走出去

Kent Beck 的框架还有一个隐含的点：他的 A/B/C 分类是站在"管理者/资深工程师"视角的。但作为一个工程师，你也有自己的选择权。

  • 如果你想深耕技术，成为某个领域的专家——那你就需要有意识地做那些"A 信号"的事，尤其是写文档、做分享、跨团队贡献
  • 如果你想走管理路线——那你需要额外关注沟通和协调能力，培养大局观
  • 如果你想做独立开发者或创业——那你需要在做好本职工作的同时，有意识地积累全栈能力和产品思维

无论哪条路，Kent Beck 的核心建议都适用：不要只盯着手头那堆任务。把每个任务当作学习的机会，把省下来的时间投资在自己身上。

七、总结

Kent Beck 这篇文章虽然标题是写给新人看的，但里面的道理对任何阶段的工程师都有价值。

核心观点回顾：

  1. 你的价值不在于完成了多少任务，而在于你的成长速度
  2. 先做可靠的人（B 信号），再追求卓越（A 信号）
  3. A 信号的核心是"从每个任务中学到更多"——这需要额外的时间投入，但这种投入会自我加速
  4. 用省下来的时间投资自己，以能惠及他人的方式
  5. C 信号可以犯，但绝不要犯第二次

对我自己的启发：

工作不只是用时间换工资。它更是一场对自己的长期投资。每一个看似普通的任务，都可以是成长的阶梯——只要你愿意多走一步。

正如 Kent Beck 所说，资深工程师在观察的不是你今天能写多少行代码，而是一年后的你能做什么。这个视角，值得每个新人记在心上。