Kent Beck 这篇写给初级工程师的文章，最扎眼的一句话是：公司招你，不是为了让你多关几个任务。

这话反常。新人进团队，Jira 票、GitHub issue、迭代看板，哪个不在数任务？但 Beck 的判断很冷：如果公司只买今天的吞吐量，资深工程师自己做通常更快、更稳、更少返工。招新人，是在买未来。

他用了一个很准的比喻：新人工资，是为未来工程师支付的“期权费”。

任务数不是新人价值的核心指标

Beck 把新人粗略分成 A、B、C 三类。这不是正式绩效制度，更像一个老工程师对团队信号的拆解。

类型团队看到的信号对组织意味着什么
A改变团队效率不只完成任务，还让后面的任务更容易
B稳定成熟代码能跑，沟通清楚，时间合理，少制造额外成本
C一年后可能不在反复添乱，制造事故，伪装进度，重复犯同类错

B 的门槛不玄学。

代码能工作。别人知道你在做什么。任务能在合理时间内完成。出了问题能讲清楚，不把成本甩给 reviewer、on-call 或 devops。

犯错正常。重复发出同一种 C 信号，就不正常。

这比“新人要努力”有用。努力是情绪词，信号才是组织会记账的东西。一个新人真正要先证明的，不是“我很忙”，而是“我不会让系统因为我变得更乱”。

A 信号往往更慢，但长期更值钱

更有意思的是 A。

A 不是一个季度关 40 个任务，别人只关 20 个。Beck 的意思是，单看数量，信息太少。A 的核心是学习率和系统收益。

比如这些动作：

  • 证明某个需求其实不用做；
  • 找出 10% 工作带来 90% 收益的部分；
  • 把一个大 diff 拆成连续小 diff；
  • 先让困难改动变容易，再完成改动；
  • 顺手改善设计，而不是只补一层胶带；
  • 写内部工具，减少重复劳动；
  • 把学到的东西写成团队可复用的总结；
  • 做一个有洞察、响应快的 reviewer。

这些事有个共同点：它们经常比“赶紧关票”更慢。

这也是最容易被误读的地方。Beck 没有给新人无限拖延、沉迷重构的许可证。他仍然要求在合理时间内完成任务。区别在于，合理时间内交付，不等于把“最短时间关票”当唯一美德。

工程里常说“磨刀不误砍柴工”。问题是，很多团队只奖励砍柴数量。最后刀越来越钝，柴越劈越乱，大家还以为是新人产能不够。

这件事的历史味很重。早期工厂管理喜欢数件数，件数好算，质量、返工、协作成本难算。软件团队换了工具，旧毛病还在：把最容易量化的东西，当成最重要的东西。

不完全一样。软件不是流水线，工程师也不是计件工。但权力结构很像：指标越粗，行为越会向指标表演。

该观察的不是新人忙不忙，而是团队奖励什么

我更在意的是，这篇文章其实在讲工程组织的激励设计。

好组织买的是成长期权。它会看谁在降低维护成本，谁在减少认知负担，谁让下一次交付更轻。坏组织买的是廉价吞吐量，只看谁关票多、在线久、显得忙。

结果很现实。新人会顺着奖励长大。

你奖励关票，他就学会关票。大 diff、浅修补、重复劳动、隐藏风险，都会被短期指标喂大。你奖励清晰沟通、可审查代码、复盘和工具化，他才有动力把成长过程摊开给团队看。

对初级工程师，动作很具体：

对象该做什么别做什么
初级工程师主动同步进展和阻塞；把大改动拆小；记录学到的东西；同类错误下次避开用忙碌感替代交付；憋大 diff；遇到风险不说；把重构当拖延借口
工程经理 / 技术负责人评估任务完成，也评估返工率、沟通质量、review 成本、是否减少未来工作只按关票数排座次；把新人当便宜劳动力；嘴上要成长，会上只问吞吐

接下来最该观察的变量，不是新人一个月关了多少票。

看两件事就够了。

第一，团队 review 一个新人代码的成本是在下降，还是一直靠别人兜底。第二，这个新人做过的任务，有没有留下可复用的东西：更小的改动路径、更清楚的文档、更少的重复问题、更少的后续维护成本。

如果这两个变量在改善，任务数少一点，不一定是坏事。如果这两个变量没改善，关票再多，也可能只是把债务换了个地方堆起来。

对新人来说，别把自己包装成“便宜版资深”。你赢不了。资深工程师上下文更多，踩坑更少，速度也更稳。

新人真正能展示的，是可靠地变强，并且让别人看见你怎么变强。

对技术负责人来说，别一边抱怨新人不会思考，一边只奖励最粗糙的产出数字。激励像水，往低处流。你奖励什么，团队就长成什么。

Beck 这篇文章狠，但不刻薄。它把一个工程常识讲得很直：公司不是在买新人今天多关一个任务，而是在赌他明天少制造十个麻烦，后天能替团队省下一整条弯路。