程序员不是砌砖工人，他们是做家

　　英文原文：Your Developers Aren’t Bricklayers, They’re Writers

若是你有 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？

　　-------------------------------------------------------------------------------------

　　译文连接：http://www.codeceo.com/article/programmer-not-bricklayers.html

　　翻译做者：码农网 – 小峰