程序猿不是砌砖工人,他们是作家

假设你有10个程序猿,最好的那个可能至少比最差的那个好5倍。

这绝对不是胡扯。

我们这样定义“更好”:工作速度更快,产生的bug更少。代码更具可读性、逻辑性和可维护性。

程序猿不是砌砖工人,但他们往往被当成是砌砖工人。 (我并非说鄙视这些职业)

“为什么我须要高级程序猿,要知道同样的薪酬我能够雇两个0基础的了?”

“这个功能一个程序猿做须要三个月的时间。那就仅仅须要再加两个,就能够在一个月内搞定了。

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

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

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

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

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

即使他不离开。当面对由于公布/项目延迟导致的整个团队的加班,他会怎么想?离开是必定的。仅仅是时间早晚而已。

而且,假设你真的运气实在不佳,提了还有一个人去代替好先生的位置,却不幸是还有一个差先生的话,那我就仅仅能默默地为你点根蜡烛了。

那么,为什么我们总是习惯于忽略这个事实呢?

由于忽视比纠正问题easy得多——至少某种程度上,的确如此。

而且没人愿意做告发同事的小人。成为他丢掉饭碗的原因:由于搞不好差先生上有高堂要赡养。下有儿女嗷嗷待哺。也许他刚刚买了新房子,每一个月都要还贷——最重要的是,真的非常难衡量开发者的工作效率。除非你让他们俩做同样的任务来做对照,就像上面的故事一样。

于是我一直在想这个问题:该怎样衡量开发者的工作效率。我非常妒忌做销售的。由于他们的薪酬是依据业绩来的。

我有一些想法(还不成熟)能让你去其糟粕取其精华。我也有一些想法关于怎样识别、吸引和留住好的开发者。

我的身份以及我为什么要告诉你这些真相

我曾作为一个全职的开发者干了10多年。早在1989年我做出了我的第一个商业化的产品(游戏)。

尽管它并没有给我带来非常多钱。但感觉真的超好(那时我才16岁)。几年后。我出售了当中一个游戏点子。并最终公布于任天堂游戏机(以及其它格式)上。从我经验的角度。我能够告诉你,当你看到你想出来的东西(包含名称)最终出如今商店中,这感觉不要太爽。

2008年。我应聘了一家技术驱动公司的一个非技术职位。我想了解企业一般的执行模式,包含销售在内的企业中发生的全部非技术进程。尽管,我的技术能力对我的求职非常有帮助,但不再是工作的重要组成部分。

我不再为了谋生而编程(确切的说,是当时),但常常在业余项目上鼓捣各种新技术。对我来说。读一本好书。既令人兴奋,同一时候又能够得到放松。

在我眼下的岗位上,我常常会遇到一些误解概念或缺乏开发基本知识的人。

而在他们身处的职位上(一般是那些CxO们)。这些基础知识会造成巨大的影响。

非常多CxO会将开发者当作是砌砖工人,死板地计算他们的工作效率。可是,在这里,我想再次重申这个“作家理论”。开发者是脑力工作者。OK?

文章摘自码农网

时间: 2024-10-06 01:09:55

程序猿不是砌砖工人,他们是作家的相关文章

程序员不是砌砖工人,他们是作家

程序员不是砌砖工人,他们是作家 作者: Piet Hadermann  来源: 码农网  发布时间: 2015-06-07 20:14  阅读: 6564 次  推荐: 28   原文链接[收藏] 英文原文:Your Developers Aren't Bricklayers, They're Writers 如果你有 10 个程序员,最好的那个可能至少比最差的那个好 5 倍.这绝对不是胡扯. 我们这样定义"更好":工作速度更快,产生的 bug 更少,代码更具可读性.逻辑性和可维护性.

程序员不是砌砖工人,他们是作家【转】

如果你有10个程序员,最好的那个可能至少比最差的那个好5倍.这绝对不是胡扯. 我们这样定义“更好”:工作速度更快,产生的bug更少,代码更具可读性.逻辑性和可维护性. 程序员不是砌砖工人,但他们往往被当成是砌砖工人. (我并不是说歧视这些职业) “为什么我需要高级程序员,要知道同样的薪酬我可以雇两个初级的了?” “这个功能一个程序员做需要三个月的时间,那就只需要再加两个,就可以在一个月内搞定了.” 为什么说上面的想法很荒谬?因为我们没有一种简单又有效的方法来衡量程序员的生产力.一旦碰到我们无法衡

程序猿生存定律--管理向左,技术向右

一个程序猿在考虑增值时无法回避的一个根本问题是究竟是做技术还是做管理.当然也有些职位会介于两者之间比方架构师.但我们临时不去做细分.而是用简单的二分法. 这样的基本方向上的选择对兴许非常多细节上的取舍有关键影响.所以在考虑其它之前.最好先回答一下这个问题.这就和修炼时要选择少林.武当.华山还是魔教一样,一旦选择,基本上是回不了头. 当然选择管理不意味着不须要掌握编程技能.毕竟当下大多公司还是信奉"宰相拔于州郡.将军起于行伍"的.但当技术达到一定水平后,管理还是技术这样的方向性的选择将对

程序猿生存定律--细论软件这个行当的根本特征

程序猿生存定律这系列的文件夹在这里:程序猿生存定律--文件夹 喜欢从头瞄的.能够移步. ------------------------------------------------------------------------------ 规律是必须顺应而不能改变的.但除此之外现实中另一些事实也是无法改变的,这两者都非常像程序中的常量,想提高人生的高度则须要同一时候驾驭这两者,而不能试图为两者赋值.以下我们就一起来看一下,软件世界中仅仅能顺应,而不能试图改变的特质有那些. 技术更迭偏快 在

中国特色程序猿的「钱途」

今天在微博看到一篇文章,程序猿转型书商 年交易额千万元.作为一个合格的中国特色的码农.忍不住想写点儿什么. 程序猿的「钱途」在那里? 从出版业说起 网络作品排到靠前的,都不会太难看,一般人不爱看某部作品也是由于不喜欢这个类型,而此人也不会全不喜欢这些网络作品.究其原因,是由于网络作品都是让人先白看的,看的好了才出了头.而纸质作品就不一定了,排行榜靠前的,有好作品,也有垃圾. 很多大牛都是写了博客,后来出了书.这些书也都不次,可能有人让为不好,是由于技术书不像小说.小说在读故事,技术书是在学知识或

“程序猿”随笔之武汉龟山印象

“程序猿”,是我们这些与代码打交道的程序员们的网络“雅号”.我不记得什么时候知道自己这个雅号的,大概是从网络疯传“程序员卖肉夹馍”开始的吧,~_~. 可能是受<人猿泰山>和<西游记>的影响,我从小就喜欢树木.山水,只可惜我老家是江汉平原的古战场荆州,一马平川.毕业后“南下”广州,白云山成了我最常去的“公园”,旅行也是优选深山大泽. 转眼间,天庭过去了十几天,人间过去了十几年,到了2013年,我已经在武汉8年多了.我的旧文说过2013年春搬家到武汉龟山脚下,从此经常进山里闲逛, ~_

程序猿生存定律--细论影响人生成绩的四个要素(1)

程序猿生存定律这系列的文件夹在这里:程序猿生存定律--文件夹 喜欢从头瞄的.能够移步. ---------------------------------------------------------------------------------------------- 定律要素之中的一个:自身价值 在金庸先生构建的武侠世界里,最犀利的杀伐武功应该是<独孤九剑>,但学会了独孤九剑却失了内功的令狐冲一样会被一堆无赖按到地上揍个鼻青脸肿.待到学会了吸星大法,内力大进,那就再没这回事了. 依据

连载《一个程序猿的生命周期》-《发展篇》- 12.向生活妥协的选择之路,你也面临吗?

本篇文章的主角是第二个加入我们团队的,暂且称他为G兄.是我第二家公司的同事,但是当时并没有交集,后来经过其他同事说起,被我招过来的.关于第二家公司的情况,请参见<而立之年,第一次跳槽,寻求转型> 在加入我们团队之前,G兄在一个不大不小的公司做内部OA系统,众所周知不会有什么太大发展,他当时也不太满意.在和他交流的过程中,我说的很直接:1.开发公司内部OA,并非公司实际产品,无法直接创造利润,就算是公司的产品,现在做OA的多了去了.2.OA开发完成后,只剩运维人员,假设裁掉一部分人员的话,你怎么

Java程序猿学习当中各个阶段的建议

回答阿里社招面试如何准备,顺便谈谈对于Java程序猿学习当中各个阶段的建议 引言 其实本来真的没打算写这篇文章,主要是LZ得记忆力不是很好,不像一些记忆力强的人,面试完以后,几乎能把自己和面试官的对话都给记下来.LZ自己当初面试完以后,除了记住一些聊过的知识点以外,具体的内容基本上忘得一干二净,所以写这篇文章其实是很有难度的. 但是,最近问LZ的人实在是太多了,为了避免重复回答,给自己省点力气,干脆就在这里统一回复了. 其实之前LZ写过一篇文章,但是那篇文章更多的是在讨论“面试前该不该刷题”这个