Kent Beck: 初级工程师如何从完成任务转型为高影响力表现

初级工程的目标是成长，而非吞吐量

对于初级工程师而言，成功的首要指标不是完成任务的数量，而是进步的速度以及为系统带来的价值。资深工程师将新员工的薪资视为对该工程师未来成长潜力的“期权溢价”，比起眼前的短期生产力，他们更优先考虑培养高绩效的下一代人才。

区分绩效等级：A、B 和 C 级工程师

资深工程师将新员工分为三个等级，以决定如何分配指导和支持资源：

• Category A (Game-Changers): 使周围每个人都变得更高效的工程师。
• Category B (Solid Performers): 可靠的工程师，最终会成长为稳定的贡献者。
• Category C (Underperformers): 一年内不太可能胜任该职位的工程师。

由于资深工程师的时间有限，他们会最积极地支持 Category A 级别的表现者，其次是 Category B，同时尽量减少在那些持续表现出 Category C 迹象的人身上投入精力。

基准线：'B' 级工程师的信号

在追求卓越之前，初级工程师必须首先证明自己不是 Category C 级别的表现者。一个“稳健”（Category B）工程师的基准由可靠性和避免负面外部性来定义。关键信号包括：

• 功能性代码: 提交的代码确实可以运行。
• 沟通: 让团队了解当前的活动情况。
• 合理的时间安排: 在合理的时间范围内完成任务（理想情况下在初始估算的三倍以内）。
• 减少摩擦: 避免为他人创造不合理的工作量。虽然寻求帮助是可以接受的，但造成过度的评审负担、值班错误或 DevOps 事件会被视为负面表现。

一种会将工程师立即标记为 Category C 的严重失败，是任何试图通过声称工作已完成但实际上并未完成来“钻系统漏洞”的行为。

迈向卓越之路：'A' 级工程师的信号

区分高影响力（Category A）工程师的不是关闭任务的数量，而是从每个任务中提取的学习量以及他们生产力的“一阶导数”。高绩效者通过以下行为展示价值：

战略性任务执行

• 质疑必要性: 提供令人信服的理由，证明某项任务根本不需要执行。
• 帕累托优化: 识别出任务中那 10% 能带来 90% 收益的部分。
• 迭代实现: 通过多种方式实现任务，以找到最佳方法。
• 简化: 发现更好的设计，并在实现所需功能的同时，提交能够简化现有代码库的 diffs。

工作流与工具

• 增量交付: 提交一系列小的、每日的 diffs，而不是一个巨大的 pull request。
• 工具改进: 编写内部工具，为整个团队简化重复性任务。
• 跨团队贡献: 在不忽视主要职责的前提下，向其直接团队范围之外的领域提交有用的 diffs。

专业成长与协作

• 有见地的评审: 作为一个响应迅速且有见地的代码评审员。
• 质量保证: 在所有工作中包含稳健的单元测试。
• 知识共享: 以一种具有说服力且对他人有用的方式记录学习心得。

在探索与交付之间取得平衡

大多数“A 级信号”比完成任务所需的绝对最小时间更多。为了实现这一点，初级工程师不应追求完成任务的绝对最短时间，而应追求一个合理的时间。通过更好的时间和任务管理所节省下来的时间，应该重新投入到这些能造福于整个团队和系统的、高价值活动中。