作者：(美)Brian W.Fitzpatrick Ben Collins-Sussman
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
极客与团队试读：
前言
“工程问题都很简单。人际关系才是最难的。”——比尔·库格伦，前Google工程部资深副总裁生活中总是充满了离奇的转折，就好像我们俩从没想过会合作写一本软件工程的书一样。
和大多数电脑狂一样，大学毕业后我们发现自己的兴趣和热情（折腾电脑）居然也是不错的谋生手段。而和那个时代的大多数黑客一样，我们的整个20世纪90年代中期都是在干这些事情，用别人剩下的零件攒机，拿着一大叠软盘安装预览版的Linux，然后学着操纵UNIX机器。我们都是系统管理员出身，然后在互联网泡沫刚起来的时候跑到小公司里去当程序员。泡沫破裂后，我们开始为那些幸存的硅谷企业（比如Apple）工作，后来又跳槽去了一家创业公司（CollabNet），全心设计开发了一款开源版本控制软件Subversion。
然而2000年到2005年期间，一些意想不到的事情发生了。尽管我们创造了Subversion，但是我们每天的任务却渐渐发生了变化。我们不再只是天天坐在那里写代码，而是开始领导一个开源项目了。这意味着我们要整天挂在聊天室和一堆程序员志愿者打交道，关注他们都在做些什么。这还意味着要几乎完全通过邮件列表来协调各种新特性。我们逐渐发现一个项目成功的关键不仅仅是写出漂亮的代码：所有人向着同一个目标一起合作也是同样重要的。
2005年的时候我们一起创建了Google芝加哥分部，以程序员的身份继续着我们的职业生涯。这时我们已经完全融入开源世界了——不仅仅是Subversion，还有Apache软件基金会（ASF）。我们把Subversion移植到Google的BigTable架构上，并以Google Code为名发布了一项开源项目托管的服务（类似于SourceForge）。我们开始参加（后来开始做演讲）各种开发者大会，例如OSCON、ApacheCon、PyCon，还有Google I/O。我们发现同时为企业和开源项目工作的经历让我们无意之间了解到了软件工程团队运作的奥秘。一开始我们做的演讲都是轻松幽默的，大多是批判无用的开发流程（“Subversion最差实践”），后来则开始转向探讨如何保护团队不受害群之马的影响（“开源项目如何应付害群之马”）。越来越多的听众聚集到我们的演讲会场，我们称之为程序员的“集体疗法”。每个人都对我们谈论的问题有着切肤之痛，都想要对大家抱怨一下。
于是，六年来我们做了一大堆反响热烈的和软件开发过程中人际关系有关的演讲。最后奥莱利公司的编辑玛丽·特莱斯勒建议我们干脆把这些演讲写成一本新书。接下来发生的事情就略过不表了。想要编写出色的软件？这本书就是为你写的本书的读者
本书是专门写给那些想要更上一层楼以及编写出色软件的程序员看的。CEO、心理学家、管理层\计算机理论学家，还有焊电路板的技师等都不算是我们的目标读者（虽然这些朋友或许也能读得津津有味）。在此我们假设本书的读者具备以下两个重要条件。
•你需要和团队里的其他程序员合作。无论是为公司企业工作，或是某个开源项目或是学校作业的一员都可以。
•你喜欢软件工程，并且觉得它应该是一件很有成就感、很好玩的事情。如果你只是应付工作混口饭吃的话，那估计你对实现自我价值和获得职业满足感不会有什么兴趣。
在讨论程序员怎么才能“通力合作”的时候，我们总结出了一些表面上看起来和程序员这份工作风马牛不相及的经验和准则。我们会在各章里谈到怎么才能更好地领导一支团队和企业，怎么才能和用户建立起良性的关系等话题。乍看起来这些章好像是专门写给所谓的“管人的人”或者说“产品经理”看的，但我们可以保证，你的职业生涯到了某个阶段的时候一定会有意无意地担当起这样的角色。所以先放下疑虑，继续往下读吧！这本书里讲到的东西是每个软件工程师最终都会碰到的。警告：本书不是技术手册
首先我们需要澄清一些事情。好学的程序员通常都喜欢去读一些能将某些个特定问题用纯数学的形式展现出来的书籍，而通常这样的问题都存在完美的流程化的答案。
本书并不属于这种类型。
本书主要关注的是软件开发中有关人的那个方面，而人是很复杂的。正如在我们自己的演讲中说到的那样，“人基本上就是由一大堆间歇性bug组成的”。这里论及的问题和答案都是很凌乱的，很难用完美逻辑来解释。本书读起来像是论文集，而事实上它的确也就是一本论文集。每一章我们都会讨论一系列相关的问题（通常是用案例故事的方式），然后针对整个主题再探讨各种应对方案。你可能需要反复阅读很多页，努力把它们联系起来，甚至思考数日才能融会贯通！
我们在此还要作一些声明。正如我们在演讲里开过的玩笑，“这里的观点完全是基于我们自己的经验得出的，完全属于我们自己。要是你不同意我们的观点，完全可以去自己做演讲啊”。和我们的现场演讲一样，只要和本书主题相关，任何讨论都是值得鼓励的。我们欢迎各种反馈、修正、新观点，以及反驳：你可以在http://www.benandfitz.com/上找到我们。本书的所有内容都来自我们的亲身经历和无数错误中得到的教训。
你还应该注意，我们在例子中提到的都是化名，以保护无辜（或者犯错）的当事人。本书的内容都是课本里学不到的
我们认识的软件工程师绝大多数都花了4～10年的时间在学校里学习计算机科学和软件工程。截至本书出版为止，我们不知道有任何一门课程是真正教你怎么在团队和公司里与人合作交流的。好吧，大多数学生都会在学校里被要求参与某个项目，但是教一个人怎么好好地和另一个人协作与把他直接丢到一个迫使他协作的环境里完全是两码事。绝大多数学生最后都不怎么喜欢这种经验。小结
所谓成功的程序员不仅仅是追逐最新的语言或是编写最快的代码。职业程序员几乎都是要参与团队合作的，而且事实上团队直接影响个人生产力和幸福感的程度超出很多人的想象。
本书的目标很简单：编写软件是集体项目，而且我们认为人的因素对结果的影响不亚于技术因素。大多数人虽然在编程技术上耕耘数载，但是在人际关系上却从来没有下过功夫，而学习与人合作也是成功路上不可或缺的重要环节。只要你能在软件工程的“软技能”上下点功夫，就能达到事半功倍的效果。第一章第天才程序员的传说章
既然本书讨论的是软件开发里危险的人际关系，那么把注意力放在有绝对控制权的因素上是显而易见的选择，这个不定因素就是：你自己。
没有人是完美的，但是在给同事挑错之前，你得先知道自己的毛病。我们希望你想想自己的反应、行为和态度——或许你可以从中得到一些心得体会，从而变成一名更成功、更高效的软件工程师。在处理人际关系的问题上花的精力越少，你就有越多的时间编写漂亮的代码。
本章的主旨是要理解软件开发是集体项目（这一实际）。要在团队里获得成功，你必须以谦虚、尊重和信任为核心原则。
不过在此之前，我们先来观察一下程序员的日常行为吧。帮我把代码藏起来
过去6年来我们俩一直在各种编程大会上做演讲。由于我们是2006年发布Google开源项目托管服务的小组成员，所以我们收到了很多关于这个产品的问题和请求。到了2008年中的时候，我们注意到这些请求里出现了很明显的趋势。
•能让Google Code上的Subversion隐藏某个分支么？
•能不能实现这样的功能：先把新建项目隐藏起来，等到准备妥当的时候再公开发布？
•我想推倒重来，能不能删掉整个历史记录呢？
你能看出这些请求之间的共同之处么？
这里的要害就是缺乏安全感。人们不喜欢自己做到一半的事情被别人指手画脚。从某种意义上来讲，这是人的本性——没人喜欢被批评，特别是还没完成的工作。这种态度透露出软件开发的某种趋势。缺乏安全感其实意味着背后可能隐藏着更严重的问题。天才的传说
首先我们要澄清一件事情：我们实际上不是体育迷。每次我们的太太们在电视机前为了篮球或者足球比赛欢呼雀跃的时候，我们总会挠挠头皮觉得这有什么好激动的。但不管怎么说，我们毕竟是见证了20世纪90年代初芝加哥公牛队的辉煌（顺便说一句，这是一支篮球队）。我们当时都住在芝加哥，全国媒体在这里聚集了好多年，来报道这支传奇球队。
那么我们在电视和报纸里听到最多的是什么？不是球队本身，而是迈克尔·乔丹，球队的超级巨星。全世界的球员都想成为乔丹那样的明星。我们可以看到他在其他球员周围跳舞转圈圈，在电视广告里也能看到他。他演了一部很傻的电影，在其中他和一群卡通人物一起打球。他是大明星，每个小孩子都会在球场里偷偷练习打篮球，希望将来有一天也能像他一样。
程序员其实也一样，我们也会有自己崇拜的偶像。莱纳斯·托瓦兹、理查德·斯托曼、比尔·盖茨——这些改变了世界的英雄都作出了了不起的贡献。毕竟莱纳斯靠自己就写出了Linux不是吗？要小心自己本能地去崇拜事物
其实莱纳斯只是写了一个可以工作的类UNIX内核的初级版本，然后把它贴到了邮件列表上而已。这并不是一项简单的任务，而且它也的确是一项了不起的成就，但是这真的只是冰山一角而已。Linux的规模是这个的几百倍，有几百名聪明绝顶的程序员参与了开发。莱纳斯真正的成就是领导并协调他们的工作，Linux之所以如此耀眼完全是这些人通力合作的结果（另外，UNIX也是由贝尔实验室里的一小群天才写出来的，并不完全是肯·汤姆森和丹尼斯·里奇的功劳。）
同样的，自由软件基金会的软件都是由斯托曼编写的吗？他编写了第一版Emacs，而bash、GCC，以及所有其他运行在Linux上的软件都是由几百名程序员负责的。史提夫·乔布斯领导的团队开发了麦金塔电脑，还有比尔·盖茨，尽管他为早期的家用电脑编写了BASIC解释器，但其实他更大的贡献是围绕MS-DOS创办了一家成功的软件公司。可是这些集体荣誉都被算在了他们这些领袖的头上。
那么迈克尔·乔丹呢？
我们还是一样崇拜他，但事实上他是不可能靠自己一个人就赢得每一场篮球赛的，他真正天才的地方是他和球队一起打球的方式。球队教练菲尔·杰克逊是非常聪明的一个人——他的教练水平是毋庸置疑的：他知道单靠一名球员是无法赢得冠军的，所以他围绕乔丹打造了一支“梦之队”。这支队伍干劲十足，耀眼程度完全不亚于乔丹。
既然如此，我们为什么还是不断地去崇拜这些故事里的主角呢？人们为什么为明星代言的产品掏钱？为什么我们会想要去买米歇尔·奥巴马的裙子和迈克尔·乔丹的球鞋？
明星的号召力是很大的。人类会本能地去寻找领导者和榜样，崇拜他们，然后模仿。我们都需要榜样的激励，编程世界也不例外，“技术英雄”的现象几乎都要被神化了。我们都想要写出像Linux那样改变世界的东西，或是设计一门了不起的程序语言。
从内心深处来讲我们都默默地希望自己是天才。极客的终极梦想就是得到一个激动人心的灵感，然后闭关数周甚至数月将它完美地实现出来，最后向全世界发布自己的作品，名动天下。同行们会折服于你的聪明才智，人们会排着队来买你的软件，名望和财富更是唾手可得。
不好意思先等一下：醒醒吧，你很可能不是什么天才。
当然我们并无恶意，你肯定是一个很聪明的人，但是你知道这个世界有多少真正的天才吗？的确，你能写代码，拥有这种能力已经算是人群里的聪明人了，但问题在于即便你真的是天才也是不够的。天才也会犯错，好点子和高超的技术并不是软件成功的充分条件，你的职业生涯能否成功完全要看你能不能与人合作。
事实上所谓的天才传说只是我们缺乏安全感的一种表象罢了。很多程序员都害怕和别人分享他刚刚开始做的东西，因为这意味着同行会看到他们的错误，从而知道这些代码背后的作者并非天才。这里引用本的博客上某位程序员的留言：“如果别人看到我未完成的作品，我会非常忐忑，觉得他们会因此对我产生质疑，把我当成一个傻瓜。”
这是程序员这个人群里很普遍的看法，所以最自然的反应就是躲起来不断地努力工作。只要没人看到你犯错，你就还有机会最终一鸣惊人。所以产品完善之前还是先藏拙吧。
不愿献丑的另一个原因是害怕别的程序员会偷走你的创意，然后抢先发布。所以只要保持低调，创意就不会被偷走了。
我们知道你现在可能会想：那又怎么样？难道我们不能按照自己的方式工作吗？
事实上还真的不能。我们可以断定你这样做是不对的，而且错得离谱。让我们来告诉你为什么。隐瞒是有害的
假如你一直都是单打独斗的话，你其实是增加了自己失败的风险，而且浪费了自己成长的可能性。
首先，你怎么知道自己选的路是对的？
假设你是一名狂热的自行车设计师，有一天你想到了一个绝妙的主意，设计出一个具有颠覆性的换挡装置。你订购了零件，然后在车库里泡了好几个星期来制作原型。当你的邻居（他也是自行车爱好者）问你最近在忙什么的时候，你想还是先保密好了。在这个设计完善之前，你不想任何人知道它的存在。几个月以后，你遇到了瓶颈，没有办法令原型正常工作，但由于这个项目是保密的，所以也没办法向你的机械师朋友们寻求帮助。
直到有一天，你的邻居从他的车库里推出一辆自行车，上面有一个全新设计的换挡装置。其实他也一直在建造一个和你的设计类似的东西，只不过他有自行车行的朋友帮他的忙。这时你一定非常窝火吧。你把自己的东西拿给他看，他立刻就指出了你在设计上存在的缺陷——要是你早点拿出来的话，搞不好这些缺陷在一开始就修复了。单打独斗的结果往往令人失望
这里我们可以得到好几个教训。真正做出产品之前不愿分享好创意实际上是一场很大的赌博，你很容易在一开始就犯下很基本的错误，你有可能是在重新发明轮子。还有你完全丧失了合作的好处。注意到你的邻居和别人合作后进展有多快了吗？这正是为什么人们在跳进泳池前会拿脚趾试试水的原因：你需要确定自己在做的事情是对的，方法也是对的，而且不是重复劳动。一开始就踏错步的概率总是很高的，越早征求意见和反馈，就越能把风险降低。记住这句久经考验的原则——“确保失败尽早发生，尽快发生，经常发生”——我们会在本书稍后详细讨论失败的重要性。
尽早分享不仅仅可以防止一开始就步入歧途和检验创意，它还可以强化所谓的“公车因子”。
公车因子（名词）：一个项目里，需要有多少人被公车撞到才能令其完全瘫痪。你的团队的公车因子是多少
你的项目里知识的分散程度是多少？假如只有你一个人理解原型代码是怎么工作的，那么或许对你的职位的安全程度来说是很高，但要是你被车撞了的话，对项目本身来说就是灭顶之灾了。但如果有一个朋友和你合作的话，公车因子就可以翻倍。要是有一个小组一起设计制作原型的话就更好了——项目不会因为某位成员的消失而完蛋。记住：这里只是比喻，并非真的是被车撞，而是指任何生活中都会发生的意外情况，比如结婚、搬家、离职或是照顾生病的家人等。你若想要确保项目有一个光明的前景，就一定要把公车因子纳入考量。
除了公车因子之外，还有整体进展的速度。人们往往会忘记单独工作通常都是很艰辛的，进展有时会慢得令人难以接受。独自工作能让你学到多少东西？你的进展如何？网络虽然是观点和信息的大熔炉，但是它是替代不了人与人之间真正的交流的。直接和别人一起工作能潜移默化地提升集体智慧。每次遇到事后觉得可笑的障碍时，你浪费了多少时间才走出死胡同？想想如果有同事在旁边帮你一把的话会有什么不同——他们会立刻指出你哪里弄错了，该怎么解决它。这就是软件公司里团队通常都是坐在一起（或是在一起结对编程）的原因：你需要一位旁观者。
再打一个比方。想想你是怎么用编译器的。当你编译一个有一定规模的软件的时候，你会花好几天甚至好几个星期坐在那里写代码，然后在全部写完确保一切完美后才第一次进行编译么？肯定不会啦。你能想象一口气编译50 000行代码会有什么后果么？程序员是最需要不断反馈的：写一个新函数，编译，加了一个测试用例，再编译一下，又重构了一部分代码，再编译一下。这样就能在生成代码的时候尽快地改正笔误和bug。我们的每一步都离不开编译器，好像僚机一样。有些开发环境甚至能在我们打字的同时进行编译。正是依靠这种方式我们才能保持高质量的代码并确保软件在正确的轨道上演化。
这种快速反馈不仅在代码层面，对整个项目来说也是必不可少的。有抱负的项目都必须快速演化并不断适应环境的变化。项目可能会遇到意料之外的设计瓶颈，或者行政上的阻力，又或者只是发现事与愿违。需求总是在往意想不到的方向变化。你要如何通过反馈来发现自己的计划和设计中需要修改的地方？答案是：团队合作。埃里克·雷蒙说过，“只要有足够多双眼睛，就能发现所有的bug，”而更好的说法是，“足够多双眼睛可以确保你的项目保持正确的方向。”闭门造车的结果往往是当实现最初的创意后，却发现世界已经完全改变，原本的产品已经失去意义了。
工程师和办公室
20年前的传统看法是工程师需要自己独立的办公室，关上门安静工作才会有生产力。这样才能保证他有大把不受干扰的时间可以专心编程。
而我们却认为把绝大多数工程师关在独立办公室里不但毫无必要而且还很危险。今时今日，软件业已经不是个人英雄的行业了，它需要团队的合作，保持沟通渠道的通畅甚至比随时在线的网络连接更重要。虽然得到了不受干扰的环境，但如果方向错了，那也只是在浪费时间罢了。走进任何一家21世纪以来创建的、快速成长的高科技公司，你会发现工程师都是围坐在共享的小格间（也叫“牛棚”）里，或是共用一张桌子，很少见到各自把自己锁在办公室里的情况。
当然啦，你还是需要找到办法来过滤杂音和干扰的，我们发现很多团队因此发展出一套自己的沟通技巧来表达自己现在很忙，有事等会再说。以前和我们合作过的一支团队就有这样一套语音中断协议：假如你有事找玛丽谈，你要说，“breakpoint玛丽”。如果玛丽正好有空档可以停下来，她就会转过来和你谈。要是她正在忙，她会说“ack”表示知道了，然后你就先去忙其他事情吧，她那边忙完了就会来找你。
有些团队会给工程师发降噪耳机来解决背景噪音的问题——事实上在很多公司里，带着耳机实际上就表示“不是重要的事情就别烦我”。另外一些团队则会用在显示器上放置记号和玩具的办法来表示自己不愿被打扰。
请别误解我们——我们完全认同工程师应该有不受干扰的时间来全情投入编码之中，但是我们认为他们更需要团队之间高效通畅的沟通渠道。
因此用一句话来总结就是：本质上，单打独斗比合作风险更高。相比担心自己的创意被偷走或是被人笑话，你更应该担心自己是不是在错误的方向上浪费了大量时间。
令人遗憾的是，这种“创意要保密”的想法并非软件行业独有的，所有领域都普遍存在这个问题。就拿学术界来说，科学原本应该是自由开放、信息共享的。但是“不发表即灭亡”的迫切需求，以及对基金拨款的竞争却造成了反效果。学者们不再乐于分享。他们小心翼翼地保护着自己的想法，秘密地进行研究，把犯过的错误都掩盖起来，使最终发表的论文看起来似乎得来全不费功夫一般。其结果往往都是灾难性的：要么不小心重复了前人的工作，要么在一开始就不知不觉犯下了错误，最糟糕的是创造了一些原本有趣，但现在完全过时无用的东西。其中浪费的时间和精力都是无法估量的。
别再把自己变成上述统计结果的一部分。团队才是王道
现在我们来小结一下。
我们到目前为止一直在打磨的观点就是，在编程领域里，真正的独行侠是很罕见的——就算他们真的存在，他们的非凡成就也不是凭空而来的。这些改变世界的成就几乎都是集体智慧努力得来的结晶。
因此建立一支全明星团队才是真正的目标，不过想达成这个目标，难度高得惊人。最好的团队能充分利用好队里的巨星是没错，但是集体的力量一定是大于个体力量之和的。
用一句话来说就是：软件开发是集体项目。
乍看之下这个理念很难让人接受，毕竟这和我们心里的天才程序员幻想是相抵触的，所以先记下来再慢慢理解吧。记住，软件开发是集体项目
一个人躲在自己小黑屋里抖聪明是没用的。光靠自己神神秘秘地搞创造发明是不可能改变世界，令千百万用户受益的。你需要合作，告诉别人你的想法，让别人帮你分担劳力，向别人学习，进而打造一支出色的团队。
现在来做个实验：你能想出几个应用广泛的成功软件是真正由一个人完成的？（有些人可能会提到“LaTeX”，但很难说它是一款“应用广泛”的软件，除非你觉得那些写学术论文的人在所有电脑用户里占有相当大的比例！）
我们会在这本书里不断地重复这个集体项目的概念。高效的团队才是通向成功的关键所在，你应该尽可能地以此为目标，这同样也是本书的使命。三支柱
到这里我们对于团队的观点已经立论了。既然团队合作才是开发成功软件的捷径，那么如何才能打造出（或者找到）这样优秀的队伍呢？
答案是很难。要达到合作无间的境界，你首先要学习理解所谓的社交技巧“三支柱”。这三项原则不但是人际关系中的润滑剂，更是所有良性互动与合作的基本。谦虚
没有人是宇宙中心。谁也不是万能的，谁都会犯错。你必须不断地提高自己。尊重
你必须真心实意地关心同事。他们都是活生生的人，他们的能力和成绩都需要得到肯定。信任
要相信别人的能力和判断力，在适当的时候懂得放权。
我们把这些原则简称为HRT。发音是“heart”而不是“hurt”，因为它是要减轻痛苦而是不是伤害别人。事实上我们的论文就是直接基于这些原则的：
基本上所有的社交摩擦最终都是由于缺乏谦虚、尊重，或是信任而造成的。
乍听之下似乎有点难以置信，但请姑且相信我们。你不妨仔细回想一下生活中遇到过的各种令人难受的社交场景。先不说别的，当时大家是不是都有保持有礼有节？是不是真的有尊重对方？是不是有相互信任？
我们相信这些原则至关重要，本书正是围绕它们而展开的。
本书是以你为起点的：让你了解HRT，并真正理解消化以HRT为交际核心的意义。这就是第一章的内容。然后我们能不断地扩大影响的范围。
第二章讨论的是在三支柱之上打造团队的挑战。建立团队文化是走向成功的必由之路——这就是之前说到的“梦之队”。
然后我们会讨论那些每天会和团队打交道，但是却不属于核心团队文化的人。他们可以是其他团队的同事，或是项目的志愿者。他们中的很大一部分人不但完全无视H RT ，更有甚者，完全就是老鼠屎！学习如何抵御这种人对团队的伤害是你的首要任务。不过你的终极目标应该是拔掉他们的爪牙，让他们融入到你的团队文化中来。这是扩充队伍的最佳方式之一。拥抱HRT才能合作无间
大多数团队都隶属于更大的公司，这种环境常常和害群之马具有同等危害。你的产品能否顺利发布亦或是最终面临被取消的命运，完全取决于你能不能学会如何避开各种行政障碍。
最后，你的用户也是需要考虑的。我们往往会忘记他们的存在，但就是他们决定了产品的寿命。没人用的软件是没有存在价值的。对团队至关重要的HRT原则同样（也应该）适用于你对用户的态度，你能从中获得的好处是不可言喻的。
说到这儿，让我们先暂停一下。
当你翻开这本书的时候，你大概从没想过要参加什么每周互助小组吧？对此我们表示同情。社交的确是个棘手的难题。人类是混乱复杂的生物，完全无法预料，有些人会让人觉得不愿与之打交道。与其耗费那么多精力去分析各种社交场景，步步为营，还不如干脆完全放弃努力。行为完全可以预判的编译器岂不是容易对付得多？干嘛要跟那些社交的麻烦较劲呢？
这里引用一段理查德·海明的著名演讲：
我花了很多时间给我的秘书们讲笑话，和他们搞好关系，这也让我从他们那里得到了许多好处。比如有一次，不知道什么缘故，梅山所有的复印机都坏掉了。别问我为什么，反正就是坏掉了。而我正好要复印一些文件。于是我的秘书给霍姆德尔的朋友打了个电话，跳上公司的车，开了一整个小时去帮我复印，然后再开车回来。这就是我花了那么多功夫讲笑话逗她开心，表示友善得来的回报。真可谓投之桃李，报之琼瑶。也就是说，通过使用系统并研究如何让系统帮你做事，你就学会了调整系统，让它按照你的意愿工作。
这个故事告诉我们：不要低估社交的力量。社交不是勾心斗角，或是操纵别人，它是通过建立起人与人之间的关系来把事情做成功，而且这种关系延续的时间肯定比项目本身更长。HRT实战
说了那么多谦虚、尊敬、信任的东西，听起来都像是纸上谈兵。既然这样，我们现在来看看它们和现实是怎么联系起来的。既然我们追求的是实际可操作的建议，所以下面会给出一系列特定的场景实例。其中很多看起来似乎都是显而易见的，可一旦开始仔细思考，你就会发现自己（和同僚们）犯错的频率有多高了。放下自负
好吧，说得更直白一点，就是让某些缺乏谦逊的人收敛一点儿。没人喜欢和总是以自我为中心的人合作。哪怕你真的是会议室里最聪明的那个，你也没必要到处炫耀。例如，你是不是总是觉得自己对于每个话题都要抢先发表意见，或是要作总结性发言？你是不是觉得自己需要在一项议案或是讨论中对每个细节发表评论？或是你总是要知道谁在干什么？
注意，“表现得谦逊一点”和人见人踩的懦弱完全不是一回事：自信并没有错。只是不要过了头，非要弄得自己好像无所不知一样。其实更好的思路是想办法促成“集体”荣誉感。不要去担心你的个人形象是不是高大，而应努力去营造一种团队和集体荣誉感。Apache软件基金会在围绕软件项目经营社区上已经有很长的历史了。这些社区对自己都有很强的认同感，根本不欢迎对那些只关心自己往上爬的人。
自负这个东西有很多种解释，就看你怎么理解，但很多时候它都会妨碍你的工作，让你进步缓慢。这里从海明的演讲里再摘取一段小故事来证明我们的观点：“约翰·图基几乎总是不修边幅的模样。每次他参加重要会议的时候，对方总是要好一会儿才反应过来原来这是位大人物，应该认真听他说。有好长一段时间约翰都要面对这种麻烦。这实在是太浪费时间了！我不是说你应该屈服，我说的是，‘作出妥协的样子能给你带来很多好处’。如果非要由着自己的性子来，‘我就是我行我素的人’，那么你就在整个职业生涯里不断地付出一些不大但是很讨厌的代价。日积月累就会变成原本没必要的大麻烦。……通过使用系统并研究如何让系统帮你做事，你就学会了调整系统，让它按照你的意愿工作。不然的话，你就得终其一生去和这种潜规则作斗争。”学会批评和接受批评
乔是一名程序员，他最近找到了一份新工作。在上了一星期的班以后，他开始深入地学习了解团队的代码。出于责任心，他开始以温和的方式对同事的代码提出疑问。他通过E-mail的方式发出代码审查，礼貌地询问设计初衷或是指出逻辑上可以改进的地方。两个星期后他被叫到了主管办公室。“出什么事了？”乔问道，“我是不是什么地方做错了？”主管看起来不太高兴：“乔，最近有很多人投诉你，说你对同事太苛刻了，把他们说得左也不是右也不是。大家都很不爽，你最好低调一点。”乔因此大受打击。若是在一个完全以H RT为基础的环境里，乔的代码审查应该是可以被接受的，同事们也会认同这种做法。但是在这个例子里，乔就应该对团队里弥漫的不安全感多加小心，在引入代码审查的时候应该更谨慎一点。
在职业程序员这个行当里，人身攻击是相当罕见的——批评通常都是为了产品好。其中的诀窍就是要确保你（和你周围的人）认识到对某人的创造性工作提出建设性批评和人身攻击之间的区别。后者是毫无意义的——这种攻击不但显得小气，而且几乎不可能有什么建设性。而前者通常都是有益的，对改进具备指导性。最重要的是，它蕴含着对对方的尊重：只有真正关心对方的人才会提出建设性意见，希望对方在自身或是工作上有所进步。所以学着尊重对方，礼貌地给出建设性批评吧。如果你真的尊重一个人，那你就会自发地选择有技巧有帮助的措辞——这种技巧需要很多练习才能学会。
作为谈话的另一方，你也应该学会接受批评。这不是说你在技术上要谦虚，而是说你要信任对方，相信他是从心底为你好（当然还有你的项目），完全没有把你当傻瓜的念头。编程和所有技能一样，都需要熟能生巧。如果你的同事提出的做法比你现在的好，你会把它当成是对你的性格或是人生价值观的攻击吗？我们真心希望你不会。同样，你的自尊和你的代码不应该有什么联系。换句话说，你和你写的代码是两回事。你应该不断地告诫自己，你和你写的代码是两回事。不但你自己要相信这个观点，还要让你的同事也认同它。别把你的自尊和你的代码等同起来
举个例子，假如你有一个比较敏感的同事，那么下面这样的话是万万不能说的：“老兄，你完全把这个方法的控制流程给弄错啦。你应该和大家一样用标准的xyzzy代码模式才对。”这段话全是反模式的东西：首先你告诉他，他“错了”（好像这个世界非黑即白一样），然后要求他作出修改，最后还指责他写的东西和所有人都不一样（让他觉得自己很傻）。可以预见，这样会让对方变得很抵触，得到的回应也肯定是没有什么理智的成分。
好一点的版本可以是这样“：嗨～我有点看不懂这段代码的控制流程。要是用xyzzy代码模式的话会不会更清楚一点？维护起来也方便？”注意这里，你谦虚地把问题归到自己头上，而不是他。他没有错，只是你理解代码有困难而已。另外提出的建议也只是提供了一种方法让可怜的你能理解代码，或许还能在项目长期维护上有所助益。你也没有提出任何要求——你的同事完全可以谢绝这个建议。讨论的范围被限定在代码上，没有涉及任何人的价值观或是编程技术。快速失败；学习；迭代
商业界里有一个著名的（也是说烂了的）段子，说是曾经有一个经理因为犯下大错损失了上千万美金。第二天他非常沮丧地回到办公室开始整理桌子，这时他接到了预料之中的通知，“CEO想要见你”，于是他步履沉重地走进CEO的办公室，默默地递上一张纸。“这是什么？”CEO问道。“我的辞呈，”这位高管答道，“你叫我来就是要炒我鱿鱼的吧。”“炒鱿鱼？”CEO一脸狐疑地答道“，我为什么要炒你鱿鱼？我刚刚才花了一千万来培训你！”
当然，这个段子很极端，但是故事里的CEO心里明白，就算炒鱿鱼也不能挽回这一千万的损失，而且还要损失一名很有价值的高管，因为他以后肯定不会再犯这种错误了。
我们俩都在Google工作，而我们最喜欢的Google的格言之一就是“失败是可以接受的”。广泛的认识是如果没有经历过失败的话，就说明你的创新还不够，或者你承担的风险还太小。失败是更上一层楼的绝佳机会。事实上，托马斯·爱迪生曾经说过：“即便我找到了一万种行不通的办法，也不代表我失败了。我并不会因此而泄气，因为每次试错都是在前进。”
Google通常都采用这样一种（我们之前讨论过的）理念，“不要等到完美的时候再出来”：只要产品大致可用，就立刻把它按照原样公开给大众。这就是Google Labs的使命。这种办法使得成功和失败的地方得以立即显现出来，这样编程团队就可以尽快从中学习，迭代，然后发布新版本。它的缺点是Google常常会被揶揄说他家的产品总是在“beta”阶段，比如Gmail就“测试”了四年多。而它的优点在于可以迅速做出调整以适应变化，在很短的时间内就能做出惊艳的产品。所有的这一切都要求谦虚的特质——把不完美的软件展示给用户是可以接受的，另外还需要一些信任，即用户真的会认同你的努力，并且期望迅速看到改进。
从错误中学习的诀窍是要记住自己摔倒的地方，按商业用语来说就是“事后检讨”。但是要特别小心，千万不能把事后检讨的文件变成一堆无用的道歉和借口——这不是它的目的。真正的事后检讨应该包含有关“学到了什么”以及“怎么改正”等经验教训的详细注解。然后要保证把它放在一个随手可及的地方，并且认认真真地按照上面所写来实施改进。记住，正确地记录错误还能让其他人（不管现在还是将来）方便地了解事情的原委，以避免重复历史。不要抹掉自己的足迹——像跑道一样点亮它们，为后来人指路吧！
一份出色的事后检讨应该包含以下内容：
•简要
•事件的时间线，从发现到调查，再到最终结果
•事件发生的主因
•影响和损失评估
•立即修正问题的步骤
•防止事件再次发生的步骤
•得到的教训为学习预留时间
辛蒂曾经是超级巨星——在她的领域里她绝对是大师级的程序员。被提升为技术指导后，责任随之变大，而她也接受了这个挑战。很快她就能领导周围的每个人并指导他们工作了。她出席各种大会并就自己的领域作演讲，不久之后她已经能掌管好几个团队了，她也非常享受“专家”这个头衔。但是她却开始厌倦这种生活了，不知不觉地她不再学习新东西，成为所有人之中最聪明、经验最丰富的专家的这种新鲜感开始褪去。尽管表面上光鲜亮丽，但是总好像缺了点什么似的。直到有一天她终于意识到自己的领域不再尖端，人们开始转向其他更有兴趣的课题。她到底出了什么问题？
我们来分析一下：成为人群中最睿智的人的确很让人高兴，而且能够指导别人绝对可以带来了不起的成就感。但是问题在于一旦攀至顶峰，人们往往就会停止学习了。而当一个人不再学习的时候，她就会开始觉得厌倦，一不小心还会变得落伍。虽然当领导很过瘾，但是只要能放下一点骄傲，你就能开阔眼界，接触新鲜事物。这说穿了其实还是谦逊的问题和是不是愿意像指导别人一样接受别人的指导。偶尔应该跳出自己的舒适区，在更大的舞台上接受各种挑战。这样你才能长久地保持愉快的心情。学习保持耐心
傅攀勃在多年前写过一个把CSV仓库转到Subversion（以及后来的Git）上去的工具，由于RCS和CSV的行为异常古怪，他不断地发现各种诡异的bug，比如CVS会默默地吃掉明明是非法的RCS文件。而他的老朋友和同事卡尔对CVS和RCS都非常了解，他们决定一起来修复这些bug。
可是就在他们开始结对编程的时候发生了一个问题：傅攀勃喜欢自底向上的工作方式，他会深入项目，通过快速尝试各种情况来梳理细节。而卡尔却是喜欢自顶向下工作方式的工程师，他会先搭好框架，构建好调用栈里每个方法的实现后才会考虑bug的问题。这就引发了两人之间巨大的冲突和分歧，有时甚至会产生激烈的争执。傅攀勃和卡尔尽了极大的努力和专注，还恪守了HRT的原则才得以完成这项任务。HRT最终不但拯救了项目，也保住了他们之间的友谊。对影响保持开放的态度
你越是容易受影响，你就越能影响别人；你越是示弱，你就越强壮。这两句话看起来有点自相矛盾。但是每个人都碰到过某个同事，固执到叫人恼火。无论怎么试图说服他都没用，越劝越不听。最后怎么样？就我们的经验来讲，大家最后就会自然而然地把他当成障碍物“绕道而行”，再也不会有人听取他们的观点或反驳。没人希望这种事情发生在自己身上吧？所以请记住这一点：接受意见改变自己没什么大不了的。不要随意挑起争斗。不要忘了，要别人听你说话，首先是要学会当一个听众。注意在被影响的时候，如果你要听取意见，一定要在你下定决心或是确定宣布你已经做好决定之前——要是你的主意老是改来改去的，别人会觉得你这个人没什么立场。
说到示弱，初看之下也有点奇怪。如果一个人承认自己对某个东西一无所知，不知道要怎么解决问题，那他还能得到多少团队的信任么？示弱就是暴露弱点，这不是在摧毁自己的自信吗？
其实不是。承认自己犯错或是无知从长远来讲其实能提升你的形象。事实上它蕴含了HRT的全部方面：它对外表示了“谦虚”，这是有责任心、负责的态度，这也是表示“信任”别人意见的态度，同时作为回报，别人也会因为你的诚实和坚强而“尊重”你。所以有时候最好的答案就是：“我不知道。”诚实和谦虚不是氪气石
想想那些政客吧。这帮人之所以讨厌是因为无论他们错得多离谱，或是对件事物表现得有多无知，他们也从来不会承认，所以很多人都觉得政客的话是不可信的。这种现象主要是因为政客经常暴露在对手的攻击下。但是写软件的时候就用不着总是抱着防备的心态了——你的同事是合作者，不是竞争者。下一步
若能读到这里，说明你已经在掌握“与人合作”的艺术的征途上跨出了第一步，你已经检视反省了自己的行为。只要能在日常生活中运用这些策略，你就会发现合作将变得更自然，工作效率也能大大提高。
重要的改变要由自己做起，然后慢慢影响其他人。在下一章里，我们要讨论如何在你隶属的团队中培养HRT文化。第二章第培养出色的团队文化章
团队和团队之间的文化差异是非常大的，它反映了多种多样的价值观和对不同事物的重视程度。有些能引领团队走向成功，而有些却会导致彻底失败。即便是那些能带领团队成功的文化也有高下之分，有的非常高效，能让团队的注意力完全集中在编写软件上面；有的则会给手头的工作带来很多干扰。这一章我们要探讨的就是团队文化，特别是各种对成功有助益的沟通技巧。我们将会说明这些技巧是如何帮助出色的工程师团队更有效率地编写软件的。什么是文化
当我们听到“文化”这个词的时候，脑子里浮现的情景往往是某个晚上去歌剧院看演出，或是高中生物课上在培养皿里繁殖细菌的画面。工程师团队的文化其实和后者的差别并不大。
假如你吃过非常美味的发酵面包并且对烘培它的人感到好奇的话，你会发现这面包的关键就在于酵母。酵母是面粉和水里的酵母菌和乳酸菌。酵母菌能让面包膨大，而乳酸菌是让面包具有强烈酸味的秘密。然而并非所有乳酸菌都是一样的，有些乳酸菌产生出来的风味更好吃，所以当面包师找到味道一流的酵母（即含有恰当酵母菌混合比例的面团）时，她就会小心翼翼地通过加水和面粉来继续培养这种益菌群。然后只要取出一小部分酵母混进面包里，瞧！马上就能得到一条好吃的发酵面包啦！这是因为酵母里的菌群不但能产生她想要的风味，而且还能盖过面包食材本身以及空气中的酵母菌。你需要一块好酵母
团队文化就像是一块含有酵母的面团：酵母（团队创始人）能将菌群培养物植入生面团（团队新人），从而变出一块好吃的面包（团队）。如果团队本身具有很强的风格，它就能压过新人带来的任何“坏习惯”。如果团队文化不够强势，团队就会被新人带来的风气所影响。由于未知的文化往往伴随着未知的结果，因此一个团队最好拥有自己的熟悉的团队文化。好的酵母能让新人融入你的文化中
团队文化不仅仅是成员们编写代码的方式或是成员之间的相处之道，它还包含了所有人都认可的经验、价值观、目标。我们工作过或观察过的每个工程团队对此都有不同的见解。团队或者公司的创始人决定了团队大部分的特点，但它还是会随着时间不断变化发展。
组成团队文化的元素非常丰富。有些和代码编写有直接的关联，比如代码审查、测试驱动开发，以及在大规模进行编码前对于良好设计文档所抱的态度等。有些元素则和社交的关系更大一点，比如每个星期四一起去某个餐厅吃午饭，或是星期五的时候一起去大家都喜欢的酒吧喝一杯之类的。有些在外人看来甚至很傻很古怪：比如Google匹兹堡分部曾经就在一条货运火车线旁边，每次有火车经过的时候（顺便提一句，火车可是非常长的哦），大家都会跳起来互射Nerf泡沫枪弹。所有的这些元素组成了一支团队的文化，并且影响着团队的生产力以及吸引和留住优秀成员的能力。
试读结束[说明：试读内容隐藏了图片]