嘿，新人：我们雇你不是为了让你完成任务

原文作者：Kent Beck
原文链接：https://newsletter.kentbeck.com/p/hey-n00b-we-didnt-hire-you-to-complete
发布时间：2026 年 5 月 15 日

欢迎！我要传给你一个秘诀，让你顺利、快速地度过新人期，而且我不会吊你胃口：没人在乎你完成了多少任务。

为什么不呢？我们真正在乎的是什么——这就是本文剩下部分的主题。

从我们的视角看你

从我们的视角（“我们"指的是"老工程师们”）看看你的处境。我们雇了一堆像你这样的人。

我们这些高级工程师有自己的日常工作要做，但我们还得搞清楚你属于哪一类。我们会尽最大可能支持优秀的人。我们会给可靠的人足够的支持，帮助他们成长。尽管听起来很残酷，对于那些撑不下去的人，我们希望投入尽可能少的精力。

你的工作就是进入你想进入的类别，并向我们发出信号，告诉我们你就属于那里。

你手头那堆任务？你的经理或技术负责人完成那些任务的时间，比帮你完成它们的时间要少得多，麻烦也少得多。如果我们只关心今天的生产力，我们根本就不会雇你。

相反，我们（高级工程师们）关注的是未来：我们知道这里的工作会远远超出我们所能完成的。我们现在付你薪水，是作为对你将成为的那个工程师的期权费。如果这步棋走对了，我们将拥有下一代牛逼的工程师。如果走错了，十年后我们还得做同样的工程工作，而我们真的不想那样。

新人 A 这个季度完成了 40 个任务。新人 B 完成了 20 个。哪个更好？

信息不够。

如果所有任务难度都一样呢？那哪个更好？还是信息不够。

记住，我们在试图判断你是 A、B 还是 C。我们需要什么信息才能判断？

第一层筛选是判断你是 B 还是 C。以下是比"用绝对最少的时间完成任务"更重要的目标：

✅ 你的代码能工作。
✅ 你告诉了别人你在做什么。
✅ 你在合理的时间内完成了（如果在最初估计的三倍以内就很不错了）。
✅ 你没有给其他人造成不合理的工作量。
- 你求助的人多花了时间——还好
- 评审者不得不花额外时间——不好
- 值班工程师不得不响应你的错误——非常不好
- DevOps 不得不响应你造成的事故——加倍的不好

任何试图通过声称完成了没做的工作来钻系统空子的行为，会立刻把你标记为 C 类。假设你钻不了这个系统的空子。

你会发出一些 C 类信号。这是不可避免的。我们都经历过。永远、永远不要发出两次同样的 C 信号。 并确保信号的总体平衡是你是一个 B 类。

第二层筛选是，假设你至少是 B 类，那你是不是 A 类？

区分 A 类的不是他们关闭了多少任务，而是他们从每个任务中学到了多少。记住，以我们的标准来看，你的生产力烂得很。我们预料到了。我们在寻找的是你生产力的一阶导数（变化率）。

以下是一些表明你是 A 类的信号：

🎯 你能令人信服地论证这个任务根本不需要做。
📊 你挖掘数据，发现任务中 10% 的部分创造了 90% 的价值。
🔄 你用多种方式实现了这个任务。
🏗️ 你发现了更好的设计，并提交了一系列 diff，不仅实现了任务，还简化了代码的其他部分。如果在实现之前就这么做，额外加分（先让难的变更变容易，再做容易的变更）。
📝 你提交一系列小的 diff，而不是一个大的。每天推送 diff 额外加分。
🛠️ 你写了一个内部工具，简化类似的任务。（如果没有类似任务，你会扣分。）
🌐 你在与你团队无关的领域提交了有用的 diff，但不是以完不成正式任务为代价。
✍️ 你以有趣、有用、有说服力的方式写下你学到的东西。
👀 你是一个有洞察力、响应及时的评审者。
✅ 你包含了扎实的单元测试。（我倒希望这是 B 类信号，但慢慢来嘛……）

“牛逼"的清单比"别搞砸"的清单长得多，这不是很好吗？你有很多方式可以发光。

所有 A 类信号都有一个共同特征——它们比仅仅完成关闭任务所需的工作要花更长时间。

这不是允许你在花里胡哨的边角料上永远耗下去。永远要在合理的时间内完成任务，只是不要用绝对最少的时间。

你可能在想，这些"额外"的时间从哪里来。你已经忙得不可开交了。这就是《你需要知道的关于编程的一切，但没人告诉你要问》[编者注：待写] 派上用场的地方。我们会谈论时间管理、任务队列管理、diff 队列管理，以及其他能加速你进步的话题。

把你省下来的时间，以惠及他人的方式投资于你自己。这就是我们在寻找的。

作者：Kent Beck · 数百名付费订阅者