程序员的天才神话

   自从软件开发中的社交危机问题以书籍形式出现后,将关注焦点聚集于一个可变因素之上成为了可能,这个可变因素便是——人。

   人类天生就不是完美的。但你在了解到同事的缺点之前,需要先了解自身的问题。请你思考自己的行为举止和态度。而作为回报,我们希望你可以获得一些真正有用的在如何成为一名高效成功的软件工程师的问题上的洞察力。你将在与他人就某一问题达成协议上花费更少的精力,而省下更多的时间创作优秀的代码。

   本章的重点是要理解,软件开发是一项团队活动。为了在工程团队的基础上完成目标,你需要改变受自身人格核心原则影响而产生的行为、尊重,和信任。

   在开始之前,先让我们看看程序员在一般情况下的行为举止。

帮我隐藏我的代码

   在过去6年间的开发大会上,我们两人已经做过很多很多的演讲。自从我们在2006年作为最初队伍的一部分接手谷歌开源项目托管服务以来,我们收到了大量的关于产品的提问和请求。将时间调回2008年中,我们在一堆请求中注意到了一个与众不同的趋势。以下是我们得到的:

    - 你们有能力给出Google Code上的Subversion的详细分支吗?

    - 你们是否可以在创建项目并开始之前将其隐藏,直到开发完后再公布于世呢?

    - 嗨,我想重写草稿上的全部代码,你们可以清除掉所有的历史记录吗?

   你可以发现这些请求的共同之处吗?

   这里的关键动机在于,不安全性。人们害怕他人在日常生活中看到并且评论自己的工作。从一方面讲,这是一种人类天性——没有人喜欢被批评,特别是在工作正在进行,尚未结束的时候。这种态度将我们推到了软件开发的风口浪尖。不安全性从根本上讲,是一个大问题的症状表现。

天才的神话

   首先,我们需要明白一件事:我们并不是真正的体育运动粉。每当我们的妻子为电视上的篮球或橄榄球比赛而欢呼尖叫时,我们都挠头苦思是什么让她们如此兴奋。不过,我们确实经历了20实际90年代初期,并亲眼目睹了芝加哥公牛队(这是一支篮球队)夺冠。这段时间我们正好在芝加哥,全国的媒体(national media)对这支梦之队的故事跟踪报道了好几年。

   我们在报纸和电视上听到最多的是什么?不是公牛队这支球队,而是Michael Jordan,那个超级球星。世界上所有的球员都希望成为下一个Michael Jordan。我们看到他绕着其他球员跳舞;我们看到了他电视上的商业广告;我们观看的一部他和一群卡通人物打篮球的电影(迪士尼1996年拍摄,空中大灌篮)。他是明星,每一条街区的每一个孩子都在私下里练习投篮,希望跟着他的脚步成长。

   程序员有着同样的天性——寻找偶像,崇拜偶像。Linus Torvalds,Richard Stallman,Bill Gates——所有的用丰功伟绩改变了世界的传奇人物都在其列。Linus独立开发了Linux操作系统吗?

enter image description here

当心出于本能的极端崇拜。

   事实上,Linus只是写出了类Unix内核代码,并且将其发到邮箱列表中。这不是一个小小的任务分配,而绝对是一个令人钦佩的壮举。但这只是冰山一角。Linux系统的全部代码量是Linus贡献代码量的数百倍,由数百天才共同开发。Linus的真正成就是领导并协调众人的工作。Linux是他们集体劳动的耀眼成果(顺便说一句,Unix系统是由在贝尔实验室的一个天才小组开发,而不是仅由Ken Thompson和Dennis Richie两人创作)。

   同样的,Stallman单独开发了基于自由软件标准的软件吗?他的确单独完成了Emacs的初代版本。但其他数百名程序员认真负责地完成了bash、GCC工具链,以及所有运行在Linux下的支持软件。Steve Jobs领导了一整支团队构建Macintosh(苹果麦金塔电脑)。当人们了解到Bill Gates为早期的家庭计算机写了一个BASIC解释器的时候,他已完成了更大的成就,基于MS-DOS创办了一家成功的公司。最终他们都依靠出色的合作能力成为了领导者和领军人物。

   而Michael Jordan呢?

   我们极端地崇拜他。但事实却是,他并没有靠自己赢过一场球赛。他真正的天赋其实是与他的团队共事。球队教练Phil Jackson非常智慧——他的指导战术富有传奇色彩:他把每一个从未赢过冠军的球员重组在一起,并一MJ为中心将他们称为“梦之队”。球队就像是一部上好油的机器,每个人都像MJ一样为自己感到骄傲。

   那么为什么我们要反复崇拜这些故事中的个人?为什么大众会买那些带有名人签名的产品?为什么我们会想要购买与Michelle Obama所穿同款的裙子或Michael Jordan的同款战靴?

   名人效应占原因的很大一部分。人类天性使然会寻找领导者或模范,并崇拜他们,尝试模仿他们。我们都为了能受到鼓舞而需要英雄,在编程界也同样如此。这种“技术大神”的现象几乎成为神话。我们都希望写出一些像Linux一样可以改变世界的东西,或是设计下一个杰出的程序语言。

   内心深处我们都悄悄地希望自己是天才。终极极客幻想是被一种超棒的全新概念所冲击。你在你的小角落中一呆便是几周甚至几月,为了一个点子的完美实现而拼命工作。然后你将自己的软件“解放”到世界,让人们为你的天才所震撼;让同事们为你的聪明而惊讶。成群的人使用你的软件。名望与财富自然而然地随之而来。

   但请稍等,让我们认清现实,你也许并不是一个天才。

   无意冒犯,当然——我们肯定你是一个聪明的家伙。但你是否真正意识的到现实中的天才是怎样的吗?当然,你会写代码,这是一项富有诀窍的技术,可以归到超越大多数人的一类中去。但这还不足以将你划为天才。天才也会失误,即便拥有精英级的编程技术也无法保证你的软件会一次成功。可以成就或毁掉你的事业的,是你能多好地与他人合作。

   你会发现,天才神话正是造成我们不安全性的另一个放面。大多数程序员都害怕分享他们刚刚开始的工作,因为这意味着同事们会看到他们的失误,发现代码的编写者并不是一个天才。在此引用另一个程序员Ben的博客:

   我知道在人们完成工作之前我会严肃地审视他们,就像他们会认真评论我并且认为我是一个蠢货一样。

   这在程序员中是一个非常普通的感觉自然的反应是低调隐藏自己,然后工作,工作,再工作!没有人会看到你的粗心大意。你仍有机会在完成之时将你的杰作公之于众。隐藏它们,直到你将之完善到极致。

   另一种“将卡紧紧护在胸前”的一般动机是担心另一个程序员会拿走你的创意并且先你一步付诸行动。你将其重重保护加密,从而控制创意不会外泄。

   我们大概知道你现在在想什么了:那又如何?难道人们不应该被允许随心所欲地工作吗?

   事实上,这是不被允许的。在这件事上,我们断言你是错的,并且是大错。接下来我们会给出理由。

隐藏是有害的

   如果你所有时间都在单独工作,那么你是在增加失败的风险,欺骗你的成长可能性。

   首先,你如何知道自己是在正确的轨道上?

   想象你是一个自行车设计的骨灰粉,有一天你想到一个绝妙的方法去用一种全新的方式设计齿轮变速器。你收集零件,开始把自己关在车库连续几个星期试着做出一个原型。当你的邻居——同样是一个自行车爱好者,询问你最近怎么样时,你决定不谈论关于创意的事情。在完成作品之前,你不希望被任何人知道项目的存在。又几个月过去,你在让原型机正确运行上出现了麻烦。但由于你的秘密工作,向你擅长机械的朋友请教是不可能的了。

   后来的某天,你的邻居从他的车库中推出了一辆带有全新齿轮变速器的自行车。原来他前段时间也在做一个和你的创意非常相似的玩意儿,只不过他是在一群车行朋友的帮助下完成的。这点使你非常恼怒,你向他展示了你的工作。他指出了你设计上的几处简单的缺陷——那些问题本可以在第一周就能得到完善的,如果你当时可以展示给他的话。

enter image description here

与世隔绝的工作常常通向失望。

   相似的教训数不胜数。如果你坚持把好的创意隐藏起来并拒绝向任何人展示,直到完美实现为止,那么你是在进行一场豪赌。在早期很容易犯一些基础的设计错误。你冒着巨大的风险,并且失去了合作带来的好处:注意到你的邻居与他人合作工作带来的快速高效了吗?这就是为什么人们在下到深水前会先探入脚趾:你需要确认自己在做正确的事,按着正确的方式,并且以前从未做过。早期的失误几率是很高的。越早寻求帮助,越早降低风险。(注:我们应该了解,有时候在前期获得太多的帮助是危险的,我们会在后续章节中解释。)记住一句经过了实践检验的名言:“越挫越勇,永不言败!(Fail early,fail fast,fail often)”——我们将在本书的后面讨论失败的价值。

enter image description here

   早期的分享不仅代表了预防个人失误以及审视创意,同样重要的还有强化了项目中一种我们称之为“Bus factor”的因素。

Bus factor(名词):在项目完全确定之前需要核对的参与人数。

enter image description here

你团队的Bus factor是多少?

  你的项目为多少人所知?如果你是唯一一个理解原型代码运作的人,这可能对工作的保密性有好处,但也意味着一旦遇到困难,项目会被迫停止。如果你与你的一个朋友一起工作,那么的项目拥有双份Bus factor。如果你有一个小型团队一起设计制作产品原型,事情会变得更好——项目不会因为一个团队成员的离开而终止。牢记一点:团队成员不会每个人逐个被公交命中,但生活中其他不可预知的事情仍会发生。他们中的某一个也许结婚了;或者被迫离开团队,离开公司;或需要照顾生病的亲友。你需要设法管理团队Bus factor以促使项目的完成。

   在Bus factor的另一边,是项目每一步进展的问题。人们很容易忘记独立工作的艰辛及远低于公认水平的速度。从独立开发中你学到了多少?网络是获取建议和信息的极好的平台,但这不能代替人类的真实经验。与他人共事可以直接增加努力产生的的集体智慧。当你被某个荒谬的事困住时,浪费了多少时间使自己摆脱困境?设想有一些同事在身后第一时间告诉你你是呆瓜,以及如何能解决问题所带来的经历的不同之处。这真正是软件工程公司中团队协同开发(或结对编程)的原因所在:你会经常发现自己需要另一双眼睛。

   另一个类比。思考一下你是如何使用编译器的。当你坐下来写下一个很大的软件时,是否是花费数天或数周编写代码,在感到自己已完美完成工作后第一时间按下编译按钮的情形?当然不是了。你能想象到有多少不幸需要重建,尝试编译50,000行初始代码的景象吗?作为最好的程序员之一的我们反复贯彻着:写一个新的对象,编译;添加一组测试,编译;重写一些代码,编译。在产生新的代码后我们会尽快修复错误和漏洞。我们希望编译器可以每一时刻都在身边,就像僚机一样(空战中掩护队友的战机);希望一些环境可以如我们设计的那样稳定编译我们的代码。这正是我们保持代码优质及软件可以正确运行每一比特的方法。

   另外同样需要反复贯彻的几点不仅仅是使用在代码方面,而是贯通了整个项目。目标远大的项目都是进展迅速并且不得不接受项目所需的环境。项目陷入了不可预测的设计困境,或是党派纷争,或仅仅是简单地发现项目并没有按照计划执行。软件需求是变化的。你是如何得到反馈环节从而可以立刻得知你的设计或计划需要改变的?答案是:**团队**。Eric Steven Raymond经常引用一句话,“众人使漏洞无处藏身。”(Many eyes make all bugs shallow.1999年出版文集《大教堂和市集》首次描述)但更好的版本是:“众人使你的项目正常执行。”(Many eyes make sure your project stays relevant and on track.)井底之蛙,焉知世界之大。

工程师与办公室

   在20年前,传统观点规定:一个富有成效的工程师应该拥有属于自己的独立办公室。这可能是唯一的方法来保证她可以有大量连续不被打断的时间专注于编写大量代码了。

   我们认为,对于大多数工程师来说,一间独立办公室不仅是多余的,更是危险的。(我们当然承认严肃的内向型人格者应该会比大部分人需要更安静、独立的环境,并且得益于此。)今天,软件是由团队开发,而不是个人;并且团队工作的高效和队员间沟通的高效可比你的网络连接有价值多了(在一个关着门的独立房间,能与外界交流的,也就电话和网络了吧^_^)。你可以支配每一分有效时间,但如果将其用在了错误的事情上,就是在浪费生命。走进21世纪一家高速发展的高科技公司的办公室,你会看到成群的工程师聚集在一个用来分享的小房间(shared-cubicles,又称:"bullpens")或者圆桌区域(desk area)。你很少能看到他们把自己锁在办公室、疏远彼此的情形。

   当然了,你也需要一些方法过滤掉噪音和干扰。这也是为什么我们会看到很多团队都做出了规定,用以在团队忙碌的时候不会干扰到工作。我们曾使用过一条声音干扰协议:如果你想开口,你要说:“断点XX”(breakpoint Mary),XX就是你要说话的对象。如果XX在可以停下手头工作的点上,他会转动椅子听你说。如果XX太忙了,他只会说:“确认”(ack),这时你就该继续其他的事情直到XX完成手上的头等要事。

   其他的团队向工程师们发布了噪音消除听筒,使其可以更简单地干掉区域内的噪音。事实上,在许多公司穿戴上听筒是一个通用的讯号,这表示“除非是非常重要的事情,否则不要打扰我。”更有一些其他团队的成员使用一些动物作为其屏幕背景来传达“若非紧急,请勿打扰”的信号。

   请不要误解我们——我们仍然相信工程师需要大量不间断的时间专注于代码编写;但我们也相信他们需要一个团队成员间高效率,低摩擦的连接。

   这些点归结到一起就是:独立工作固有的比团队合作更具风险。当你害怕有人窃取你的创意或者认为你是呆瓜的时候,你更应该害怕浪费大量时间在错误的方向上挥汗如雨。

   悲剧的是,“看紧你的金库”(clutching ideas to the chest)的问题不仅仅面向软件工程一方面——这是一个贯穿整个领域的普遍问题。举一个例子:专业科学理应是免费、开放的信息交换。但是对“发表或灭亡”、对授权认可的争夺的极度渴望实际上起到了相反的效果。优秀的创意者不分享他们的创意。他们过分坚持,秘密研究,将所有的错误隐藏在自己的小路上。然后在最后公布一篇文章使整个过程听起来轻松且平淡无奇。然而结果往往是灾难性的:他们或是意外重蹈他人的覆辙;或是在早期犯下了一个未知的错误;亦或他们所做的是一个在以前曾闪亮一时,但现在被归为无用的事情。那些浪费的时间和努力,真是悲剧。

  不要成为另一个样本!

团队!团队!!团队!!!

   让我们将时间倒退,将所有想法放在一起。

   我们反复强调一个重点,独行侠是非常稀少的——即使在他们谋生时他们也不会完成超人般的业绩;他们改变世界的任务几乎总是团队努力的灵感的边角料。

   打造一个明星团队是真正的目标,但这会非常非常困难。最好的团队会最大化利用他们的高手,但整体总是优于部分的总和。换成一句简单的话说,就是:

   软件开发是团队活动。

   在最初,这也许是一种很难理解的观念,直到这种观念直接粉碎了我们心中天才程序员的幻想。试着想颂歌一样祷念它。

enter image description here

记住:软件开发是团队的运动。

    一个人宅在自己的黑客小窝中是不足以成为高手的。隐藏准备自己的秘密发明是不会改变世界或是让众多计算机使用者感到高兴的。你需要与他人合作,分享你的观点,划分工作,取人之长,补己之短,然后创建一个耀眼的团队。

   思考一下:有多少被广泛使用,由你命名的成功的软件是实际由一个人独立开发出来的?(很多人也许会说“LaTeX”,但这个软件很难称为“被广泛使用”,除非你将那写写学术论文的认定为所有计算机用户中在统计学上有重大意义的一部分。)

   我们很乐意在书中不厌其烦地重复这种“团队运动”的观念。高效的团队是目标,也是通向成功的关键。你应该尽最大可能将这些经验设为你的目标,这是本书的目的所在。

enter image description here enter image description here enter image description here