假设你有10个程序猿，最好的那个可能至少比最差的那个好5倍。

这绝对不是胡扯。

我们这样定义“更好”：工作速度更快，产生的bug更少。代码更具可读性、逻辑性和可维护性。

程序猿不是砌砖工人，但他们往往被当成是砌砖工人。 （我并非说鄙视这些职业）

“为什么我须要高级程序猿，要知道同样的薪酬我能够雇两个0基础的了？”

“这个功能一个程序猿做须要三个月的时间。那就仅仅须要再加两个，就能够在一个月内搞定了。

”

为什么说上面的想法非常荒谬？由于我们没有一种简单又有效的方法来衡量程序猿的生产力。一旦碰到我们无法衡量的东西，我们就会忽略它。

我这样问你好了：你是愿意让两个新手来照应你的宝宝。维修你的车。给你做腰椎穿刺，还是宁愿找一个资深的？

相关研究表明。最好程序猿的生产力最高可比最差程序猿的高28倍。可是用在这些最好程序猿身上的成本肯定不会有这么多，所以他们是软件领域中最划算的“特价商品”。

ROBERT GLASS，《FACTS AND FALLACIES OF SOFTWARE ENGINEERING》

假设你一定要比較的话。那么事实上程序猿更像是作家。

有些作家写出的东西能数以百万计地卖出去，而有些作家写出来的东西无聊至极最后仅仅能用来烧火用！

可是，他们都生产出了一本书，因此，他们都是作家。可是除非你去阅读他们的书。否则你就不会知道他们俩的区别。

编程经理老早就认识到好程序猿和差程序猿两者的生产力有着天囊之别。但实际測得的数据结果依旧让我们全部人都大吃一惊。在研究中，Sackman、Erickson和Grant想要衡量一组经验丰富的程序猿的表现。结果表明，最佳和最差的生产力比例平均约为10：1，特别是编程速度的比例令人惊讶地达到5：1！
FRED BROOKS。《THE MYTHICAL MAN-MONTH》

以下给你讲一个真实的故事。（有关名字已作更改。）

一家软件公司须要在他们的标志产品中实现一个新的模块。Mr Lousy（差先生）刚好有空。于是就将这个任务交给了他。让他立刻开工！

经过四个月的修修补补，差先生最终完毕了。

QA团队发现存在着大量的bug和矛盾之处，并将报告返回给差先生。差先生依据报告又花了2周的时间来修复这些bug，并最终给出了一个新的版本号。那些该死的恼人bug真是绞尽了差先生的脑汁。

測试然后修复，如此循环了两三次。

用户已经在期待这个新的模块。销售人员也签署了一些新的客户。把这个模块做出来。并整合到下一版本号中这一过程的压力之大可想而知。

可是。所幸，成功了！

开香槟庆祝吧！

呀，不正确，新模块中依旧满是bug。

群众的眼睛总是雪亮的。客户总是特别擅长于找到一些曾经从未被发现的bug。

于是他们联系技术支持。技术支持团队再去找是什么地方出了错，是客户不知道怎样操作功能。还是他们自己搞错了。抑或这仅仅是一个bug，一个能够重现的bug。……然后技术支持团队提交了错误报告。于是，差先生悲剧了，——我的意思是。哪怕他正在搞还有一个项目。在这个时候也仅仅能放下手头的一切工作来解决这些麻烦事。

（这还没有涉及到代码的维护性。逻辑性和文档化问题——由于以后肯定会有其它人来改进这些代码）

可是，唉，怎么说呢……似乎有一些bug超出了差先生的能力范围。他根本修复不了。此外，不断出现的新bug。没人知道确实它们是新出来的，还是曾经就有但就是没有被发现而已的。

技术支持烦不胜烦。

而销售越来越恼火。由于新客户纷纷表示这个模块太不靠谱了。他们要取消合同！

最后，老板不得不让Mr Rockstar（好先生）来看一看这些代码。

好先生并不想为差先生收拾烂摊子，非常多结构在他眼中都是没有意义的。

他建议重写代码。预期大概须要一个月的时间。然后他开工了，仅仅比原先预计的多了几天就完毕了模块（他是好先生，而不是完美先生）。除了QA团队发现了一些小错误。一切都能如期工作。

QA团队在心里默默操心：假设全部的程序猿都像他一样。那他们就没实用武之地了。差先生觉得好先生这是在傲慢地嘲笑他，但他的看法对好先生而言是无关紧要的。

改进过的模块非常快公布了。

每一个人都非常高兴。由于最终能够正常工作了。

万岁！

如今真的到了能够开香槟庆祝的时候了！

可是此时。似乎全部人都忘记了好先生仅仅用了一个月左右的时间就成功搞定了差先生用了七八个月也搞不定的任务。

这两个开发者生产力水平的巨大差异由此可见一斑——他们执行的是全然同样的任务。

通过编写更精简但功能很多其它的代码，通过编写bug更少更易于维护的代码，一个优秀的开发者能够减轻QA人员，同事和管理人员的工作压力，提高身边每一个人的生产力。这就是为什么研究得出的这些数据，如28倍的生产效率是可能的。甚至可能还报低了。假设你纵览全局的话。
PHIL HAACK。《10 DEVELOPERS FOR THE PRICE OF ONE》

那么，在这个故事中可能会发生的最糟糕的事情是什么呢？

好先生最终注意到他比差先生的效率要高得多：他能轻易识别不良代码。可是尽管如此。他非常肯定自己的薪资和差先生的差点儿相同。他表示不满，甚至于毅然决然地离开。于是你的开发团队失去了一个高效的力量支柱。

即使他不离开。当面对由于公布/项目延迟导致的整个团队的加班，他会怎么想？离开是必定的。仅仅是时间早晚而已。

而且，假设你真的运气实在不佳，提了还有一个人去代替好先生的位置，却不幸是还有一个差先生的话，那我就仅仅能默默地为你点根蜡烛了。

那么，为什么我们总是习惯于忽略这个事实呢？

由于忽视比纠正问题easy得多——至少某种程度上，的确如此。

而且没人愿意做告发同事的小人。成为他丢掉饭碗的原因：由于搞不好差先生上有高堂要赡养。下有儿女嗷嗷待哺。也许他刚刚买了新房子，每一个月都要还贷——最重要的是，真的非常难衡量开发者的工作效率。除非你让他们俩做同样的任务来做对照，就像上面的故事一样。

于是我一直在想这个问题：该怎样衡量开发者的工作效率。我非常妒忌做销售的。由于他们的薪酬是依据业绩来的。

我有一些想法（还不成熟）能让你去其糟粕取其精华。我也有一些想法关于怎样识别、吸引和留住好的开发者。

我的身份以及我为什么要告诉你这些真相

我曾作为一个全职的开发者干了10多年。早在1989年我做出了我的第一个商业化的产品（游戏）。

尽管它并没有给我带来非常多钱。但感觉真的超好（那时我才16岁）。几年后。我出售了当中一个游戏点子。并最终公布于任天堂游戏机（以及其它格式）上。从我经验的角度。我能够告诉你，当你看到你想出来的东西（包含名称）最终出如今商店中，这感觉不要太爽。

2008年。我应聘了一家技术驱动公司的一个非技术职位。我想了解企业一般的执行模式，包含销售在内的企业中发生的全部非技术进程。尽管，我的技术能力对我的求职非常有帮助，但不再是工作的重要组成部分。

我不再为了谋生而编程（确切的说，是当时），但常常在业余项目上鼓捣各种新技术。对我来说。读一本好书。既令人兴奋，同一时候又能够得到放松。

在我眼下的岗位上，我常常会遇到一些误解概念或缺乏开发基本知识的人。

而在他们身处的职位上（一般是那些CxO们）。这些基础知识会造成巨大的影响。

非常多CxO会将开发者当作是砌砖工人，死板地计算他们的工作效率。可是，在这里，我想再次重申这个“作家理论”。开发者是脑力工作者。OK？

文章摘自码农网