咱们这么界说“非常好”：作业速度更快，发作的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?
