【译文】10x 软件工程师

我一直在思考工程师对项目的不同影响，以及 “10x 工程师 “等标签背后的真正含义。多年来，许多文章都讨论过这个概念，有些人认为它是一个神话，有些人则认为你的团队中至少需要有一名工程师。这是一个热门话题；可以理解的是，这个词经常引发争论。不过，我认为，除了数字标签和 leetCode 分数之外，了解开发人员为团队带来的真正价值也是至关重要的。

我也认为 10x 工程师是伟大的，不，这不是神话。但我有一个更细微的观点–我不认为 10 倍工程师与编码有任何关系，更重要的是，我认为任何人都可以成为 10 倍工程师。这不是一种个人素质，而是你作为软件开发人员所做的所有微小决定的累积效应–你选择的工具、你调试的方式、你与团队成员相处的方式。

在我早期的职业生涯中，我亲眼目睹了一个普通的开发人员如何在一夜之间变成 10x 工程师：我们有一个由小团队开发的高负荷项目，每秒有数千次请求，这是一个搜索模块，必须快速工作，扫描大量数据以匹配多维查询。乍一看，一切都很顺利；代码在生产中运行了一段时间，但一些用户抱怨说，他们随机收到的请求没有回应。

随着时间的推移，错误率不断攀升，但我们却无人可问。原来的开发团队已经离职去做另一个项目了，根本没有时间来帮助我们。产品上线后，由于并发问题未得到解决而导致的不可预测行为，客户理所当然地感到不满。

这时，我们的首席开发人员站了出来。他花了几天时间调试每一行代码，试图将问题归零。他是我认识的最好的工程师吗？不，他不是，但在那一刻，他对项目的贡献是团队中其他人的 10 倍。他凭借一己之力解决了我们苦苦思索了大半年的问题。

反思这一点，”10 倍开发人员 “这个词很难恰当地描述所做出的重要贡献。这与比其他工程师快十倍无关；这与做出正确的决定，为整个团队带来重大的积极成果有关。如果你的速度很快，但其他方面都很糟糕，那么你是真正的 10 倍还是 0.1 倍呢？

10x 受到认知偏差的影响

10x 这个词很华丽。它能吸引眼球。有人在一天之内就破解了一个解决方案，然后 “砰 “的一声，他们就被贴上了 “10 倍工程师 “的标签。问题是，这个词被我们的认知偏见所扭曲。当我们忙着关注这些明星时，却往往忽略了那些稳定可靠的工程师，是他们维持着引擎的运转。

为什么会出现这种情况呢？我们的大脑喜欢英雄故事。我们天生就喜欢欣赏异类，因为他们出类拔萃。这是很久以来的生存法则。如果有人在某件事情上有显著的优势，我们就会注意到，即使这种情况每满月才会发生一次。这种启发式虽然在野外很有用，但会让我们的判断出现偏差。

10x 工程师就是这样一个糟糕的例子，也是完全错误的。

光环效应是一种非常常见的偏见。当我们对一个人的整体印象因其某项突出特质或成就而发生偏差时，就会出现这种现象。例如，如果一个团队成员曾经在很短的时间内解决了一个非常复杂的错误，我们可能会忽略他们一直以来在项目截止日期前所做的努力，仍然会因为他们曾经做出的惊人之举而将他们视为佼佼者。这可能会导致我们高估他们的能力，从而对他们寄予过高的期望。

对比效应会让我们低估一个人的能力，原因很简单，那就是他的能力没有更耀眼的同事那么引人注目。这可能会导致我们忽视那些对我们的成功同样重要但却不那么显眼的稳定贡献。当我们将两个工程师直接进行比较，而不是根据他们各自的优点进行评判时，也会出现这种情况。比方说，我们的一位开发人员刚刚做了一个杀手级功能演示，而另一位开发人员的演示并不顺利。在大家的心目中，第二个开发人员可能会不公平地变得更糟–不是因为他们的工作不好，而是因为他们的工作被掩盖了。是否因为他们的作品被掩盖了，所以他们的得分才是 0.1x？我不敢苟同。

造成对 10 倍工程师认知偏差的下一个偏见是确认偏见。这是指我们看到他们曾经做了一件伟大的事情，然后开始捕捉那些支持我们叙述的细节，而忽略那些不支持我们叙述的细节。例如，如果我们给某人贴上 0.1 倍的标签，我们可能会不自觉地忽略他们的成功，而过度关注任何失误，从而强化我们最初的判断。

“生产中出现了一个错误。一定又是 David  在推送错误的东西”。

这里的问题是，当我们在为团队的闪光点点赞时，我们可能没有看到团队成员在默默地重构代码，使其更加简洁，或者没有看到他们花了几个小时指导新同事。这些行为可能不会让人联想到 “10 倍工程师在工作”，但对任何团队的长期成功都至关重要。

典型场景和行为

正如我之前提到的，”10 倍工程师 “与”-10 倍工程师 “的争论主要与无数日常决策、我们如何应对不同情况有关；它不一定与以最快速度编写代码有关，也不一定与实现的算法 “有多聪明 “有关。让我们来探讨几种情况，也许能更好地说明被视为 10 倍工程师有多容易。

处理生产中的错误：

想象一下客户或利益相关者在应用程序中发现了一些与您开发的功能相关的不一致之处。将其视为当有人说你的代码无法正常工作时如何应对的一般经验法则。

✅ 10 倍工程师：”我们会检查一下，然后再联系您”。你迅速隔离问题，修复漏洞，通知团队，并在事后总结中分享修复方法，以防止今后再出现问题。

❌ 0.1x 工程师：”在我的机器上能用”。忽略最初的报告，将责任归咎于环境或用户错误，当他们最终解决这个问题时，应用的热修复程序并不能完全解决问题，只是暂时的。

回应代码审查：

一位资历更深的开发人员正在仔细检查你的代码，提出其他实现方法，并说你应该先按照公司的标准重构代码，然后再批准拉取请求。

✅ 10 倍工程师：”感谢您的反馈。我很感谢你的建议！”你真心感谢反馈意见，努力整合建议，并感谢同事的真知灼见。关注什么对产品更好，而不是推动自己的议程和自我。

❌ 0.1x 工程师：”你错了，我的代码是完美的。对反馈做出防御性反应，无理争辩，拖慢评审进程。关注自我–他们编写的代码比整个产品的改进更重要。

处理资源和管理：

众所周知，软件工程不仅仅是编写代码，发布任何功能都需要大量的资源。因此，想象一下这样一种情况：在日常会议上，经理们开始推动通过项目管理工具提高透明度。他们说自己缺乏背景，很难让整艘船保持平稳。

✅ 10 倍工程师：”是的，Jira 很烦人，但我听你的，它让每个人都能了解最新情况，让你能做好本职工作”。你深知开发与管理之间平衡的重要性，并努力完成必要的管理任务，确保两者都不被忽视。

❌ 0.1x 工程师：”Jira 烂透了，没人关心它，它甚至都不是真正的工作”。对每次演示、图表和票据工作都感到恼火。

引进新技术：

您的项目已经有五年没有进行适当的重构了。业务发生了很多变化，代码库中添加了很多黑客，以覆盖业务增长带来的所有新的边缘情况。现在是正确重构的时候了，应该从头开始，以适应不断发展的业务需求。

✅ 10 倍工程师：”让我们先进行概念验证，看看哪种技术最适合我们，然后再决定采用哪种技术。”你会深思熟虑地评估新框架，考虑团队能力和项目需求。你要解决潜在的技术债务问题，并考虑必要的重构。

❌ 0.1x 工程师：”我们应该使用 angular，因为它是最好的，因为这是我唯一使用过的框架，接下来的 45 分钟我都会和你争论不休。”未经适当评估就推动采用新技术。允许技术债务无节制地积累，以牺牲项目的长期健康为代价优先开发新功能。

在团队会议期间：

您与团队成员坐下来讨论开发所需功能的其他方法。有很多不同的实现方式，有人建议采用无服务器方式，有人建议使用 Rust 和内部构建。大家来来回回提出了很多好主意。

✅10 倍工程师：”让我们听听大家的意见”，你建设性地发表意见，使讨论不偏离轨道，并遵守时间限制。你鼓励每个人发表意见，并根据集体决定选择最佳行动方案。

❌ 0.1x 工程师：”让我们在 45 分钟内听听我的意见”。主导谈话，将话题引向无关主题，情绪化地争论。

处理失败的项目

并非所有事情都能一帆风顺。有时你会失败。你在失败时的表现也会将你与 0.1x 工程师区分开来。这些微小的互动非常重要。

✅ 10 倍工程师：”好了，团队，让我们找出出错的原因，不要责怪任何人，确保这种情况永远不会发生。”你们以建设性的态度分析所发生的问题，在没有责备的环境中进行讨论，了解可以改进的地方，以防止今后再发生此类问题。

❌ 0.1x 工程师：”都是 Jane 的错；她的代码总是出错”。将责任推卸给他人，避免共同承担责任，经常掩盖项目失败背后的真正原因，以维护自己的地位/自我。

最小可行产品 (MVP) 开发：

如果你是公司的创始工程师，或者是新晋的技术联合创始人，你的首席执行官会向你请教应该构建什么产品以及何时发布。重要的是要明白，工作需要时间来完成。

✅ 10x 工程师：”你专注于交付 MVP，其功能足以满足早期用户的需求并验证产品概念。

❌ 0.1x 工程师：”让我们做到完美，永远不发货”，目标是在产品发布时做到完美和功能齐全。

功能优先级：

每个软件工程师都有与之共事的经理。大多数情况下，经理们会与团队讨论优先级，而团队则会就下一步应该开发什么提出自己的意见。

✅ 10 倍工程师：”我们的客户怎么说，他们最大的痛点是什么？你要与产品管理部门密切合作，优先考虑能为客户带来最大价值的功能。

❌ 0.1x 工程师：”我想推出 Kubernetes”，坚持实施复杂、影响较小的功能，这些功能展示了技术实力，但与用户需求或业务目标不符。

我希望这些场景能达到目的，说明你不必通宵达旦地交付高度复杂的软件才能被视为 10 倍工程师，你只需在日常任务中选择正确的行动方式，同时提交可靠的代码。

平均水平是推动力

大型项目的进展离不开集体的努力，而不仅仅是某个明星开发人员的功劳。当然，拥有一个能像机器一样快速解决问题和编写代码的人是很好的。但一个人只能做这么多，即使他是 10 倍或 100 倍的工程师。他们会生病。他们会休假。他们有休息日。他们会辞职。当超级英雄需要休息时，过于依赖这些超级英雄的项目就会陷入困境。

从上面的情况可以看出，以正确的态度挺身而出，足以让你的团队认为你是一个十倍于他人的工程师。如果每个人都能这样做，那么你就会拥有一支专注于最好的事情并全力以赴的优秀团队。这难道不是最重要的吗，而不是庆祝某个人在一天内编出了一个非常复杂的功能？想一想任何重大的软件更新或产品发布都进展顺利。是一个人的功劳吗？几乎没有。是一个团队处理了数以千计的小任务/投诉/问题/票据，把一切都做好了。

让我们平等地欣赏所有方面的贡献。毕竟，是各种类型的共同努力创造了真正成功的项目，而不仅仅是个人的辉煌时刻。

本文文字及图片出自 10x Engineers