我一直在思索我们工程师对项目的多样化影响，以及像 "10x 工程师" 这类评价背后的真实意义。过去几年里，很多文章都讨论过这个概念，有些人称其为神话，而有些人则认为你的团队里至少需要有一位。这是一个备受关注的话题；很容易理解，这个术语经常引起争论。然而，我认为理解一个开发者给团队带来的真正价值，超越任何数字评价以及他们的 leetCode 分数是非常重要的。
我是那派认为 10x 工程师是伟大的人之一，而且，我的观点并非出于天方夜谭。但是我有一个更为细微的看法，我认为 10x 工程师与他的编码能力无关，更重要的是，我认为任何人都有可能成为 10x 工程师。这不是个人品质，而是你作为软件开发者所做出的所有微小决策的累积效果 —— 你选择的工具，你尝试 debug 的方式，你与团队队友交往的方式。
在我早期的职业生涯，我亲眼目睹了一个普通的开发者如何一夜之间成为一个 10x 工程师：我们有一个每秒钟应对成千上万请求的高负载项目，这个项目由一小团队开发 —— 这是一个需要快速工作，并且需要扫描大量的数据以匹配多维度查询的搜索模块。乍一看，一切都很顺利，代码已经在生产环境运行了一段时间，但有些用户抱怨说他们随机地收不到响应。
随着时间的推移，错误率持续上升，但我们却无人可以求助。最初的开发团队已经转向另一个项目，实在没有时间帮助我们。产品已经上线了，由于尚未解决的并发问题导致不可预测的行为，用户们对此有理由感到苦恼。
然后，我们的主要开发者站了出来。他花了几天时间试图定位问题，调试每一行代码。他是我所认识的最优秀的工程师吗？他并不是，但在那个关键时刻，他对项目的贡献是团队中任何其他人的 10 倍。他一己之力解决了我们搏战了半年以上的问题。
回过头来看，"10x 开发者" 这个词实在不足以公正对待那些必要的贡献。这并不是关于你比其他工程师快 10 倍，而是关于做出关键的决策，为整个团队带来显著的正面效果。如果你的速度快了，但其他所有东西都出问题了，你是真的 10 倍工程师还是 0.1 倍工程师呢？
10 倍效率工程师：被认知偏见所扭曲的观点#
10 倍效率工程师（10x engineer）这个术语颇具吸引力。它戏剧性地抓住了人们的注意。有人在一天之内就快速构思出解决方案，于是立刻 —— 他们就被冠以 10 倍效率工程师的美誉。但问题在于，这个术语的使用充满了我们的认知偏见。我们总是目不转睛地关注那些如星辰般耀眼的人物，却往往忽略了那些脚踏实地、可靠的工程师，正是他们默默地维持着系统的正常运转。
为什么会这样呢？嗯，我们的大脑偏爱英雄故事。我们天生很容易对那些因突出而引人注意的异常者表示钦佩。这可以追溯到我们早期生存的本能。当某人在某事上表现得非常突出，我们就会注意到他们，哪怕这样的情况只在满月之夜偶尔出现一次。在野外，这种启发式的思考很有用，但在日常判断中，它可能会让我们产生偏见。
比如，上图就是一个关于 10 倍效率工程师的糟糕范例，它也完全错误。
一种非常普遍的认知偏差是晕轮效应（halo effect）。当我们对一个人的整体印象被某个突出特质或成就所影响时，就出现了晕轮效应。例如，如果团队里的某个成员曾经在短时间内解决了一个复杂的 bug，我们可能会因此忽视他在项目截止时间上连续的挣扎，依旧把他们看做高效能人士，这是基于他们那一次令人难忘的壮举。这可能会导致我们高估他们的能力，从而不合理地提高对他们的期望值。
对比效应（contrast effect）可能会导致我们因为一个人的技能不如其他更耀眼的同事那样立即显眼而低估了他们。这可能让我们忽略那些对我们的成功同样至关重要却相对隐蔽的稳定贡献。当我们直接比较两位工程师的能力而不是基于他们自身的优点作出判断时，也会出现这种情况。设想一下，如果我们的一位开发者刚完成了一个出色的功能演示，而紧接着另一位的演示就没那么抢眼。第二位工程师在大家心目中可能就会不公平地显得不那么出色 —— 并非因为他们的工作不好，而是因为他们被他人的光芒所遮盖。仅仅因为被遮盖，他们就是 0.1 倍效率工程师了吗？我不认同这一说法。
接下来的偏差是确认偏差。当我们看到某人曾经做得很棒，之后我们开始留意那些支持我们看法的细节，并忽视那些不符合的情况。比方说，如果我们给某人贴上了 0.1 倍效率的标签，我们可能就会在无意识中忽视他们的成功，并过度关注任何小失误，从而加固了我们的初步评判。
“生产环境出了一个 bug。肯定又是 David 推出的有问题的改动。”
这里的问题是，当我们对那些抢眼的行为给予赞赏时，我们可能就看不到那些默默在后台重构代码以提高整洁度的团队成员，或者是花时间辅导新同事的人。这些行为可能不会大声疾呼 “10 倍效率工程师在此”，但是它们对于团队的长远成功至关重要。
典型场景及行为表现#
正如我之前所述，关于 10 倍效能工程师与 - 10 倍效能工程师的辩论，主要取决于无数我们日常做出的决策，以及我们如何面对不同情境的反应；它并不仅仅与你编写代码的速度快慢或实现的算法有多么 “聪明” 相关。让我们通过一些具体场景来展示成为一名 10 倍效能工程师其实并不难。
处理生产中的 Bug#
设想一下，一个客户或者利益相关方发现应用中有一些与你负责开发功能相关的不一致之处。当有人告诉你你的代码出了问题时，以下可以作为你反应的基本准则。
✅ 10 倍效能工程师：“我们会立即查看并尽快回复您。” 你迅速定位问题、修复 Bug、通知团队，并在事后分析中分享解决方案以避免未来的问题。
❌ 0.1 倍效能工程师：“在我的电脑上运行得很好。” 一开始无视报告，将问题归咎于环境或用户操作错误，并且最终施加的临时性热补丁并未彻底解决问题。
响应代码审查#
一位经验更丰富的开发者正在审查你的代码，他建议使用另一种实现方案，并表示在 Pull Request 被批准前，你应该先按照公司通用标准进行重构。
✅ 10 倍效能工程师：“感谢你的反馈。我非常欣赏这些建议！” 你真心感激这些反馈，努力整合这些建议，并感谢你的同事提供的洞察。专注于产品更好的发展，而不是推动个人议程或自我。
❌ 0.1 倍效能工程师：“你错了，我的代码已经很完美了。” 对反馈表现出防御性，无理辩驳，这不仅拖慢了审查过程还只关注于个人 —— 认为他们所写的代码比产品整体的改进更重要。
处理上层管理和行政事务#
众所周知，软件工程不仅仅是关于编写代码；发布任何功能都伴随着大量的额外工作。想象在日常会议中，管理者开始要求通过项目管理工具增加透明度。他们表示自己缺乏情境理解，难以保持整个项目的顺利进行。
✅ 10 倍效能工程师：“是的，Jira 有时确实令人烦恼，但我明白你的意思，它确实能让每个人保持同步，助于各司其职。” 你明白开发与管理间平衡的重要性，并努力处理必要的行政任务，确保两者都得到重视。
❌ 0.1 倍效能工程师：“Jira 太糟了，根本没人在意它，它甚至不能算是真正的工作。” 对每一次演示、绘图和票务工作都显得很不耐烦。
引入新技术#
自从你的项目上次正确地进行了重构已经过去了五年。随着业务发生了许多变化，代码库中添加了许多临时解决方案来应对所有由业务增长引入的新的边界情况。是时候正确地做事了，从零开始以适应不断变化的业务需求。
✅ 10 倍效能工程师：“我们做一个概念验证，看看哪种技术最适合我们，然后再决定我们要投入哪种技术。” 你在评估新框架时深思熟虑，考虑团队能力和项目需求。你考虑到了潜在的技术债务，思考做必要的重构。
❌ 0.1 倍效能工程师：“我们应该选择 Angular，因为它是最好的，因为那是我唯一熟悉的框架，我打算在接下来的 45 分钟里和你争论。” 毫不考虑地推动新技术的采用，允许技术债务累积，并将新功能的开发优先于长期项目健康。
团队会议#
你和团队坐下来讨论落实一个需求功能的替代开发方案。可以有许多不同的实现方式，有人提议走无服务器的路线，有人建议使用 Rust 语言，并在本地设施上构建。众多不错的想法在团队成员之间频繁交换。
✅ 10 倍效能工程师：“我们来听听每个人怎么说。” 你以建设性态度参与讨论，确保对话有序进行，并遵守时间限制。激励每个成员发表见解，基于团队的共同决策挑选最合适的行动方针。
❌ 0.1 倍效能工程师：“这里是我的见解，请大家静听 45 分钟。” 在讨论中占据主导地位，使话题偏离重点并情绪化争论。
面对失败的项目#
事情不总是顺心如意的，有时你会失败。你在失败面前的反应同样能体现出你与 0.1 倍效能工程师的不同。这些细小的互动非常至关重要。
✅ 10 倍效能工程师：“好的，我们来客观分析一下哪里出了问题，避免指责任何人，并确保将来不再发生类似情况。” 你以建设性的方式分析问题，并在一个不寻找替罪羊的环境中探讨，理解需要哪些改进来防止将来发生类似的问题。
❌ 0.1 倍效能工程师：“这都是某某的错，她 / 他的代码总是出问题。” 将责任推卸给他人，避免共同承担责任，往往掩盖了项目失败的真正原因，以保护自己的立场或虚荣心。
最小可行产品（MVP）的开发#
如果你是团队中的主要工程师或刚开始承担技术共同创始人的角色，CEO 可能会来向你征询建议，询问应该开发什么以及何时发布。重要的是要明白，工作量会填满为它分配的时间。
✅ 10 倍效能工程师：“我们来制作一个足够好的产品并将其推向市场。” 你专注于交付一个具有足够特性满足早期使用者，同时验证产品概念的最小可行产品（MVP）。
❌ 0.1 倍效能工程师：“我们要把产品做到完美然后再也不发布。” 追求完美，希望在产品推出时就功能全面完备。
功能的优先级排序#
每一位软件工程师都需要和管理者密切合作。通常，管理者会和团队讨论确定哪些功能的开发顺序，并征求团队的意见，看看接下来应该开发什么。
✅ 10 倍效能工程师：“客户有什么反馈呢？他们最大的问题点在哪里？” 你与产品管理紧密合作，优先开发那些为客户带来最大价值的功能。
❌ 0.1 倍效能工程师：“我想部署 Kubernetes。” 坚持要开发技术含量高但影响力较小的复杂功能，这些功能虽然显示了技术实力，但却不符合用户的需要或业务目标。
我希望这些场景达到了揭示的目的，那就是：你无需熬夜、加班就能交付高度复杂软件，并以此获得 10 倍效能工程师的认可，关键是要在日常工作中做出正确的决策，并提交高质量的代码。
普通人作为推动力#
大项目的成功推进得益于团队的集体（共同）努力，而非某一位超级明星开发者的独力作为。当然，如果有能迅速解决问题、像打印机一样编程的人在团队里，那自然是极好的。但即使是十倍能力或者百倍效能的工程师，也有其局限性。他们可能会生病，需要假期休息，或有时候状态不佳。他们也可能会离职。一味依赖这些 “超级英雄” 的项目，当这些 “超级英雄” 需要休息时，可能就会遇到棘手的困境。
招纳十倍工程师。来源：workchronicles.com
正如你从前述场景中所见，保持正确态度已足够让你在团队中脱颖而出，被视作一名十倍工程师。如果每个人都这样前进，那么你就会有一个着眼于最佳实践、力求尽善尽美的出色团队。这难道不是最重要的吗？比起庆祝某人一天之内编写出一个极为复杂的功能更重要对吧？想想那些进行顺利的重要软件更新或者产品发布。那仅仅是由一人完成的吗？几乎不可能。这是整个团队共同处理了数以千计的小任务、投诉、问题、事务，以确保一切正确无误。
我们应当公平地看待并欣赏各种层面上的贡献。毕竟，真正成功的项目来自于各方面的共同努力，而非仅凭个人的瞬间灵光。
2024 年 4 月 23 日更新：如果你更喜欢观看视频而不是阅读，或者只是想见识一下我的风采 —— 我录制了一段视频，分享一个十倍工程师应该具备的特点。请观看至视频末尾，分享我的个人经历。点击这里观看视频。