一夜之间，一名普通开发者变成了“10 倍工程师”？

【CSDN 编者按】一直以来，本文作者都在思考工程师对于项目的不同影响，以及“10 倍工程师”等标签背后的真正含义。他认为，如今人们对于“10 倍工程师”的理解，已经逐渐扭曲了。

原文链接：https://vadimkravcenko.com/shorts/10x-engineers/

作者 | Vadim Kravcenko

翻译 | 郑丽媛

出品 | 程序人生（ID：coder_life）

多年来，许多文章都曾讨论过“10 倍工程师”这个话题。有人认为这是一个神话，也有人认为团队中至少要有这样一名工程师——显然，这是一个热门话题，也经常引发争论。

不过我觉得，除了用数字和 leetCode 分数来衡量之外，了解开发人员为团队带来的真正价值也很重要：我认同“10 倍工程师”很厉害这个观点，但我不认为“10 倍工程师”与编码有任何关系，甚至我觉得任何人都可以成为“10 倍工程师”。

在我看来，这不是一种个人素质，而是作为软件开发人员所做的所有细小决定的累积效应，包括你选择的工具、你调试的方式、你与团队成员相处的方式等等。

一夜之间，一名普通开发者成为了“10 倍工程师”？

在我早期的职业生涯中，我亲眼目睹了一名普通开发者一夜之间变成“10 倍工程师”：有一个由小团队开发的高负荷项目，每秒有数千次请求，这是一个搜索模块，必须快速工作，扫描大量数据以匹配多维查询。

乍看之下，一切都很顺利，但代码在生产中运行了一段时间后，就有用户抱怨说，他们随机收到的请求没有回应。

随着时间的推移，错误率不断攀升，但我们却无人可问。因为原来的开发团队已经离职去做另一个项目了，根本没有时间来帮我们。产品上线后，由于并发问题未得到解决而导致的不可预测行为，客户自然感到愈发不满。就在这时，我们的首席开发人员站了出来。他花了几天时间将问题归零，调试了每一行代码。

那么问题来了：他是我认识的最好的工程师吗？不，他不是。但在那一刻，他对项目的贡献是团队其他人的 10 倍，他凭一己之力解决了我们苦苦挣扎了大半年的问题。

结合这个故事，“10 倍工程师”这个词似乎就很难对重要贡献做出公正评价，因为关键并不在于要比其他工程师快十倍，而是要做出正确的决定、为整个团队带来重大的积极成果。试想一下，如果你只有速度很快，但其他方面都很糟就糕，那你这样到底是 10 倍还是 0.1 倍呢？

“10 倍工程师”的概念被扭曲

“10 倍工程师”这个词很华丽，也确实吸人眼球。例如有人在一天之内破解了一个解决方案，然后他们就会被贴上“10 倍工程师”的标签。问题是，这个词已经被我们的认知偏见所扭曲了：当我们都忙着关注那位主人公的时候，往往忽略了那些稳定可靠的工程师，正是他们在维持着引擎的运转。

为什么会出现这种情况呢？大概是我们天生就喜欢英雄主义，喜欢那些出类拔萃的特例，如果有人在某件事情上表现出色，我们就会注意到——但事实上，这个判断已经出现偏差了。

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

相反，对比效应则会让我们低估一个人的能力，原因很简单，因为与那位更耀眼的同事相比，其他人就不会那么引人注目。这可能会导致我们忽视那些对成功同样重要、却不那么显眼的稳定贡献者们。

当我们将这两种工程师直接进行比较，而不是根据他们各自的优点进行评判时，也会出现这种情况。比方说，一位开发人员刚刚做了一个杀手级功能演示，而另一位开发人员的演示并不顺利。那么在大家心目中，大概率会觉得第二个开发人员的能力不如第一位——但这不是因为他的工作不好，而是因为他被掩盖了。

由于这类人的成果被掩盖了，他们就成为了“0.1 倍工程师”？我决不同意。

造成对“10 倍工程师”认知偏差的下一个原因是确认偏见。具体来说，就是我们看到了一个人做了一件伟大的事情后，就会开始注意他那些符合我们认知的细节，而忽略那些不符合我们认知的细节。例如，如果我们给某人贴上“0.1 倍工程师”的标签，可能就会不自觉地忽略他的成功、而过度关注他的失误，从而强化我们最初的判断。

类似于：“生产中出现了一个 Bug，一定又是 David 在推送错误信息。”

这里存在的问题是，当我们为团队的某个人大力点赞时，没有看到其他团队成员在默默地重构代码，使其更加简洁，也没有看到他们花了几个小时指导新同事。这些行为可能与“10 倍工程师”看起来毫无关联，但对任何团队的长期成功都至关重要。

一些典型的场景和行为

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

（1）处理生产中的 Bug：

想象一下，客户在应用程序中发现了一些与开发功能不一致的地方。也就是有人说你的代码无法正常工作时，你该如何应对。

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

❌ 0.1 倍工程师：“在我的机器上能用。”你忽略了最初的报告，将责任归咎于环境或用户错误，到最后要紧急解决这个问题时，只能给出暂时性方案。

（2）回应代码审查：

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

✅ 10 倍工程师：“收到反馈，非常感谢你的建议！”你真诚地感谢反馈意见，努力整合建议，并感谢同事们的真知灼见。更关注什么对产品更好，而不是只关注自我感受。

❌ 0.1 倍工程师：“你错了，我的代码是完美的。”对反馈做出防御性反应，无理争辩，拖慢评审进程，认为坚持自我比整个产品的改进更重要。

（3）处理开销和管理：

众所周知，软件工程不仅仅是编写代码，发布任何功能都需要大量的开销。因此，想象一下这样一种情况：在日常会议上，经理们开始推动通过项目管理工具提高透明度。他们说，他们不了解项目背景，很难使其顺利推进下去。

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

❌ 0.1 倍工程师：“Jira 烂透了，没人在乎它，它甚至都不算真正的工作。”你对每次演示、图表和票据工作都感到无比烦躁。

（4）引入新技术：

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

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

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

（5）团队会议期间：

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

✅10 倍工程师：“让我们听听大家的意见。”你做出了建设性贡献，让讨论基本保持在正轨上，并尊重时间限制。你鼓励每个人发表意见，并根据集体决定选择最佳行动方案。

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

（6）处理失败的项目

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

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

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

（7）最小可行性产品（MVP）开发：

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

✅ 10 倍工程师：“只要我们做得足够好，就可以发布它。”你专注于交付一个 MVP，其功能足以满足早期用户的需求并验证产品概念。

❌ 0.1 倍工程师：“我们一定要做到完美，否则永不发布。”你的目标是，在产品发布时做到完美和功能齐全。

（8）确定功能优先级：

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

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

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

在我看来，处理好以上这些场景也能成为“10 倍工程师”，不是只有通宵达旦地交付高度复杂的软件才能被视为“10 倍工程师”。你只需在日常任务中选择正确的行动方式，同时提交可靠的代码即可。

平均水平，是最大的推动力

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

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

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

推荐阅读：

▶自曝每天花 50% 的时间编码，面试谷歌却遭拒？HR 透露：低于 70% 的不考虑！

▶OpenAI员工离职遭“封口”、安全团队已解散？Altman紧急回应：确有协议，但从未实行！

▶Windows XP/2000 “果奔”上网：20+ 年前的系统刚上线，瞬间中了几十种病毒！