最近，我在网上看到不少关于 10 倍开发者的讨论。有些人想要成为这样的人，也有些人想远离这样的人。但在此之前，我们可能先要弄清楚这样一个问题：10 倍开发者真的存在、只是传说，或者仅仅是人们由于相对认知而感受到的概念？
在得出结论之前，我想先给大家讲讲自己的经历。
1. 与 10 倍开发者共事
大约十年之前，公司的软件开发总监雇佣了一名三级软件工程师，我们都叫他 Gary。大概在同一时期，我们还雇用了一位名叫 Mitch 的二级软件工程师。最初几个月里，Gary 非常安静，总是一个人待着，努力解决一个个纯技术性的问题。当时我们的任务，是为实时 3D 机械训练软件制作空气等流体的流动动画。公司里的每个人都一直希望实现这个效果，但由于种种挑战，始终未能达成。而 Gary，成为帮助我们冲击难关的英雄。
在他准备把功能提交给 QA 进行审查时，整个功能的观感至少比我想象中还要好，性能也超出预期，并拥有数千项单元测试断言作为支持。相比之下，我们的主体代码库根本就没经受过这么全面的测试。不用说了，各级管理人员都对这项睽违已久的功能感到非常满意。
我们的代码中有很多庞大，而且复杂得让人害怕的部分。
不久之后，Gary 又组织了一次工程展示。展示内容主要集中在架构层面，即围绕对象生命周期、依赖倒置、ad-hoc 生命周期 / 明确限定范围的对象、某些分配反模式的危害、有碍单元测试覆盖的代码耦合，以及这些因素与很多内部工程问题之间的关联等等。这次展示让与会者们感到困惑，甚至感到颇为尴尬。毕竟这一切赤裸裸的批评，指向的正是那些最早加入公司、并一路构建起知识产权体系的老员工。
我们的技术债务问题确实严重，但……也没有那么严重。虽然不会影响到生产力，但我们的代码中确实有很多庞大、而且复杂得让人害怕的部分。Gary 要做的正是揭露出这一切。但我们压力很大，因为我们每个人都是他提出的问题中的一部分。
他对现代软件设计的理解领先我们好几年。
这个人的特点是，他永远是对的。不只是在争论当中，也包括在各种判断当中，他更像是个全知全能的神。虽然我一直以先弄清事实再发言的好习惯著称，但我也得承认，在整个共事期间我一共只揪出过他一到两次不太准确的表达。和这样的人共事压力很大，因为同事们总会发现一些自己本该了解、但却一无所知的重要知识。考虑到他们往往与 Gary 有着同样的职称和头衔，这就更让人感到无地自容。
人性总有阴暗面，大家不喜欢那些特别聪明的人。特别是在对方提出的真知灼见既正确、又缺乏善意时，就更是让人不爽。所以同事们的普遍共识是，这家伙是个刻薄鬼。我个人并不觉得他是故意要让人难堪，但 Gary 在让人难堪这事上真的很有天赋。与此同时，他对现代软件设计的理解领先我们好几年，而这些心得还得在我们公司逐步实践，也许他觉得身边的同事真的让他很失望。
公平地讲，我们沿用陈旧技术与方法是有原因的，而且也靠这些旧办法开发出了强大的产品。任何公司都可能存在类似的问题。
Gary 强悍的技术实力加上对于敏捷流程的坚定拥护，最终挤走了雇用他的老领导，并由他自己上位。同事们震惊了一段时间，但很快就发现 Gary 主管带来了一系列令人兴奋的新变化。公司调整了自身产品各类，Mitch、我和另一位新任软件开发测试工程师（SDET）并纳入新团队中，尝试公司之前从未做过的工作。
根据交流感受，Gary 一直以为我是二级软件工程师。但在发现我实际上只是一级时，他相当愤怒，并很快去找公司高层理论。几周之后，我就升职了。同样的，Mitch 虽然只是二级软件工程师，但他却拥有不逊于三级工程师的知识与技能。但没办法，他只能等……不知道在等什么，总之需要一段时间才能得到与自己水平相符的职称。
有时候，Mitch 与 Gary 形影不离。我记得我们曾经花无数个小时在办公室里对未来新产品的架构设计组织头脑风暴与思维实验。到这个时候，我才意识到这两位的水平高到不知道哪里去了。有很长一段时间，他们两个人似乎开始用一种独特的语言交流。虽然他们之前从来没有协作过，但他们都认为公司内部缺少现代编程的基本概念。刚开始，人们不喜欢这两个人在那里说东说西；但事实证明，在他们碰头之后，两个人的编码效率确实高、质量也是真的稳定。
我这个人比较擅长处理技术上的困难任务，Mitch 特别聪明，而 Gary 则拥有最强的编码质量。更让人稀奇的是，虽然 Gary 总是在全体大会和管理层会议中占用很长的时间，包括设计并记录新的标准流程、为各个开发者提供帮助与指导，但我到现在也不太确定他究竟是怎么在短时间内为公司带来这么显著的生产力提升的。总之在他的带领下，整个团队都不需要加班了，包括他自己。
让所有开发者拥有共同的价值观，是建立和谐团队与强大代码库的关键。
尽管我已经有了几年的编程经验，但在 Gary 团队中度过的两年，绝对为我后续的高级开发者头衔奠定了良好的基础。他帮助我改掉了不少多年来养成的习惯——就是那种特别普遍，但并没什么用处，有时候甚至令人讨厌的习惯。相反，我们开始建立起更有前瞻性的视角，并积极使用先进工具与更高效的解决办法。而我从他身上学到的最重要一点，在于让所有开发者拥有共同的价值观，是建立和谐团队与强大代码库的关键。
我们开发出的应用程序几乎没有缺陷，性能非常好、易于扩展，而且能够在之后的项目中重复使用。从各个方面来看，这都是我在入职以来见证到的最令人振奋的技术成功。
如果这样的状况都不能给公司敲响警钟，那管理层就太失败了。
如果各位读者朋友也是那种重视工作、热爱工作的人，应该也曾被企业内的政治问题折磨得发狂。我怀疑 Gary 也是因为这个才决定离职，因为当时他并没有跳槽的打算。Mitch 在之后不到一年也选择离开，同样没有什么跳槽计划。两位最具才华的员工选择裸辞，这绝对是个强烈的信号。如果这样的状况都不能给公司敲响警钟，那管理层就太失败了——或者说，他们已经陷入了更大的问题当中。
Gary 给我的临别忠告是，“你需要多多表达自己。”回顾我们一起奋斗的那段时间，Gary 和 Mitch 都特别善于表达自己，他们有时候甚至不给我说话的余地。但只要把话筒交给我，我说出来的就一定会是有意义的东西。在他们的引导下，我意识到这确实非常重要。
我必须快速成长，帮助填补他们离去后留下的空白。虽然我的工作绩效同样非常出色，但最终我也离开了这家公司。我在这里度过了一段黄金岁月，也感激这家公司帮助我开启了职业生涯。但离别终有时，大家没必要总是强绑在一起。
几年之后，我仍然在把自己从 Gary 身上学到的价值观带到其他岗位上，也努力让自己成为一个善于表达的人。事实证明，这种价值观确实让我在其他公司里也获得了尊重与广阔的发展空间。
2. 要点汇总
不知道大家在这个故事里有什么心得，下面我来谈谈自己的切身感受……
我们很难量化什么才是真正的 10 倍程序员，但这个问题其实没那么重要
真正重要的，是帮助你身边的人获得提升。
有些人可能会争论某个同事到底是不是真正的 10 倍程序员。这样的 10 倍到底是在跟谁比？10 倍又具体体现在哪些方面？
不少朋友都有过在一半的要求时间内完成了 4 倍工作量的经历，在项目中实现了更高的单元测试覆盖率以及更出色的代码质量，总体产出可以达到其他初级开发者的 10 倍以上等等。有时候，与具有一定经验的同行竞争时，您可能也凭借着更少的技术债务或者更强的特定领域专业知识达成了类似的优势。
但这一切终究会被慢慢抹平，大家会凭借类似的从业经验、使用相同的工具、基于同一套代码库、以相同的理念 / 流程 / 设计模式处理同样的技术债务。在这样的前提下，开发者之间的效率仍有区别，但恐怕绝不可能有 10 倍那么夸张。
问题的关键并不在于比其他人更强，而是帮助你身边的人获得提升。出色的开发者没有理由用自己的优势来打击其他同事，最重要的是为他人提供指导、发现阻碍生产力进步的因素、解决问题并防止其再次发生。这样，我们就能拥有一支真正有战斗力的队伍，而不只是围绕着一位开发明星原地打转。
成为专家，还是培养自己的专业性
自满实际是在沉默当中寻找安全感。
我们不该因为某人出于长久以来的习惯、使用得到广泛证明的标准与既定技术，并由此以毫无追求的安全方法完成功能实现就对其横加指责。结合自己的经历，Gary 当初眼中的我们就像是这样一群业余爱好者。他不太注意自己的态度，只是他希望整个团队成长为软件开发专家的心情完全可以理解。
但请千万不要忘记，其他人也是人，人总是有着种种缺陷。Gary 也是这样，他在第 100 次看到同样的错误时肯定要发脾气；只是这样的错误对其他人来讲属于“正常现象”。失去耐心的同时，你也失去了对同事们应有的尊重，这本身就是对专业性的践踏。
软件领域的专业性像是一条微妙的线，我们不能随时越界，但在看到需要纠正的系统性问题时也不应视而不见。在此期间，你可能会引发混乱、可能会树敌，甚至威胁到自己的这只饭碗……但自满实际上是在沉默中寻找安全感。
如果希望改变，请在社交层面找到完美的平衡点。要用心挑选提出建议的契机，更要用心挑选提出建议时的用语。
重视实践、技术与理念
如果能够做到，这一切将改变你的职业生涯。
这些东西并不能保证把工作效率提升 10 倍。但我可以保证，只要培养起这样的能力，您会对软件开发拥有更加深刻的理解。
- 严格遵循 SOLID 设计原则
- 使用 MVC 模式进一步分离关注点
- 命令查询职责分离
- 通过实时代码覆盖工具完成单元测试覆盖
- 使用行为驱动型开发发现需求细节，同时实现 UI 测试自动化
- 明确定义并强制实施“已确认的定义”
- 代码质量与分支策略，借此保证源代码控制系统拥有良好的清洁度与性能
- 拥抱敏捷理念，但不必被动接受 SCRUM 中强调的一切流程
在职业生涯中亲身实践这些目标并不容易，毕竟每个人都已经在成长过程中积累起了自己的一套工作方式。但如果能够做到，这一切将改变你的职业生涯。
10 倍程序员的背后，可能代表着 10 倍错误
这类开发者的根本问题，在于他们的顶头上司。
公司里还有一位与众不同的开发者，我们叫他 James。从某种意义上说，他在公司已经拥有相当丰富的资历，非常擅长处理一部分编程任务。但他不愿意为自己的错误负责，经理多次批评还是无济于事。
最要命的是，其他人的大部分工作都处于 James 团队开发成果的下游。所以如果他弄错了，每个人都能感觉到；而如果别人弄错了，对他几乎没有影响。这就是上下游依赖关系的基本特征，要求上游一方必须拥有强大的责任心。
那么，为什么会陷入这么糟糕的状况呢？因为这位牛仔不相信单元测试，觉得这纯粹是在“浪费时间”，但其他人需要为他的武断买单。此外，他会反复把有问题的代码（包括无法编译或者存在严重阻塞问题的代码）添加到其他人正在使用的分支中，搞得公司内部民怨沸腾。
这类开发者的根本问题，在于他们的顶头上司。这帮管理者没有建立良好的实践，甚至把这种独行侠式的坏习惯视为理所当然。
3. 写在最后
我觉得这个世界上的 10 倍开发者也分好几种，有自私型的、有乐于助人型的、有平易近人型的，也有令人生畏型的。如果大家有天分能够加入 10 倍开发者阵营，希望各位能认真选择自己想成为哪一种类型。
