“一个优秀的程序员的生产力可以是普通程序员的10倍”。


54

我读过一位优秀程序员的采访(不是英语),他说“一位优秀程序员的收入是普通程序员的10倍”,这说明了为什么优秀程序员的报酬很高以及为什么编程公司为员工提供了许多便利。想法是,由于上述原因,对优秀的程序员有很大的需求,这就是为什么公司为此付出很多代价。

你是否同意这种说法?您是否知道任何客观事实可以支持它?

编辑:问题与经验无关;如果您谈论一位具有1年经验的优秀程序员,那么他/他的工作效率应该比具有1年经验的普通程序员高10倍。我同意从某些经验开始,事情开始消散,但这不是问题的目的。


您可以发布采访链接吗?
Mirco

1
@ area404正如我所说的,这不是英文:economie.hotnews.ro/...
m3th0dman


9
10X生产率差为程序员测量一个众所周知的事实(麦康奈尔12

Answers:


41

史蒂夫·麦康奈尔Steve McConnell)撰写的两篇文章对生产力差异的研究进行了非常全面的概述和分析:

第一篇文章(生产率变化...)指出:

...最初的研究发现个人编程效率存在巨大差异,是由Sackman,Erikson和Grant(1968)在1960年代后期进行的。他们研究了平均有7年经验的专业程序员,发现最佳和最差程序员之间的初始编码时间之比约为20:1;调试时间超过25:1的比例;程序大小为5比1;程序执行速度约为10到1。他们发现程序员的经验量与代码质量或生产率之间没有任何关系。

对Sackman,Erickson和Grant的发现进行的详细检查显示出他们的方法存在一些缺陷……但是,即使考虑了这些缺陷,他们的数据也仍然显示出最好的程序员与最差的程序员之间的差异超过10倍。

自原始研究以来的许多年中,“许多程序员之间存在数量级差异”的普遍发现已被许多其他有关专业程序员的研究所证实(Curtis 1981,Mills 1983,DeMarco和Lister 1985,Curtis等1986)。 ,Card 1987,Boehm and Papaccio 1988,Valett and McGarry 1989,Boehm et al 2000)...

本文还有一个有趣的旁注:

这种变化程度并非软件独有。范·奥古斯丁(Norm Augustine)的一项研究发现,在写作,足球,发明,警察工作和其他职业等各种职业中,无论输出是触地得分,专利权,最富有的20%的人生产了大约50%的产出。 ,已解决的案例或软件(Augustine,1979年)。


第二篇文章(...基础研究的有效性如何?)主要是针对Laurent Bossavit对第一篇文章的评论而撰写的:

在第二篇文章的“深入研究”一节中,支持“ 10倍”麦康奈尔更详细地检查了第一篇文章中使用的参考文献,并得出以下结论:

...当我在撰写本文时再次审视这些引文时,我再次得出结论,它们支持普遍的发现,即程序员之间的生产力差异是10倍。这项研究使数百名专业程序员参与了各种编程活动。

...支持10倍索赔要求的研究机构与软件工程领域的任何研究一样扎实。支持10倍索赔的研究完全不受图1中所述方法的限制,因为它们正在研究个体变异性本身(即,仅在图的左侧)。Bossavit甚至没有引用一项研究(有缺陷或其他)来抵消10倍的索赔要求,而且我也没有看到任何此类研究。没有研究得出与10倍索赔相抵触的发现这一事实为10倍索赔提供了更大的信心。当我考虑已经完成的研究数量时,总的来说,我发现该研究不仅具有启发性,而且具有决定性,这在软件工程研究中很少见。


为了完整起见,下面还引用了生产力变化中使用的参考文献列表:

参考文献

奥古斯丁,NR,1979年。“奥古斯丁法律和主要系统开发计划。” 国防系统管理评论:50-76。

Boehm,Barry W.和Philip N. Papaccio。1988年,“了解和控制软件成本”。IEEE Transactions on Software Engineering SE-14,no。10月(10月):1462-77。

Boehm,Barry等人,2000年。《使用Cocomo II进行软件成本估算》,马萨诸塞州波士顿:Addison Wesley,2000年。

Boehm,Barry W.,TE Gray和T.Seewaldt。1984年。“原型与指定:多项目实验”。IEEE Transactions on Software Engineering SE-10,no。3(5月):290-303。同样在琼斯1986b中。

卡,David N.,1987年。“软件技术评估程序”。信息和软件技术29,没有。6(7月/ 8月):291-300。

柯蒂斯,比尔。1981年。“证实程序员的可变性”。IEEE 69,No。7:846。

Curtis,Bill等。1986年。“软件心理学:需要跨学科计划。” IEEE 74,No。8:1092-1106。

DeMarco,Tom和Timothy Lister。1985年,“程序员的表现和工作场所的影响”。第八届软件工程国际会议论文集。华盛顿特区:IEEE计算机协会出版社,第268-72页。

DeMarco,Tom和Timothy Lister,1999年。Peopleware:生产性项目和团队,第二版。纽约:多塞特郡(Dorset House),1999年。

Mills,Harlan D.,1983年。《软件生产力》。马萨诸塞州波士顿:小布朗。

Sackman,H.,WJ Erikson和EE Grant。1968年。“在线和离线编程性能比较的探索性实验研究”。ACM 11的通讯,编号。1(1月):3-11。

Valett,J.和FE McGarry。1989年,“在软件工程实验室中进行软件测量的经验总结。” Journal of Systems and Software,9号。2月(2月):137-48。

温伯格,杰拉尔德·M和爱德华·舒尔曼。1974年,“计算机编程的目标和性能”。人为因素16,否。1月(2月):70-77。


13
“支持10倍要求的研究机构与在软件工程领域所做的任何研究一样扎实” –是的,确实如此。:)

另请参阅Bossavit和McConnell(及其他人士)之间的讨论,在McConnell的第二篇文章中
DNA

92

一个真正可怕的程序员的生产力可能会低于零(他们引入的错误需要的修复时间比为他们完成所有工作所需的时间更长)。

而一个真正伟大的程序员可以做的事情,穷人和普通的程序员只会永远不会实现的,不管你有多少时间给他们。

因此,由于这些原因,很难谈论“生产效率提高10倍”或“生产效率提高100倍”。

但是要记住的是,大多数程序员的雇主都不需要他们去执行普通程序员无法管理的艰巨任务。编写的大多数代码是网站,业务应用程序,Intranet应用程序等,其中许多实际上并不那么困难。在那种环境下,富有成效的程序员是最擅长理解和实现用户需求的程序员,而不是能够编写最聪明代码的程序员。

的确,大多数程序员的雇主都会选择一个好的程序员而不是一个优秀的程序员,这会更好,因为优秀的程序员只会感到无聊而离开。要找到程序员和工作之间的良好搭配。


33
就像可怕的程序员可以降低周围人们的生产力一样,优秀的程序员可以提高周围人们的生产力。他们产生易于扩展的代码,与他们进行五分钟的交谈可以使其他程序员走上更好的轨道。
砸了机器人的时间

8
与真正糟糕的程序员相比,生产率为零的程序员非常聪明。
glenatron 2012年

您如何衡量好诗人比坏诗人更有生产力?如果您想要高质量的输出,某些人可能会生产,而其他人可能无法生产。现在您的公司是在创作诗歌,还是向客户发送提醒电子邮件?:P
mika 2014年

30

软件工程的事实和谬论陈述(事实2,在Amazon预览中可用):

根据“个体差异”研究,最好的程序员比最差的程序员高28倍。鉴于他们的薪水从来都不相称,因此它们是软件领域最大的便宜货。

(在此处查找来源列表以进行研究)

当然,如果您将一个非程序员(或一个非常糟糕的程序员)的生产力与一个优秀的程序员(在经验和知识方面)进行比较,则差异可能是无限大的(n/0 == infinity对于任何积极的方面n),但这既不公平也没有明智的比较。

您的薪水可能取决于多种因素(随机排列):

  • 使用的技术
  • 您工作的国家/州
  • 公司财富
  • 公司业务类型
  • 公司中的开发人员数量
  • 您在公司工作多长时间
  • 办公室政治

与您的个人...

  • 生产率
  • 知识和经验
  • 参与公司业务(针对初创公司)
  • 谈判技巧
  • 性吸引力和技能,大声笑(嗯,智力很性感)

20

我的回答是“是,但是请谨慎使用该指标”。

我们可以说,一个发挥最佳功能的程序员是一个为功能而创造的人,与导致其性能下降的兄弟相比,他需要修复的错误更少。我不难相信,这些人的工作效率是其他人的10倍,尤其是当您考虑到一个小时内做出的一个好或坏选择很容易产生10个小时的影响,而程序员做出了许多这样的选择时,尤其如此大多数日子。

但...

在测量时要小心。我真的不相信大多数关于生产率的度量,因为我看到了无数种情况,其中几乎每个已知指标都没有考虑到我认为对团队生产率至关重要的因素。因此,我通常讨厌这样的数字来“提高生产率”。以下是一些示例:

  • 代码行(LOC)-通常令人讨厌的度量标准,因为一个精打细算的程序员会生成许多可怕的,冗长的,低效的,难以调试的代码行,而一个好的程序员会创建一些优雅,易于修复,很少破坏的代码行需要更多时间,但总体而言是更好的选择。
  • 产生的错误和/或修复时间-每个人都会产生一些错误,并且最昂贵的错误通常是由一系列错误的决定所产生的,对于这些错误的决定,问题的产生者只是多米诺骨牌效应中的最后一个。而且,您出色的调试器并不总是您的出色设计器-您需要同时使用。
  • 从几乎任何指标上来说,都有一个伟大的开发人员在团队中如此痛苦,以至于一位“超级生产力”开发人员将赶走10名基本优秀的开发人员,而我很少见到有人能够将所有事情做好,所以我们需要该项目有1个以上的人。
  • 无法轻松地解释那些优秀的人员,他们会在问题变得严重之前就将其解决,并加以解决,特别是当问题是过程中存在缺陷时-CM错误,构建效率低下,测试缺陷,安全缺陷-这些直到您意识到他们可以使您从灾难中救出时,您似乎常常会浪费大量时间-无法衡量。
  • 另外,我认为有些人需要一支具有一定规模的团队,我称之为“凝聚力建设者”-很少是绝对的最高生产力,他们通常仍处于20%的最高水平,并且他们在帮助提升工作方面做出了宝贵的工作新人们,将各个问题联系在一起,并确保正确的问题被询问,并且正确的人员被留在循环中,他们写了(没问!)每个人都参考的关键文档,因为它不仅是正确的文档,而且是正确的文档它以正确的方式组合在一起。如果您想让10个人以最高效率工作,那么您绝对需要这些人中的一个,如果将10个超级开发人员放在一个房间中,您将一无所获。

许多评估系统都试图将这些因素考虑在内,但我尚未看到有一个将所有这些因素都考虑在内的系统,因此,我对诸如“一个好的开发人员的生产力要比一个好的开发人员高出10倍”之类的因素印象深刻。平庸”,因为我必须怀疑指标是否真正说明了成功进行中的产品或成功,蓬勃发展的团队所需的所有工作。

所以我最大的警告是-您将如何处理此指标?我将使用类似的方法来意识到正确的工具和才能会在工作方式上产生很大的差异,但是如果您尝试优化团队,使每个人都能产生10倍“典型”输出,那么您必然会一个无奈的情况。更好的方法是找到一种方法,让您的团队通过更好地合作来使他们的工作比以前提高2-3倍。


不用说,我也有。:)
bethlakshmi

对于提出并相信10倍索赔要求的人们来说,这是一个非常明显的优点。您如何衡量程序员的生产力?在我们能够准确,准确和可靠地做到这一点之前,索赔只是一个神话。
乔丹·里格2014年

这不是神话,请参阅其他答案中的参考。这里提出的观点不是反驳,而是在生产力上提供了更大的范围。
2014年

10

Laurent Bossavit 在他的《软件工程的妖精》一书中描述了研究10倍生产率的说法。他发现背后没有任何声音数字-通过电话游戏,引用逐渐变得更具体,这种说法已经从推测变成了“既定事实” 。博客文章包括有关10x要求的章节,并包括相关的引用和错误引用,这是软件工程中的事实和民间传说

他发现的结果是这样的:1968年某人进行了一项研究,比较了解决特定调试问题的人员,发现其中一些人的调试速度比其他人快10倍。由此我们可以得出结论,有些人在解决该问题上的能力要高出十倍,或者可以得出结论,有些人很幸运,或者各种各样的事情。有些人选择引用这些作为(所有这些都是措辞):“一项研究(Sackman等,1968)发现某些程序员的工作速度比其他程序员快10倍”。然后变成“研究表明,好的程序员要比平均水平好10倍”,然后最终“众所周知,程序员之间的生产率差异是个人的10倍”。然后有人收集了所有这些引用,但引用了一个原始来源 说“许多研究人员相信……”。

当然,如果仅更改断言的准确性,那将不是电话游戏:乘数也等于11


另请参阅Bossavit和McConnell(及其他人士)之间的讨论,在McConnell的第二篇文章中
DNA

2

在那种环境下的生产力程序员是最能理解和实现用户需求的程序员,而不是能够编写最聪明的代码的程序员 ”(摘自Carson63000的回答)

该关键点与bethlakshmi结合在一起的观点很重要。优秀的开发人员可以在自己的现实世界中发挥自己的作用,但是随着世界的变化而迅速瓦解。能够满足业务需求比什么都重要。归根结底,除非您的业务是技术,否则业务不会在乎技术。他们需要解决方案。因此,拥有出色的设计模式并不意味着会深深吸引那些只需要数据转储以显示在网页上的最终用户。我见过平庸的开发人员通过迎合支持他们的业务来确保自己的工作,而优秀的开发人员却无聊又走了,以寻求永无止境的挑战。根据您的组织和项目,有可能养活这些面临挑战的开发人员,但很可能会有一段时间,您只是不 不需要那么多的处理能力。这些开发人员不喜欢像处理器一样闲着。他们将关闭并在其他地方重新启动。

最后,我想知道您的“关键”表演者是谁是可以的,但是开发“团队”仍然是一个团队。重申bethlakshmi,“ 您将使用该指标做什么?“如果您需要一支表现得像团队的团队,那么我就不会专注于这些指标。我会意识到,即使最小的参与者也仍然是团队的重要组成部分。即使您的关键生产力降低了60%玩家,一个玩家可能正在为您的团队提供所需的东西。找出它并尝试乘以它。不要以假设他应该领导团队而精疲力竭,也不要想办法增加乘积,通过污染其他玩家,这需要一些创造力,而不仅仅是数字。最后,您可能会发现,造就一个好的程序员的根本不是那个程序员,它可能是他的同龄人,他在工作场所的机会甚至可能是你。


欣赏编辑。现在,为什么要投票?我们是说团队动态对开发人员的价值和生产力毫无价值吗?
Draghon
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.