如果你有10个程序员，最好的那个可能至少比最差的那个好5倍。这绝对不是胡扯。
我们这样定义“更好”：工作速度更快，产生的bug更少，代码更具可读性、逻辑性和可维护性。
程序员不是砌砖工人，但他们往往被当成是砌砖工人。 （我并不是说歧视这些职业）
“为什么我需要高级程序员，要知道同样的薪酬我可以雇两个初级的了？”
“这个功能一个程序员做需要三个月的时间，那就只需要再加两个，就可以在一个月内搞定了。”
为什么说上面的想法很荒谬？因为我们没有一种简单又有效的方法来衡量程序员的生产力。一旦碰到我们无法衡量的东西，我们就会忽略它。
我这样问你好了：你是愿意让两个新手来照顾你的宝宝，维修你的车，给你做腰椎穿刺，还是宁愿找一个资深的？
相关研究表明，最好程序员的生产力最高可比最差程序员的高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》
那么，在这个故事中可能会发生的最糟糕的事情是什么呢？
好先生终于注意到他比差先生的效率要高得多：他能轻易识别不良代码。但是尽管如此，他很肯定自己的薪资和差先生的差不多。他表示不满，甚至于毅然决然地离开。于是你的开发团队失去了一个高效的力量支柱。
即使他不离开，当面对由于发布/项目延迟导致的整个团队的加班，他会怎么想？离开是必然的，只是时间早晚而已。
并且，如果你真的运气实在不佳，提了另一个人去取代好先生的位置，却不幸是另一个差先生的话，那我就只能默默地为你点根蜡烛了。
那么，为什么我们总是习惯于忽略这个事实呢？
因为忽视比纠正问题容易得多——至少某种程度上，的确如此。并且没人愿意做告发同事的小人，成为他丢掉饭碗的原因：因为搞不好差先生上有高堂要赡养，下有儿女嗷嗷待哺；或许他刚刚买了新房子，每个月都要还贷——最重要的是，真的很难衡量开发人员的工作效率，除非你让他们俩做相同的任务来做对比，就像上面的故事一样。
于是我一直在想这个问题：该如何衡量开发人员的工作效率。我很嫉妒做销售的，因为他们的薪酬是根据业绩来的。我有一些想法（还不成熟）能让你去其糟粕取其精华。我也有一些想法关于如何识别、吸引和留住好的开发人员。
我的身份以及我为什么要告诉你这些真相
我曾作为一个全职的开发人员干了10多年。早在1989年我做出了我的第一个商业化的产品（游戏）。虽然它并没有给我带来很多钱，但感觉真的超好（那时我才16岁）。几年后，我出售了其中一个游戏点子，并最终发布于任天堂游戏机（以及其他格式）上！从我经验的角度，我可以告诉你，当你看到你想出来的东西（包括名称）最终出现在商店中，这感觉不要太爽。
2008年，我应聘了一家技术驱动公司的一个非技术职位。我想了解企业一般的运行模式，包括销售在内的企业中发生的所有非技术进程。虽然，我的技术能力对我的求职很有帮助，但不再是工作的重要组成部分。
我不再为了谋生而编程（确切的说，是当时），但经常在业余项目上鼓捣各种新技术。对我来说，读一本好书，既令人兴奋，同时又能够得到放松。
在我目前的岗位上，我经常会遇到一些误解概念或缺乏开发基本知识的人。而在他们身处的职位上（通常是那些CxO们），这些基础知识会造成巨大的影响。
很多CxO会将开发人员当作是砌砖工人，死板地计算他们的工作效率。但是，在这里，我想再次重申这个“作家理论”，开发人员是脑力工作者，OK？
英文原文：Your Developers Aren’t Bricklayers, They’re Writers
