认识达内从这里开始

程序员不是砌砖工人，但他们往往被当成是砌砖工人。 

“为什么我需要高级程序员，要知道同样的薪酬我可以雇两个初级的了?”

“这个功能一个程序员做需要三个月的时间，那就只需要再加两个，就可以在一个月内搞定了。”

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

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

相关研究表明，最好程序员的生产力最高可比最差程序员的高 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》

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

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