最近，关于『10 倍速工程师』（10x engineer）这个话题有了越来越激烈的讨论。实际上，10 倍速工程师就是指那些『在个人生产力方面，相对于普通工程师具有 10 倍以上工作效率的顶尖工程师。』
生产力
我曾经见过一些人，他们的工作效率远在我之上。可是我想说的却是，个人生产力的高低与团队效率完全无关。
通常情况下，生产力是按照产出结果的数量来定义的。
『真正有效的生产力，特别是在工业界，其计算方式是每单位投入与产出之比。』
规模不经济
然而，我们面对的问题在于，软件在一定程度上具有规模不经济的特点。我们想要构建的代码越多，构建和维护软件的成本也就愈加昂贵。随着软件规模不断增长，我们将会花费更多的时间和金钱在：
- 运维支持 - 保持软件正常运行。
- 用户支持 - 帮助人们使用这些功能特性。
- 开发者支持 - 培训新人理解和掌握我们的软件。
- 开发新的功能特性 - 随着系统规模成长，复杂度和构建新特性的时间也会不断增长。
- 理解依赖关系 - 软件和系统内部的关联变得愈加复杂。
- 构建工具 - 测试、部署以及软件变更的规模增长。
- 沟通交流 - 团队成员交流成本提高。
也就是说，单个人员的生产力越高，团队运行的整体效率可能越低。
我们的工作真的有效吗？
在我们所做的所有事情之中，最终来看，只有很少一部分能够创造出足以证明我们自身价值的东西 - 伴随着开发工作的推进，我们才会逐步有的放矢地专注在这些高价值的事情上。
如果我们实现了一个深受用户喜爱的功能，这就让判断我们工作的有效性变得非常容易。如果这项特性带给我们的收益远高于成本的话，那就更容易判断其价值了。
当你将这些工作成果与那些团队长期以来一直付诸于努力的工作方向进行比较的时候，你的感觉又是怎样的呢？我们所做的每一件事情都有其机会成本，因为你一旦选择了一个方向，就不能在另外一些地方，或者说更有价值的工作上付诸努力了。
0.1 倍速应用原则
有时候，关注不做什么反而更能让我们团队的工作有效性大幅提升：
- 我们无需添加这个特性。是否已有现成软件可以替代？
- 我们不用增加这个功能。由此引入的复杂性是否为我们带来了真正的价值？
- 我们先不要构建这个产品。可否做一些小测试，以此验证我们的假设是否成立？
- 我们不用急于部署这个开发工具。如果调整一下工作流程，或许就无此必要了。
- 我们无需适应这个新技术。也许利用现有技术或者我们熟悉的技术就可以达到同样的目标。『实现这一目标的最佳工具』是一种很不靠谱的说法。
- 我们无需持续维护这个特性。想一想究竟是什么影响我们删除这段代码？
- 我们无需自动化这个流程。难道就没有其它的方法了吗？或许这个流程本身就是多余的。
价值识别其实很难
鉴于维护每一件我们所构建的东西都有其固定成本，我们不如只在 10% 的工作上付诸努力，如果我们可以想出真正有价值的 10% 的工作究竟是什么的话。
至于这 10% 的工作，我们甚至情愿花费 10 倍以上的精力将其持续维护成本减少到最低。
现实中场景中，探寻哪些工作最具价值，以及哪些工作纯粹是在浪费时间，其实才是真正的挑战。
作者：Ben Jiweber，软件工程师，Unruly Tech 技术 leader。
原文：Why I Strive to be a 0.1x Engineer
感谢：Qingniu 帮助审阅并完成校对。