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

“为什么我需要高级程序员，要知道同样的薪酬我可以雇两个初级的了
“这个功能一个程序员做需要三个月的时间，那就只需要再加两个，就可以在一个月内搞定了。”
为什么说上面的想法很荒谬为我们没有一种简单又有效的方法来衡量程序员的生产力。一旦碰到我们无法衡量的东西，我们就会忽略它。
我这样问你好了：你是愿意让两个新手来照顾你的宝宝，维修你的车，给你做腰椎穿刺，还是宁愿找一个资深的/span>
相关研究表明，最好程序员的生产力最高可比最差程序员的高28 倍。但是用在这些最好程序员身上的成本肯定不会有这么多，所以他们是软件领域中最划算的“特价商品”。
如果你一定要比较的话，那么其实程序员更像是作家。
有些作家写出的东西能数以百万计地卖出去，而有些作家写出来的东西无聊至极最后只能用来烧火用！
但是，他们都生产出了一本书，因此，他们都是作家。可是除非你去阅读他们的书，否则你就不会知道他们俩的差别。
编程经理老早就认识到好程序员和差程序员两者的生产力有着天囊之别。但实际测得的数据结果依然让我们所有人都大吃一惊。在研究中，Sackman、Erickson 和 Grant 想要衡量一组经验丰富的程序员的表现。结果表明，最佳和最差的生产力比例平均约为 10：1，特别是编程速度的比例令人吃惊地达到5：1！
下面我给你讲一个真实的故事。（有关名字已作更改。）
一家软件公司需要在他们的标志产品中实现一个新的模块。Mr Lousy（差先生）刚好有空，于是就将这个任务交给了他，让他立马开工！
经过四个月的修修补补，差先生终于完成了。 QA 团队发现存在着大量的 bug 和矛盾之处，并将 告返回给差先生。差先生根据 告又花了 2 周的时间来修复这些 bug，并最终给出了一个新的版本！那些该死的恼人 bug 真是绞尽了差先生的脑汁。
测试然后修复，如此循环了两三次。
用户已经在期待这个新的模块。销售人员也签署了一些新的客户。把这个模块做出来，并整合到下一版本中这一过程的压力之大可想而知。但是，所幸，成功了！开香槟庆祝吧！
呀，不对，新模块中依然满是 bug。群众的眼睛总是雪亮的，客户总是特别擅长于找到一些以前从未被发现的 bug。于是他们联系技术支持。技术支持团队再去找是什么地方出了错，是客户不知道如何操作功能，还是他们自己搞错了，抑或这只是一个 bug，一个可以重现的 bug。…… 然后技术支持团队提交了错误 告。于是，差先生悲剧了，——我的意思是，哪怕他正在搞另一个项目，在这个时候也只能放下手头的一切工作来解决这些麻烦事。

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

但是，唉，怎么说呢……似乎有一些 bug 超出了差先生的能力范围，他根本修复不了。此外，不断出现的新 bug，没人知道确实它们是新出来的，还是以前就有但就是没有被发现而已的。技术支持烦不胜烦。而销售越来越恼火，因为新客户纷纷表示这个模块太不靠谱了，他们要取消合同！

最后，老板不得不让 Mr Rockstar（好先生）来看一看这些代码。
好先生并不想为差先生收拾烂摊子，很多结构在他眼中都是没有意义的。他建议重写代码，预期大概需要一个月的时间。然后他开工了，只比原先估计的多了几天就完成了模块（他是好先生，而不是完美先生）。除了 QA 团队发现了一些小错误，一切都能如期工作。 QA 团队在心里默默担心：如果所有的程序员都像他一样，那他们就没有用武之地了。差先生认为好先生这是在傲慢地嘲笑他，但他的看法对好先生而言是无关紧要的。