10倍效率程序员是否真的存在

在编程神话中，一个 10 倍效率的程序员可以完成一个普通程序员 10 倍的工作量。「普通程序员」就是指，善于完成工作但没有 10 倍效率程序员那神奇能力的人。实际上，为了更好地描述普通程序员，我们可以这样认为，就是在专业程序员之中，代表那些可以输出平均编程成果的程序员。

是否存在 10 倍效率的程序员，在这件事上编程社区内是严重的两极分化：有人说根本没有这样的人，也有人说事实上不仅存在这种人，如果你知道到哪里去寻找，甚至还存在 100 倍效率的程序员。

如果你认为编程是一个“线性”的学科，那存在 10 倍效率的程序员这件事看起来几乎是不可能的。一个跑步的人怎么可能跑得比另一跑步的人快10倍？在相同的时间内，一个建筑工人怎么可能建造东西的速度比另一个建筑工人快 10 倍？然而编程是一门设计学科，并以一种非常特殊的方式。即使程序员不参与实际的程序的架构设计，实施它的行为仍然需要一个实施策略上的子设计。

因此，如果一个程序的设计和实现不是线性能力，像经验、编码能力、知识和识别等无用之物，在我看来，不仅仅是线性的优势，当这些事物作用在一起时，它们的效果就远不是一加一这么简单了。当然，当程序员可以同时处理程序的设计和实现时，这种现象发生得更多。如果越以“目标导向”为任务，那么拥有10倍效率潜力的程序员为了轻松地达到目标就越可以开拓她/他的能力。

当手头有非常刚性的任务时，这个任务有具体的指南：必须使用哪些工具和如何实现事物。那么 10 倍效率的程序员在更短的时间内执行大量工作的能力就被削弱了：他仍然可以开拓“局部”上设计的潜能，但却不能以更意义深远的方式去实现目标，这也许包括，可能、甚至完全从项目中删除部分规范，即便需要达到的目标几乎看起来相同但需要付出的努力程度由于一个大因素被减少了。

在作为程序员工作的二十年中，我观察着与我一起工作的其他由我指导的程序员同事，我下发指定的目标，他们则给 Redis 和其他项目提供补丁。期间，很多人告诉我，他们相信我是一个非常高效的程序员。考虑到我根本不是一个工作狂，我也把自己当作快速编码的一类人。

以下这些品质，我认为将引发程序员生产力高低截然不同：

纯粹的编程能力：完成子任务

程序员最显著的限制或优势之一就是处理实际执行程序部分的一个子任务：一个函数，一个算法等。令人惊讶的是，根据我的经验，非常有效地使用基本的命令式编程结构来实现某些功能的能力，并不像人们想象的那么普遍。在一个团队中，有时我观察到非常无能的程序员，甚至不知道一个简单的排序算法，和在理论上非常有能力、但实施解决方案的实践非常不足的刚毕业程序员相比，他们的工作往往事倍功半。

经验：模式匹配

通过使用经验：我的意思是一系列已经探索完成的用于大量重复的任务解决方案。有经验的程序员最终知道如何处理各种子任务。这既避免了很多的设计工作，也是针对设计错误的非常强大的武器，但反过来却又是简洁的最大敌人之一。

专注：实际时间 VS 虚假时间

如果不考虑时间质量，那么评价花费多少时间来编写代码是不恰当的。内部和外部因素都可能导致专注度下降。内部因素是拖延，对手边的项目缺乏兴趣（你不能做好你不喜欢的事情），缺乏运动/福祉，不好的睡眠质量或者睡眠不足。外部因素是频繁的会议，没有实际办公室的工作环境，同事经常打扰等等。很自然的是，尝试改善专注度和减少中断对编程生产率将产生非边际影响。有时为了变得专注，需要采取极端措施。例如，我只会偶尔阅读电子邮件，并且不回复他们中的大多数。

设计上的牺牲：删减 5%，获得 90%

当不愿意认识到一个项目的非基本目标占据了很大的设计复杂性，或者正在使另一个更重要的目标难以实现时，往往会产生复杂性，因为在基本特征和非基本特征之间有设计张力。设计师认识到设计中所有不容易实现的部分是非常重要的，即在努力和优势之间没有绝对的比例。为了最大限度地实现产出而执行的一个项目，将完全地集中在可以在合理的时间内实现的方面。例如，当设计Disque（一个消息的代理工具）时，在某些时候，我意识到通过为消息提供性能最好的顺序，项目的所有其他方面都可以大大提升：可用性、查询语言和客户端交互、简洁性和性能 。

简洁性

设计时保持简洁性，这个明显的观点意味着一切。为了理解什么是简洁性，核查复杂性大多数时候是如何产生的是值得做的。我认为复杂性的两个主要驱动因素：不愿意进行设计上的牺牲以及在设计活动中累积的错误。

如果在设计过程中，每次都追求错误的路径，我们将离最优解决方案越来越远。一个初始设计错误，在不好的方面，不会导致该系统重新设计。为了应对初始设计错误，却会导致另一个复杂的解决方案被设计。因此，项目在每个错误的步骤之后将变得更加复杂和效率低下。

实现简洁性的方式是以“概念证明”来推敲，从看起来最可行和直接的解决方案开始工作，以便大量简单的设计能在程序员脑中被探索。之后，经验和个人设计能力将有助于改进设计，并为需要解决的子设计找到合理的解决方案。

然而，每次需要实现一个复杂的解决方案时，重要的是要长时间地推敲如何避免复杂性，只有在没有更好的可能性的、即使考虑到完全不同的替代方案情况下，才继续这个方向。

完美主义，或者如何扼杀你的生产力和影响你的设计

完美主义有两种变体：在程序中达到最佳可衡量的性能的工程文化，以及作为一种人格特征。 在这两种情况下，我认为这是程序员快速交付事情的最大障碍之一。 完美主义和外部带有偏见的观点的恐惧带入了一种设计偏差，导致仅根据心理或简单可衡量的参数来改进设计时可选择项较少，其中诸如健壮性、简洁性、及时交付的能力往往不被考虑。

知识：一些理论将会有所帮助

在处理复杂任务时，有关数据结构的知识、计算的基本限制和非常适合于模拟某些任务的非平凡算法将对找到合适设计的能力产生影响。 成为一切事物的超级专家不是必需的，但是至少，知道一个问题的潜在解决方案是必需的。例如，应用设计牺牲（接受一些误差百分比）和清楚概率集合基数估计器可以组合在一起，以避免复杂、缓慢和记忆效率低下的用于统计整个流程中唯一的项目的解决方案。

底层：了解核心

即使使用高级语言，程序中的一些问题也是由于对计算机如何执行给定任务的误解而产生的。 这甚至可能导致需要从头开始重新设计和重新实现项目，因为在使用的工具或算法中存在着根本问题。良好的 C 语言能力，了解 CPU 的工作原理以及关于内核如何运行以及系统调用如何实现，这些可以避免糟糕的后期意外。

调试技巧

有时候为了发现那些 bug 会花费大量的工作时间。善于获取一个bug的状态、一系列合理的解决问题的步骤、以及编写不太可能包含太多错误的简单代码的态度，这三点对程序员的工作效率有很大的影响。

看到程序员的上述品质如何能够对输出产生 10 倍的影响，我并不奇怪。 结合起来讲，从可行的模式开始，它们允许良好的设计实现，可以比替代方法简单几倍。 有一种方法可以用来强调简洁性，我喜欢称之为“机会主义编程”。 基本上在每个开发步骤中，选择一系列要实施的功能，用最少的付出，以最大程度地影响程序的用户基础。