致敬“普通”的工程师——一位软件工程师对“10倍工程师”神话的质疑与反思
作者：Charity Majors，Honeycomb.io 联合创始人兼 CTO。
本文最初发表于 Substack 的软件工程师专栏 Refactoring，链接在此处。
我们大多数人都遇到过一些堪称“魔法师”般的软件工程师。他们仿佛拥有特殊的天赋，在复杂的心智模型中如鱼得水，能迅速给出令人意想不到却又优雅的解决方案，或以惊人的速度写出高质量的代码。
在我的职业生涯中，确实遇见过不少这样厉害的人物。他们的存在，也许正是“10倍工程师”这一概念持久流行的原因——也就是那些工作效率或能力能达到普通同行十倍的工程师。这一想法已经成了互联网上的一个梗。但这一概念其实来源于相当薄弱且粗糙的研究，人们为维护它所提出的观点也常常显得荒谬可笑（比如说，10倍工程师喜欢用黑色的屏幕背景，极少接触用户界面开发，而且通常是糟糕的导师和面试官），甚至完全迎合了刻板印象（例如：“我们想招那种穿连帽衫的年轻小伙子，就像扎克伯格那样的”）。但必须承认，这种说法似乎与我们的日常经验又莫名吻合，听起来就很有道理。
事实上，我并不否认世界上存在某些工程师的工作效率确实是其他人的10倍。然而，我真正质疑的是下面两个方面。
衡量生产力本身充满问题，且难以准确
首先，你如何衡量生产力呢？我对“存在一种绝对客观的指标能评定每个人的工作效率”的暗示感到质疑。请想想看，工程师们所面对的技能与经验组合有多么广泛、多么复杂：
你用的编程语言是Golang、Python、Cobol还是Lisp？用的具体版本、库和框架是什么？为了熟练使用这些工具，你还掌握了哪些额外的软件知识？
你还需要用到哪些跨领域的技能、市场知识和产品背景？比如设计、安全、合规性、数据可视化、市场营销或金融领域？
产品所处的开发阶段如何？用户规模多大？你是在给Mars火星探测车编写软件，还是开发发布后无法修改的产品？
更何况，每个人的能力和技能也不是一成不变的。比如，我曾经是一名很出色的数据库可靠性工程师，可能在某个时候甚至达到了所谓“10倍工程师”的级别，但现在肯定不是了。我已经有好多年没再调试过数据库查询计划了。
“10倍工程师”这种说法，似乎在暗示生产力是一个人固定不变的属性。然而，一个人在某个领域也许可以成为10倍工程师，但在其他众多领域，他可能只是一般水平甚至还达不到平均值。我认识不少顶尖的工程师，却从没见过谁能够在所有领域、所有场景下都比其他人高出10倍。
工程师并不拥有软件，团队才拥有软件
其次，更为重要的是：就算存在“10倍工程师”，又怎么样呢？软件并不是由个别工程师拥有的，而是由整个工程团队共同拥有。一个单独的工程师编写代码的速度再快，也意义不大。真正重要的是整个团队共同编写、测试、审查、部署、维护、重构、扩展、架构和迭代自己所拥有的软件的速度。
每个人都共用同一个软件交付流程。如果你们公司里最慢的工程师花5小时才能部署一行代码，那么最快的工程师同样也得花5小时来部署这一行代码。在软件开发生命周期中，真正花在写代码上的时间其实远远少于其他各个环节。
如果你公司里有任何服务或软件组件仅仅由某一名工程师负责，那么这个人就是一个单点故障。
我并不是说这种情况绝对不能发生。在初创企业里，一个人负责某些软件的情况其实很正常，因为初创企业最大的生存威胁就是行动太慢而倒闭。但当你的公司开始壮大时，软件的所有权就必须交给团队来承担。个别工程师可能生病、休假甚至离职，而业务本身必须能够对这些情况保持弹性。
当一个团队整体拥有软件时，工程团队领导者最重要的职责就变成了构建高效能的工程团队。如果你一定要打造一个“10倍”的东西，那就去打造一个10倍效能的团队吧。
最优秀的工程组织，恰恰是让普通工程师也能做出卓越工作的地方
当人们提到“世界一流的工程组织”时，脑海中往往浮现的是那些充满资深工程师、首席工程师的团队，或者是招聘大量来自大厂和顶尖大学人才的公司。但我认为，一个真正伟大的工程组织，恰恰是你不需要成为所谓“最优秀”或出身背景最亮眼的工程师，也能对业务产生重大影响的地方。事实甚至恰恰相反：一个真正伟大的工程组织，应该能让那些普通的、有一定技能、有一般水平专业能力的软件工程师，也能始终如一地快速行动、持续交付、回应用户、清晰理解自己构建的系统，并且日复一日、周复一周地推动业务持续前进。
任何人都可以建立一个由最优秀、最聪明的工程师组成的组织，让他们轻松创造产品并不断取得进展。这一点其实并不难做到。而过度强调个人能力反而会让领导者逃避他们真正的职责。如果你能建立一套体系，让经验较少的工程师也能高效地将自己的努力转化为产品与业务的增长，这将成为你的巨大竞争优势。从商业视角来看，衡量生产力唯一有意义的标准是：你到底有没有推动业务切实地往前迈进一步。
一个真正伟大的工程组织，自然而然也会培养出一批世界级的软件工程师。不过我现在似乎有点超前了。
我们不妨来聊聊“普通”工程师
很多技术工作者都曾沉迷于自己“聪明孩子”的身份认同。而软件行业也不断强化着这种迷思，比如 Netflix 声称“我们只招全球前10%的顶尖人才”，或者 Coinbase 表示“我们只要最顶尖的0.1%人才”。在这里，我想提出一个挑战，让我们暂时放下这些包袱，试着把自己看作“普通人”。
承认自己只是个普通人，这确实可能让人感到谦卑。但事实上，我们中的绝大多数人都是普通人，这并不是什么坏事。即使是那些在某些标准上被认证为“天才”的人，在其他方面也可能非常普通，比如身体协调性、情感智力、空间感、音乐才能或语言能力等等。
软件工程行业确实会筛选并发展出某些类型的智能，尤其是在抽象推理能力上。但没有人生下来就是优秀的软件工程师。优秀的工程师并非天生，而是在后天培养中逐渐形成的。
构建以“普通人”为核心的社会技术系统
在招聘人才和建设团队时，我们确实应该关注每个人所拥有的独特优势。但在搭建用于软件交付的社会技术系统时，我们更应该关注的是人们作为“普通人”的特质。
普通人都有认知偏差：确认偏差、近因效应、后见之明偏差。我们努力工作、在意结果，并竭尽所能；但我们也容易忘事、不耐烦或精神走神。我们的眼睛会不由自主地被红色吸引（除非我们色盲）。我们容易养成习惯，并抗拒改变。当反复看到同样的文字时，我们会逐渐停止阅读。
我们是有血有肉的人类，会疲劳、会感到力不从心。如果凌晨三点收到警报，我们在处理警报时犯错的概率要远高于下午三点。同样，我们的情绪状态也会直接影响工作的质量。
当你构建的系统是为普通工程师而设计时，他们所拥有的那些多余的才华就能更好地投入到产品本身，而不必浪费在与系统本身作斗争上。
卓越的工程组织会培养出世界级的工程师
一个伟大的工程组织，不是只有世界上最顶尖的工程师才能产生巨大影响的地方。然而，令人意想不到的是，这样的组织恰恰最容易培养出世界级的软件工程师。
真正优秀的工程组织并不是那些汇集了全球最聪明、经验最丰富工程师的团队，而是那些能够让普通的软件工程师持续取得进展、持续为用户创造价值并持续推动业务向前发展的团队。工程师能够明显感觉到自己产生的价值，这是吸引顶级人才的最佳方式。没有什么比“创造事物、解决问题、不断进步”更能让工程师感到快乐的了。
如果你足够幸运，团队里已经拥有了一些世界级的工程师，那真是太好了！作为领导者，你的角色就是善用他们的才华来服务客户与团队的其他工程师，而不是过度依赖这些才华。毕竟，这些人才并不属于你。他们随时可能离开，而你必须能够坦然接受这样的可能性。
这些人才可能会为组织带来巨大的价值——前提是他们能够成为良好的团队成员并控制自己的自负。这可能也是为什么这么多科技公司，尤其是硅谷的公司，会对寻找和招聘这些顶尖人才如此痴迷的原因。
但公司往往过于看重“找到那些已经被打上标签的人才”，这种想法最终只会复制并强化这个世界本已存在的偏见与不平等。天赋也许在整个人口中是均匀分布的，但机会却并非如此。
不要招聘“最好”的人，要招聘“对”的人
我们常常过于强调个体的能力和特征，而没有足够重视那些塑造我们、引导我们行为的系统环境。
我相信，如果我们在招聘时能把焦点从寻找所谓“最好的人”转移到寻找更为合适的“对的人”上，包括面试流程中候选人自我淘汰、申请者多样性不足等一系列问题都会随之改善。
如果你能创造出一种环境，让人们因自身独特的优势而非缺点的缺失而被聘用；如果你关注的是如何构建互补高效的团队；如果你将包容性视为理所当然——无论是出于道德原因，还是因为它能整体提升团队表现——那么这本身就是你的竞争优势。真正的精英文化恰恰需要这种包容性作为基础。
这样的组织对工程人才而言，具有一种难以抗拒的吸引力。人们能明显感到推动业务前进的成就感、技能提升的成就感、专业能力不断打磨的成就感。这也是那些渴望成为世界级工程师的人们所向往的地方。而当你拥有这样的组织时，那些已经是世界级水平的工程师也更愿意留下来，亲手培养下一代的杰出人才。