[翻译]Team Geek -02- Chapter 1 - The Myth of the Genius Programmer(完)

 英文版原版下载：http://download.csdn.net/detail/leon1418/6935271

 - 第一章  天才程序员的神话

因为这本书是讨论软件开发风险的，所以首先很有必要关注一个你绝对可以控制的因素：你自己。

人天生都不完美。但是在你发现同事的bug前应当先了解自己的bug。我们将要求你思考自己的行为、反应和态度，最终希望你可以对于如何成为一名高效并且成功的程序员有一些真正的理解。这会将你从处理人际关系的困扰中解脱出来，有更多的时间来写出漂亮的代码。

本章最重要的观点就是软件开发是一个团队运动。为了团队成功，你要明确自己的行为所需遵守的核心原则：谦虚、尊重和信任。在我们超越自己之前，我们先观察一下普通程序员的表现。

帮我把代码藏起来

在过去的六年里，我俩在程序开发大会上做了很多演讲。自从2006年我们在Google开源项目托管服务的初创团队起，我们就收到很多关于产品的问题和请求。回到2008年中期，我们在收到的诸多请求中发现了一种特别的倾向。

你们能为Google Codes上的Subversion提供隐藏特殊版本分支的功能吗？
你们能让开源项目在一开始不公开，直到项目准备好才对外公开吗？
嗨，我想把我乱写的代码都重写，能帮我清空历史记录吗？

你能在这些请求中发现一个共同的主题吗？

所有这些请求的动机都是不安。人们害怕其他人看到并评论自己尚未完成的工作。某种意义上说，这是人的天性-没人喜欢被批评，尤其是在还没有完成事情上。这种态度给我们提示了软件开发中的一种倾向。不安实际上已经成了一个大问题。

天才的神话

首先，我们要澄清一点：我们并不是体育迷。当我们的妻子为电视上的篮球和足球比赛欢呼的时候，我们都会挠头并想这有什么好激动的。然而，作为从90年代初期过来的人，我们见证了芝加哥公牛球的辉煌夺冠历程。这段时间我们都生活在芝加哥，媒体充斥着关于这只伟大球队的报道。

我们在电视和报纸上最常看到的是什么？不是这只球队，而是Michael Jordan，超级巨星。全世界所有的运动员都希望成为乔丹。我们看着他从其他球员身边掠过，看他出现在电视广告中，看他和一群卡通角色出演的愚蠢电影。他是个明星，每个在球场练习投篮的孩子都暗自希望沿着他的道路成长。

程序员也有同样的天性-寻找并崇拜自己的偶像。Linus
Torvalds, Richard Stallman, Bill Gates，所有这些有改变世界的英雄们。



当心崇拜偶像的天性

Linus自己写了Linux系统？实际上，Linus只是写了一个类UNIX内核的概念验证，并把它放到一个邮件列表中。这是一个不小的任务，并且成果令人钦佩，但是这仅仅是冰山的一角。现在Linux系统已经比当初由几百个聪明人开发的系统大了数百倍。Linus真正的成就是领导并协调这些人的工作。Linux系统是他们集体工作的辉煌结果（UNIX系统是由贝尔试验室的一群聪明人写的，并不只是Ken
Thompson和Dennis Richie）。

与此同时，Stallman自己写了所有自由软件基金会的软件？他是写了最初一代的Emacs，但还有成百的运行在Linux系统上该基金会的软件，像是bash、GCC工具等。Steve Jobs带领整个团队完成了Macintosh，Bill Gates因为写了早期家用电脑的BASIC解释器而闻名，但他最大的成就是围绕MS-DOS创建了一家成功的公司。他们都成为了领导者以及他们团队成就的象征。

那Michael Jordan呢？

这还是个同样的故事。我们崇拜他，但事实上他无法自己赢下所有的比赛。他真正天才的地方是他和他的团队工作的方式。团队的教练，Phil Jackson，非常聪明的人，他的教练生涯是个传奇，他意识到靠一个球员无法取得冠军，所以他围绕乔丹打造了一只梦之队。球队像是一台运转良好的机器，至少像乔丹一样都令人钦佩。

所以，为什么我们不断崇拜这些故事中的主人公？为什么人们因为支持偶像而购买产品？为什么想买Michelle Obama的衣服和Michael Jordan的鞋子？

名人效应是很大的一部分原因。人们的天性是以偶像为自己的榜样，崇拜他们并尝试模仿他们。我们都需要英雄来寻找灵感，程序员的世界也有自己的英雄。技术天才几乎已经成为了神话。我们都想写出改变世界的代码，就像Linux，或者设计出下一代杰出的编程语言。

心底里我们都希望自己成为天才。每个终极极客的梦想都是被一个绝妙的新想法打动，然后数周或者数月在自己的蝙蝠洞（Batman）中闭关，并完美的实现自己的想法。之后你将自己的软件发布到全世界，用你的天才震惊每一个人。你的同行们都吃惊于你的聪明才智。人们排队使用您的软件。声望和财富也接踵而来。

可是等等，让我们面对现实吧，你很可能不是个天才。

不要见怪，我们确定你一定是一个非常聪明的人。但你是否意识到真正的天才有多么少见吗？即使你是个天才，事实证明，这还是不够的。天才也会犯错误，即便有着绝妙的点子和高超的编程技巧，也不能保证你的软件无懈可击。真正成就或者毁掉你职业生涯的是你与人合作的方式。

事实证明，关于天才的神话只是我们不安感的另一种表现。大多数程序员害怕在一开始就公开他们的代码，因为这意味着同事们会看到他们犯的错误，并知道这些代码的作者不是个天才。引用另一个程序员Ben的博客：当人们看到我未完成的产品时我有严重的不安感，就好象他们会认真评判我并认为我是个白痴。

这在程序员中是一个非常普遍感觉，自然的反应是将自己藏起来然后工作、工作、工作。没有人会发现你的粗心大意，在你完成的时候仍旧有机会展示你的杰作。藏起来直到一切都完美。

另一个使你将底牌藏起来的常见动机是害怕其他程序员用了你的点子并且在你之前完成它。要保住这个点子就只有守住秘密。

我知道你现在或许在想，那又怎么样？还不许人按照自己的想法工作了？事实上，是不允许。在这种情况下，我们确定你做错了，这是个大问题。接下来是为什么错了。

逃避是无益的

如果一直独自工作，不但你失败的可能性会越来越大，而且还会埋没你的潜力。

首先，你如何确定自己在朝着正确的方向前进？

想象你是一个自行车爱好者，某一天你突然想到了一个全新的绝妙点子来设计齿轮变速器。你买齐了零件并在车库中连续工作数周，只为制造出一辆原型车。当有同样爱好的邻居问你时，你决定保守秘密。你不想在产品完美无缺前被任何人知道。又过了数月，你在制造原型车的过程中遇到了麻烦，但是由于你是秘密在工作，所以不可能从精通机械的朋友那获得帮助。突然有一天，你的邻居从车库中推出了一辆使用新型齿轮变速装置的自行车。他的设计非常类似你的想法，但是他找了在自行车店工作的朋友帮忙。这让你很生气，你给他看了正在做的原型车。他指出你的设计有些简单的错误，如果他早点看到就可以在一开始帮你指出来。



独自工作带来的往往是失望

这个故事可以教给我们很多。

如果你一直将自己的好点子藏起来，在完成前拒绝给别人展示，那这就是在用你的成功作赌注。在早期设计中我们很容易犯错误。这会让你承担重蹈别人覆辙的危险。同时，你也失去了合作将带来的好处，看看那些善于合作的人行动有多快。这就像为什么人们在跳入水中前都要用脚趾试试水一样，你需要确定自己在做的事情是正确的，并且是之前没有人做过。初期犯错的可能非常大，你获得意见越多，你犯错的风险越低。记住下面这条百事不爽的原则“犯错要趁早，要尽快，要多犯”，在本书的后面我们会讨论失败的重要性。

尽早分享不但会让自己少犯错误，还可以让你的点子更经的起推敲。同时，强化你的项目中所谓的“巴士因素”同样重要。

巴士因素（名词）：在你项目彻底失败前承受多少成员能被公车撞到（出意外）。



你团队的巴士因素是什么？

如何分散项目风险一门知识也是技术？如果你是团队中唯一个了解原型代码的人，你的工作会非常有保障，但是也意味着如果你被巴士撞到，这个项目就完蛋了。如果和一个朋友一起工作，这样，项目的巴士因素就翻倍了。如果你有一个团队一起进行原型设计，结果可能会更好，项目不会因为一个人的离开而终止。记住，团队成员不会一个个被巴士撞到，但是其他不可预知的事情仍旧会发生。有些人会结婚、搬走、离开公司或者去照顾患病的亲人。为了项目的成功，你需要增强项目的“巴士因素”。

除了“巴士因素”外，还有项目整体进度的问题。我们很容易忘记独自工作是多么的困难，比我们愿意承认的还要慢很多。独自工作中你能学到多少? 你的进度能有多快？网络是个想法和信息的大垃圾场，但是他不能替代我们实际经验。同他人一起努力工作将直接增加集体的智慧。当你困惑于某些事情时，你浪费了多少时间在把自己从牛角尖上拉回来？想想这个场景，几个同事与你并肩作战，当你犯错误的时候会立刻指出来，并指导你如何解决。这就是为什么在软件公司里项目团队都要坐在一起，你会发现需要通过另一双眼睛来帮助自己发现问题。

这里还有另一个形象的描述。想一想你是如何使用编译器工作的。当你花费几天或者数周的时间，写下大片的代码，认为一切都搞定了，这时才会第一次按下“编译”按钮吗? 你当然不会这样。你能想象一次编译50,000行新代码将是个多大的灾难吗？作为一个程序员，我们的工作最好是在一种紧凑的循环节奏中：写一个新方法、编译；增加一个测试用例、编译；重构一些代码、编译。我们会在敲出代码后尽快的修改其中的错别字和bug。我们希望编译器可以像僚机一样时时帮助我们，有些开发环境甚至可以在我们输入代码的时候就开始编译。这就是我们保证代码质量并确保我们的程序最终会正确的方式。

这种及时反馈的工作节奏不仅仅只在代码层次，而是要存在于整个项目层次。雄心勃勃的项目都发展迅速并且必须适应不断变化的环境。项目会遇到不可预知的设计问题、政治障碍或者发现事情并不像计划的那样。需求意外的变化了，你如何才能知道什么时候要修改计划或重新设计？答案就是在和团队一起工作。Eric
Raymond经常说说“众目睽睽下错误无处可藏”，可是更好的说法应该是“众目睽睽下项目才有保障”。当那些在洞中闭关人们完成了他们的最初版本时，这个世界已经变了，他们的产品已经过时了。

工程师和办公室

二十年前的传统观念认为，为了保证工程师工作效率，她们需要自己的独立办公室。据说这是长时间专注编写大量代码的唯一途径。

我们认为大部分工程师完全没有必要有独立的办公室，这太危险了。今天的软件开发是团队项目，并不是个人项目，和团队成员时时保持面对面沟通要比互联网更有价值。你可以拥有世界上所有连续的时间，但是如果你将它用来做错误的事情，你就是在浪费时间。在21世纪，当你走进任何一家高速增长的高科技公司，你会发现工程师们会在一个隔间中或是一张桌子旁一起工作，但是你很少会发现他们会在各自的办公室中工作。

当然，你仍然需要方法来避免噪音和被打断，这就是为什么我们看到的大部分团队都有各自的沟通方式，并且你也要控制自己被打断的次数。我们曾工作过的一个团队有个口头打断协议，如果你想和Mary说话时，你要先说“中断Mary”。如果Mary此时可以停下来，她会把椅子转过来并听你说。如果Mary很忙，她只会说一句“收到”，然后你就可以继续你的事情直到她完成手头的工作。

有些团队会给工程师提供防噪音耳机来解决环境噪音，实际上，在很多公司带耳机意味着告诉别人“不要打扰我除非事情真的很重要”。其他团队会用自己的符号或是毛绒玩具来表示除非事情很紧急否则他们不希望被打扰。

不要误解我们，我们仍然认为工程师需要不被打断的工作环境以专注于编写代码，但是我想我们更需要一种高效低耗的方式来保持团队交流。所以归根到底，独自工作要比团队协作有着天生的风险。

当你害怕自己的点子被别人偷走或者害怕他们认为你愚蠢的时候，你应该更害怕的是浪费大量时间和精力在错误的事情上。

不幸的是，这种将“将点子藏在心中”的错误并不是软件开发独有的，可以说是各个领域普遍的问题。例如，专业科学应该是鼓励自由和交流的，但是“没有论文就淘汰”的绝望和科研经费的竞争都只能起到反作用。伟大的思想家不分享观点，他们着迷于自己的理念，独自进行研究，隐藏一路上的错误，最终发表一篇论文让整个过程看起来毫不费力且一目了然。他们的结果经常是灾难性的，他们经常重复别人工作，早早就犯了一个没有发现的错误，或者在他们作品发布的时候就已经过时了。浪费时间和精力是个悲剧。

不要成为下一个统计数据。

一切的关键是团队

现在，让我们回头来将前面提到观点的整合起来。

我们的观点是，在软件开发领域，独自开发是很少见的，即使存在这种开发者，他们也不是超人，几乎所有改变世界的成就背后都闪耀着一个英雄团队。

组建一个明星团队才是我们真正要追求的目标，不过这极其困难。只有最优秀的团队能让其成员都变得杰出，但永远不要忘记1+1>2，团队的力量要大于所有人的总和。

让我们用一句话总结我们的观点：

软件开发是一项团队运动。

这个观点或许让人不好接受，它违背了我们心底想成为天才程序员的梦想。但先尝试把它当作一条灵验的咒语来看待吧。



记住软件开发是个团队运动

你还没有出色到可以独自取得成功。你的秘密创作无法改变世界，也无法取悦数百万的电脑用户。你需要和别人合作，分享观点，分工合作，取长补短，组建一支杰出的团队。

想一下这个问题：你能想到多少广泛使用并取得成功的软件是一个人完成的？（有些人会说“LaTeX”，但这个很难说是广泛在使用，除非你认为那些用它写论文的人可以代表所有电脑用户。）

我们会在本书中反复强调“团队运动”这个概念。强力的团队是我们目标，也是取得成功的关键。无论如何你都应该瞄准这一目标，这是本书的根本。

三根支柱

现在你已经清楚了我们所说的团队运动这个观点。如果团队合作是开发软件最好的方式，那我们要如何组建（或者加入）一支出色的团队呢？

这不是个简单的事情。为了达到合作的最高境界，你首先要了解并坚信我们这里所说的关于社交能力的三个支柱。这三个支柱不仅是推进人际关系，还是实现良性交互合作的基石。



谦虚

      你并不是宇宙的中心，你做不到无所不知从不犯错，你需要不断完善自己。



尊重

      你要关心一起工作的人，做到平等待人，尊重他们的能力和他们的工作。



信任

      你要相信同伴的能力，相信他们可以把事情做好，在适当的时候放手让他们去做。

总的来说，我们称这些原则为HRT。我们把HRT读作“heart”（心），而不是“hurt”（伤害），因为这些都为了抚平伤痛而不是伤害别人。事实上，我们的主要论点就直接建立在这些支柱上：



几乎所有的社交问题最终都可以定位在不够谦虚、缺少尊重和信任。

这或许听起来难以置信，但是不妨尝试一下。现在，想一想你自己生活中那些不快的、不舒服的社交场景。在这些场景中，每个人都表现的谦逊吗？每个人都真正尊重别人吗？所有人之间是否都相互信任吗？

我们相信这些原则是很重要的，本书也将围绕这些原则。

这本书将从你让相信这个三个原则，并将其作为与人交流的核心开始。这就是第一章所要讲的，从这个基点起，我们将不断扩大这三个原则影响力。

在第二章我们将讨论在这三个支柱基础上组建一个团队。创建团队文化是取得成功的前题，这就是前面所说的梦之队的关键。

接下来我们再看看那些每天都和你团队打交道的人，但这人可能并不是核心团队的一部分。有些可能是其他团队的合作者，或者仅仅是帮助你项目的志愿者。他们很多不仅无视HRT原则，而且彻底是个团队毒瘤。学习如何让你的团队免受他们的影响是第一要务，然而，用团队文化清除毒瘤，并让他们融入团队是我们的最终目标。这是扩大团队的一个很好方式。



坚信HRT是团队合作的最高境界

大部分团队都隶属于一个更大的公司，这种组织结构经常和团队毒瘤一样会障碍团队的发展。学习驾驭这些组织结构中的障碍，就是我们如何能推出一个产品并取消类似项目的关键。

最后，让我们想一想你软件的用户们。有些时候我们忘记了他们的存在，但是他们才是你项目的生命线。没有用户，你的软件将没有意义。你在团队中推行的HRT原则同样应该应用在和用户打交道上，这会让你获得很大的利益。

让我们暂停一下。

当你拿起这本书的时候，你可能不会想到自己每周都会处理一些这类的问题。我们对此表示同情。处理社交问题是很困难的。人都是复杂的、不可预期的，而且常常讨厌与人交流。即使花费大量精力在分析社交问题上，并且进行了策略上的改变，但是这些努力很仍然很容易打水漂。如果有个类似编译器的东西来帮我们处理这些社交问题一定是个更好的解决方案吧？为什么我们要为这些社交问题困扰呢？

这里引用一段Richard Hamming的著名演讲：

在你给秘书找麻烦前，如果讲讲笑话并表现的友好些，就可以得到秘书更好的帮助。比如有一次，因为一些愚蠢的原因，Murray Hill(莫雷山,位于新泽西)所有的复印服务都不能使用了。不要问我这是怎么发生的，它的确是发生了。我必须要完成一些工作。这时我的秘书找到了一个在霍姆德尔市(位于新泽西州)的家伙，用公司的汽车，花了近一小时的时间带他来并进行了修复，然后再将他送回去。这就是我平时对她很好，还经常讲笑话帮她振奋起来的回报。这点额外的工作，在之后给我带来了回报。当意识到你不得不使用一个系统，需要学习如何使用该系统来完成工作的时候，你要学会如何让系统来适应你的要求。

这段演讲的是要告诉我们不要低估了社交的力量。这并不是欺骗或者操作别人，而是创造一个良好的关系来将事情做好，并且良好的关系将会比项目本身还要长久。

NRT实践

所有这些关于谦虚、尊重、信任的说教，听起来像是一些让人云里雾里的大道理。让我们从这其中走出来，想一想在现实生活中要如何应用这些观点。为了寻找到一些实际中的情况，我们将检视一些你会遇到的具体的言谈举止和例子。其中很多起初听起来会很平常，但如果你仔细想一想，你会发现或许你犯了错误，并没有按照HRT的要求行事。

不要太自我

OK，这里有些简单的方式来告诫那些不够谦逊的人来放低姿态。没人愿意和自以为是的人一起工作。即使你知道你是最聪明的，也不要在别人面前指手画脚。想一想，你是不是觉得自己应该在每个讨论的话题上第一个发言，或者都要做总结发言？你是不是觉得有必要在讨论的每一个细节上都发表意见？或者，你知道有谁会像上面说的这样吗？

这里所说的谦逊并不是要做垫底的，保持自信是没有错误的。只是不要什么时候都像个百事通。更胜一筹的方式是用集体替代自我，与其担心自己是否真的了不起，不如尝试建立团队成就感。阿帕奇软件基金会在围绕软件项目组建社区上已经有很长的历史了，这些社区有令人难以置信地的特性，它们拒绝那些更在乎推销自己的人。

自我表现体现在很多方面，很多时候会它会妨碍你的工作效率并让你慢下来。这里有一个来自Hamming演讲中的提到故事可以很好的阐明这一观点：

John Tukey平时一直都穿着随便。他会走入某一间重要的办公室，可能很久其他人才发现进来了个一个大人物而且他们最好要听这个人的。长久以来，John不得不克服这种敌意。这是在浪费精力！我没有对他说“你应该是遵循规矩”，我只是说“这样会让你绕弯路的”，如果你在每一点上都选择以自我为主的话-“我要我用自己的方式来做”。你整个职业生涯都会持续为此付出一点点代价，但是到最后，你将会有大量的不必要的麻烦。当意识到你不得不使用一个系统，需要学习如何使用该系统来完成工作的时候，你要学会如何让系统来适应你的要求。或者你可以坚持反抗它，这就像是一场不大的战争，但会贯穿你的一生。

学习给予和面对批评

Joe获得了一份新的程序员工作。在第一周过后，他就开始钻研代码。因为他关心这些代码是如何工作的，慢慢的他开始质疑团队中其他人工作成绩。他通过电子邮件给同事发送自己的代码走查意见，礼貌的询问关于设计上的想法，并指出有些地方的逻辑可以进一步改进。几周后，他被叫到了主管的办公室，“出了什么问题吗？”主管问。
Joe问到“我做错什么了吗？”，主管看起来很担心，说到“Joe，我们收到了很多关于你表现的抱怨。显然，你对同事们太苛刻了，经常批评他们。这让他们很不安，你需要有所收敛“。这让Joe困惑不解。在基于HRT的企业文化下，Joe的代码走查行为应该是受欢迎的，他的同事们也应该为此表示感激。然而，在当前情况下，Joe应该更敏感的察觉到团队中的不安感，并用更微妙的方式在团队文化中引入代码评审的习惯。

在专业的软件开发环境中，批评几乎都不是针对个人的，通常批评是使产品更好的必要流程。关键是你要明白建设性批评和直接批评的区别。后者是没有用的，它几乎起不到任何作用。前者总是有用的，它可以帮助对方更上一层楼。批评的关键是要保持尊重，提供建设性意见的人要真正关心对方，真正希望可以帮助对方提高水准。学会尊重你的同事并委婉地给予建设性的批评。如果你真正尊重一个人，你就会主动的选择委婉、帮助性的措辞，这是一个需要反复练习的技巧。

另一个方面，你要学会接受这些批评。这意味着不仅仅要对自己的水平保存一个谦逊的态度，还要相信别人是真心的帮助自己，相信他们并不认为你是个傻瓜。像其他很多事情一样，编程是一门技术，它需要反复练习来提高。如果一个同事指出一种方式可以提高你的水平，你会认为这是对你个人价值的攻击吗？我们希望你不这么认为。同样的，你的自我价值不应该和你写的代码联系起来。反复告诉自己,
你不是自己写出的代码。不断告诉自己, 你不是自己写出的代码。你不但自己要相信这一点，还要让同事们也相信这一点。



不要把自己和代码划等号

举个例子来说，如果你预计自己的接下来的要做的事情可能会让同伴们不安，那你就不要直接说“你这个方法的流程完全错了。你应该像别人一样使用标准xyzzy代码模式”。当你告诉一个人他犯了个错误（其实也没有绝对正确的事情），批评他做的和别人都不一样（这会让他觉得自己是个傻瓜）的时候，你当然希望他能按你的要求进行修改。但是，事情可能并不会想你预期的这样发展，结果很可能是换来对方激烈的反应。

同样一件事情，更好的处理方式或许是这样的，“嗨，我对这里的流程不太明白，我想如果使用xyzzy代码模式可能会更清楚一点，将来维护起来也能更简单吧”。注意，这里是你在谦逊的问他，而不是他来问你。记住，他并没有错误，只是你对这段代码理解起来有困难。你的建议仅仅是希望可以让自己更好的明白这段代码，或许后面的维护也会更简单。同样的，你也不要要求他做任何事情，你要允许对方不采纳你的建议。你要把这个问题仅限制在这段代码中，不要牵涉任何个人能力的问题。

尽早出错-学习更正-如此循环

这里有一个在商业领域广为人知的故事，说的是一个经理由于犯了一个错误给公司造成了1000万美元的损失。第二天，他沮丧的来到办公室开始收拾桌子准备走人，正当他觉得这一切都不可避免的时候电话来了，CEO要见他。他来到CEO的办公室，然后主动递上了一张纸。
“这是什么？”CEO问到。

“我的辞职信，我想您是要解雇我了。”

“解雇你？”CEO疑惑的问到，“为什么要解雇你？我刚刚才在你身上花了1000万美元的学费。”

当然，这是一个极端的例子。但是，这个故事中的CEO明白，解雇这个经理也不会挽回这1000万美元的损失，并且在这次教训后，这个经理应该不会再犯同样的错误了，此时解雇他反而会是一个更大的损失。

我们在Google工作时，最喜欢的一条Google格言是“失败是一个可选项”。目前广泛认可的观点是，如果你从来没有失败过，说明你没有足够的创造力，或者没有勇气来进行冒险。我们应该把失败视作学习和提高黄金机会。事实上，爱迪生经常说“如果我发现10,000种方法都不行，我并不认为这是失败。我不会气馁，因为每一次失败的尝试都是向前迈进了一步”。

Google遵循的理念就是“不要将问题藏起来”。在系统将将可用的时候，就应该对公众发布一个原始的版本，Google实验室就是这样在做的。团队可以很快的发现哪里成功了，哪里失败了，然后就可以学习、改进并尽快推出一个新版本。当然，这个流程有时也给Google带来些尴尬，像Gmail这种持续了4年多beta版本的产品会被一些人嘲笑。但从积极的一面来看，这样做会使团队更加灵活、更快的适应变化，最终能用很短的时间推出令人惊讶的产品。所有这些所需要的都是谦逊的态度，可以接受给用户呈现软件中的缺陷，相信用户们会认可你的努力并期待看到你迅速进步。

从错误中学习的关键是对错误进行总结并归档。对错误的总结归档是必要的，但是要注意，不要写没用的道歉和辩解，这不是总结的目的。总结报告的目的是要说清楚这个错误让我们学到了什么，并且今后打算怎么做来避免类似的错误。将总结报告放在一个明显的地方，好让你可以时刻检查
自己是否按照其中所写的进行了改进。记住，一个优秀的总结报告也会帮助其他人避免发生同样的错误，让自己犯的错误成为被人的前车之鉴。

一个好的总结报告应该包括下述几点：

• 一个简短的摘要

• 问题的时间线，从错误发现到解决

• 产生问题的主要原因

• 问题造成影响和损失

• 解决问题所用到的方法

• 预防这类问题再发生的手段

• 汲取到的经验教训

留些时间学习

Cindy是她所在专业领域里真正的专家级程序员。他被提拔为技术主管，虽然责任更大了，但她勇敢的接受了这个挑战。不久，她就开始给周围的同事解答问题，并给他们指点门道。她在会议上发表讲话并很快能影响到很多团队。她完全爱上了专家这个角色。然而，她慢慢开始感到无聊。在某一时刻她停止了学习新的东西。但是，对于大部分有经验的专家来说，当聪明人的新鲜感都会逐渐消失。尽管所有一切都看起来很成功，但是有些东西消失了。有一天在工作中，她会发现自己选择的领域已经不那么重要了。人们的兴趣已经转向了其他领域。她哪里做错了吗？

让我们面对现实把，做最聪明的人的确是很有趣的一件事，指导别人也的确是非常有意义的。但问题是，一旦你在某一方面成为团队中最强的人，你可能会停止继续学习。一旦你停止学习，你就会觉得无聊。或者在不经意间逐渐的过时。人们真的很容易沉迷于当主力队员，但你会放弃一些自我意识来改变关注方向和学习新事物吗？这个例子也教育我们要保持谦逊和继续学习意愿。现在，你需要从安逸的现状中出来，找一个更大的平台，找到更强的人，接受更大的挑战。从长远来看，这会让你会更开心。

学习容忍

多年以来，Fitz都在写从CVS到Subversion的转换工具，由于RCS和CSV的特点，他经常的发现其中的各种离奇的bug。这时，他的老朋友，同时也非常熟悉CVS和RCS的Karl，他们决定一起修改这些bug。

当他们开始一起编程时，问题就出现了。Fitz是一个喜欢自下而上的工程师，出现问题的时候他会忽略一些细节，着眼于解决当前问题，通过不断尝试各种方式找到解决方案。然而，Karl是一个喜欢自上而下的工程师，在解决问题前他希望能详细了解和这个问题相关的每一个细节，在掌握所有信息的基础上找到解决办法。不同的风格导致两人合作过程中出现冲突、分歧和一些激烈的讨论。为了完成手头的工作，Fitz和Karl付出了很大努力和关注度，并且运用了不少HRT原则。最终，HRT不但拯救了他们的项目，还拯救了他们的友谊。

开放的接受建议

你越是开放的接受别人的建议，你的建议也就越能被别人接受。你越容易受到攻击，你就显得越强壮。这些话听起来很奇怪也很矛盾。可是大家都想一想那些我们周围那些固执的人。不论多少人来劝他们，他们总是固执己见。这些团队成员最终会怎么样呢？以我们的经验来看，他们最终会像个“障碍物”一样，每个人都会避开他们。人们不再听他们的建议和反对意见。你当然不希望自己变成这样，所以在心底记住这一点：让别人改变你的想法没有关系。谨慎的选择是否要“开战”。记住，为了要让别人听你的，你要先听别人的。并且，你应该在夯实基础前聆听别人的建议，之后要坚定自己要做什么，
如果你经常改变自己的想法，人们会认为你是拿不定主意的人。

这个弱点这个问题上，起初看起来同样有些奇怪。如果有人承认她对手头的事情一无所知，或者不知道如何解决问题，那她在团队中又要如何获得别人的信任呢？弱点是弱者的表现，它会摧毁人的自信，是这样吗？

不是这样的。承认自己犯错误，承认自己有些掉队，这在长远来看是帮助自己提高的一种方式。事实上，这包含了所有HRT的要素，它需要我们表现出谦逊的态度，需要我们了解关于职责和承担的意义，同时也表明你信任别人的意见，而作为回报，人们将会尊重你的诚实和能力。所以有时候，你最应该做的事情就是说出“我不知道”。



诚实和谦逊不是超人的氪星石

想一下那些职业政客们，他们从不承认自己的错误和无知，即使是在明显的犯了错或者对某些事情一无所知的时候也不会承认。就是因为这个原因，大部分人并不相信政客们说的话。这种现象的出现，是因为这些政客们会不断被自己的对手们攻击。然而，当你写代码的时候，完全没有必要提防这些攻击，因为你的队友是你的合作者，而不是竞争者。

下一步

如果你能做到这一步，你就很好的掌握了与人相处的技巧。首先，你必须检视和反思自己的行为。一旦你把这些策略应用到日常生活中，你会发现合作将变得更加自然，你的工作效率也将会明显的增加。

这个重要的改变要从你自己开始，然后逐渐影响到别人。在下一章，我们将讨论如何在团队中营造基于HRT的团队文化。