"代码能运行"只是起点，不是标准。真正的工程成熟度涉及一个人如何处理范围、模糊性和人际关系，而不仅仅是他们的功能是否有效。我使用的最简单定义是：当一个工程师能够用更少的指导处理更大的问题时，他正在成长。
| 信号 | 不够成熟 | 更成熟 |
|---|---|---|
| 问题规模 | 需要明确定义的任务 | 承担开放式问题 |
| 指导 | 需要指引 | 独立工作 |
| "完成" | 代码合并 | 成果交付并拥有 |
| 影响范围 | 自己的工作 | 团队的有效性 |
两个工程师都交付了一个功能。一个关闭了工单。另一个向PM指出了一个危险的边界情况，添加了监控，并写了一份简短的文档，以便下一个人不会迷茫。相同的代码交付，但成熟度差异很大，而我倾向于推动第二种行为。
如果您只衡量代码是否有效，您就会奖励产出并忽视真正复合增长的因素：判断力、所有权和提升他人。明确命名这些标准为工程师提供了一个清晰的"成长"定义路图，并为您提供了一个公平、一致的反馈和晋升基础。