嘿，新手，我们雇你不是为了让你单纯完成任务

背景

这篇文章源自 Hacker News 社区的一篇热门讨论，其核心观点直击软件工程中“新手工程师（Noob）”与“资深工程师（Senior Engineers）”之间常见的认知错位。在传统的职场观念中，新员工往往认为自己的核心价值在于“执行”和“交付”，即尽可能多地关闭（Close）Jira 或 Trello 上的任务卡片。

然而，资深工程师和管理层的视角截然不同。对于团队而言，新手当前的生产力低下是预期之中的。公司支付薪水，本质上是在为工程师未来的潜力支付“期权溢价”。因此，管理者关注的不是新手今天完成了多少任务，而是通过新手的行为信号，将其归类为“改变游戏规则的人（A类）”、“稳定贡献者（B类）”还是“即将被淘汰者（C类）”。这篇文章旨在揭示这种分类逻辑，并指导新手如何通过正确的行为信号来展示自身价值，从而加速职业成长。

核心内容

重新定义雇佣关系：从“完成任务”到“展示潜力”

文章开篇即指出，没人关心你完成了多少任务。资深工程师（我们）雇佣新人，是因为我们知道未来会有更多的工作量，而我们无法独自完成。我们现在的投入，是为了培养下一代优秀的工程师。如果培养失败，十年后我们还得亲自干同样的基础工作，这是我们极力避免的。

因此，新手的首要任务不是埋头苦干，而是向管理者发送正确的“信号”，证明自己属于哪一类人才：

• A类：改变游戏规则的人，能让周围人的生产力成倍提升。
• B类：稳定且可靠的执行者。
• C类：表现不佳，一年内可能无法留任的人。

管理者会全力支持 A 类，适度支持 B 类，而对 C 类则尽量减少精力投入。新手必须主动通过行为来证明自己是 A 或 B。

第一层筛选：区分 B 类与 C 类

要成为 B 类或避免成为 C 类，仅仅追求“最快完成任务”是远远不够的，甚至可能是错误的策略。以下指标比单纯的速度更重要：

1. 代码质量：代码必须能正常工作。
2. 沟通透明度：你必须让其他人知道你在做什么。
3. 时间管理：在合理的时间内完成（如果能在初始估算时间的 3 倍以内完成，表现良好）。
4. 不增加他人负担：
   • 向寻求帮助的人提供工作——可以接受。
   • 让代码审查者（Reviewers）花费额外时间——糟糕。
   • 导致 On-call 人员响应错误——非常糟糕。
   • 导致 DevOps 人员响应你引发的事故——极其糟糕。
5. 诚信红线：任何试图通过谎报工作量来“刷数据”的行为，都会立即被标记为 C 类。不要试图操纵系统，因为这是不可能的。

关键原则：新手不可避免地会发出一些 C 类信号，但绝不要重复发出同一种 C 类信号。确保你的整体信号平衡倾向于 B 类。

第二层筛选：区分 A 类与 B 类

如果你已经是 B 类，如何证明自己是 A 类？A 类与 B 类的区别不在于完成任务的数量，而在于从每个任务中学到了多少，以及是否提升了系统的整体效率。

A 类工程师的典型信号包括：

• 质疑必要性：能令人信服地论证某个任务根本不需要做。
• 二八定律：挖掘数据，发现那 10% 能产生 90% 收益的关键任务部分。
• 多方案实现：尝试用多种方法实现同一个任务。
• 重构与简化：发现更好的设计，提交的不仅仅是一个实现任务的 Diff（差异文件），而是一系列简化代码库其他部分的 Diff。如果在实现之前先简化了代码结构，会获得额外加分（即“先做难的简化，再做简单的实现”）。
• 细粒度提交：提交一系列小的 Diff 而不是一个巨大的 Diff。如果每天推送 Diff，更是加分项。
• 工具化思维：编写内部工具来简化类似的重复任务（如果没有类似任务，则会被扣分）。
• 跨团队贡献：在不妨碍官方任务完成的前提下，向非本团队的领域提交有用的代码改进。
• 知识沉淀：以有趣、有用且具说服力的方式总结所学。
• 高质量审查：成为一位有洞察力且响应迅速的代码审查者。
• 单元测试：包含扎实的单元测试（作者希望这曾是 B 类标准，但目前仍是 A 类的加分项）。

A 类信号的共同点是：它们比单纯完成任务需要更多的时间。但这并不意味着可以无休止地钻研旁支末节。必须在合理时间内完成任务，只是不需要追求“绝对最短时间”。

时间从哪里来？

新手可能会问：“我已经忙得不可开交了，这些‘额外’的时间从哪里来？”

文章暗示，这需要掌握更高级的时间管理、任务队列管理和 Diff 队列管理技巧（文中提及后续会有相关专题文章《Everything You Need To Know About Programming But Didn’t Know To Ask》）。核心建议是：节省下来的时间，应该投资在自己身上，并以惠及他人的方式呈现。

关键要点

• 不要迷信任务数量：完成 40 个简单任务可能不如完成 20 个经过深思熟虑、优化了架构的任务有价值。
• 信号决定分类：管理者通过行为信号将员工分为 A、B、C 三类。你的目标是发送 A 或 B 类信号。
• 避免 C 类陷阱：
  • 代码不可用。
  • 沟通黑盒。
  • 严重超出估算时间。
  • 给同事（审查者、On-call、DevOps）带来额外负担。
  • 谎报工作量。
• A 类工程师的特征：
  • 做减法：质疑任务必要性，简化现有代码。
  • 做乘法：通过工具化、自动化提升团队整体效率。
  • 重学习：从每个任务中提取最大价值，并分享知识。
  • 细粒度工作：小步快跑，频繁提交，便于审查和集成。
• 时间投资的逻辑：公司支付薪水是购买未来的潜力。将节省的时间用于自我提升和团队赋能，是获得高绩效评估的关键。

意义与影响

这篇文章为软件工程师的职业发展提供了一个清晰的“逆向工程”视角。它打破了“苦劳即功劳”的传统迷思，强调了**杠杆率（Leverage）和信号传递（Signaling）**在职业晋升中的核心作用。

1. 对新手工程师的启示：

   • 从“执行者”思维转向“所有者”思维。不要只盯着任务列表，要盯着代码库的健康度和团队的效率瓶颈。
   • 沟通与透明度与编码能力同等重要。
   • 学会拒绝低价值工作，或通过技术手段消除低价值工作。

2. 对管理者的启示：

   • 评估新人时，应建立多维度的评价体系，而非单一的产出计数。
   • 明确传达对“C 类行为”（如增加他人负担、不诚信）的零容忍态度。
   • 鼓励 A 类行为（如重构、工具开发、知识分享），即使这些行为在短期内看起来没有直接产出。

3. 对技术文化的深远影响：

   • 倡导一种“持续改进”和“集体智慧”的工程文化，而非“个人英雄主义”或“机械式劳动”。
   • 强调了软件工程不仅是写代码，更是关于设计、沟通、协作和系统思考的综合学科。

总之，这篇文章的核心信息是：你的价值不在于你做了多少事，而在于你通过做事让事情变得有多好，以及你让周围的人变得有多强。