Written by Brian Fitzpatrick

Edited by Riona MacNamara

英文原文：https://abseil.io/resources/swe_at_google.2.pdf

翻译：liwenbo 这里一本关于google软件研发文化的书，里面有些内容个人觉得写得很好。尤其是自己做了这面几年的团队管理，比较认同其中关于研发组织文化、DevOps敏捷开发部分的内容。尝试翻译其中两章的内容，希望对看到的人有所帮助。

image-20210912214711673

由于本章是关于谷歌软件工程的文化和社会层面内容，所以我们从一个你绝对可以控制的变量开始本章的内容：你自己。

人生来都是不完美的，或者说人类本身就是一个会出现偶尔缺陷的有机体。但在你明白你同事的缺陷之前，你更应该先弄清楚你自己的问题。我们会让你思考一下你自己的反应、行为和态度，反过来，我们希望你能获得一些真知灼见，关于怎样花更多的时间在编写高效和优质的代码上，而在处理人际关系的问题上少浪费时间。

本章的核心观点是：软件开发是一个团队协助的过程。要想在研发团队（或者任何其他创新性组织）中取得成功，你需要在谦逊、尊重、信任的原则下重新组织你的行为。在我们超越自我之前，让我们先观察一下一般情况下软件工程师表现是什么样的。

帮我隐藏代码

Help Me Hide My Code

在过去的20年间，我与我的同事Ben在很多的编程会议中做过演讲。在2006年，我们发起了谷歌的 Open source Project Hosting service（已停办）。在最开始，我们被问到很多关于产品的问题及需求。但是，在2008年中期，我们开始关注到一类问题变化的趋势：

你们能够让google code上的svn隐藏某些特定的分支吗？

你们能不能实现：开始创建项目的时候是对外隐藏的，当项目开发好之后又可以对外公开？

您好，我想重写我的代码，能不能把那些历史记录都清空？

你能发现他们需求的共同点吗？

答案是不安全感。人们害怕其他人看到或者评价他们正在进行中的工作。从某种意义上讲，不安全感是人类与生俱来的一种特性，没有人喜欢被批评，尤其是对于还没有完成的事情。意识到这个问题之后，一个更加一般的软件开发的趋势是：不安全感实际上是更大问题的一种预兆。

天才神话

The Genius Myth

许多人都有寻找偶像的本能。对于软件研发工程师而言，这些偶像可能是 Linus Torvalds，Guido Van Rossum, Bill Gates，他们通过自己的传奇经历改变了世界。Linus是单单靠他自己写就了Linux操作系统，对吗？

实际上，Linus做的只是写了一个类似Unix内核的概念原型，并把它在电子邮件列表中将其公布出来。这是一个不小的成就，并且绝对算是一个令人印象深刻的成就。但这只是冰山一角，Linux操作系统整体上可比Linus最初实现的原型要庞大得多，并且是由成百上千名聪明的工程师共同开发完成的。Linus真正的成就是领导了这些人，协调他们的工作。Linux并不是Linus最初想法的成果，而是整个社区集体努力的光辉成果。并且，Unix本身也并不是完全由Ken Thompson和Dennis Ritchie所编写的，而是由贝尔实验室一群聪明的工程师所编写的。

同样的道理，是Guido Van Rossum一个人写了全部的 Python 代码吗？他当然是写了最初版本的 Python，但是后续的版本是由成百上千其他的工程师往上面添砖加瓦所完成的，这些砖瓦包括想法、新的特性、bug修复等。乔布斯（Steve Jobs）领导了建立苹果电脑的整个团队。虽然比尔盖茨（Bill Gates）由于编写了一个用于早期家用电脑的BASIC编译器所而被人熟知，但他更大的成功是创建了一个以MS-DOS为基础的了不起的公司。然而，他们都成了各自社区成就的领导者和象征。天才神话是一种趋势，是我们把一个团队的成功归因于某一个人或领导的趋势。

我们再来看看迈克尔乔丹（Michael Jordan）。

这是一个类似的故事。我们把乔丹当做偶像崇拜，但事实上他并不是完全靠着他自己来赢得每场篮球比赛。他真正的天才之处在于他与团队的协作。他团队的教练Phil Jackson非常聪明，他的执教技巧也堪称传奇。他意识到单靠一个人是绝对没办法赢得总冠军的，因此他打造了一只围绕乔丹的“梦之队”。这只球队就像一个润滑得很好的机器，至少在乔丹自己的印象里是这样的。

因此，我们为何不停地偶像化上述故事中的个人？为什么人们会购买由明星代言的产品？我们又为何想要去购买奥巴马（Michelle Obama）的礼服，或者乔丹的鞋子？

声望（Celebrity）在其中占据了很大作用。人类天生就有寻找领袖和榜样的本能，然后崇拜他们，并且试图去模仿他们。我们需要英雄来鼓舞我们，在程序设计的世界里，也需要这样的英雄。“科技名人”的现象似乎都已经进入了神话的范畴。我们都想要写一个类似Linux 这样改变世界的东西，或者设计出下一款优秀的编程语言。

在许多工程师的内心深处，他们都暗自希望自己被看做天才。他们幻想着类似下面这样的场景：

你被一个很棒的想法打动了，然后消失在你的小房间里数周或数月，拼命地实现你的想法。终于有一天你“发布”了你的软件，你的天才震惊了所有人。你的同龄人也都被你的天才所震惊。人们排着队来使用你的软件。名声和财务自然随之而来。

但是等等，现实情况是，你可能不是一个天才。

并无冒犯之意，我们肯定你是一个聪明的人。但你可能并不知道真正的天才是多么罕见。你会编写代码，这的确是一项很不错的技能。但即便你是一个天才，仅仅会编写代码也是远远不够的。天才也会犯错，并且有个很好的主意以及优秀的编程技巧并不能保证你的软件一定会成功。更为糟糕的是，你可能会发现你只是解决了分析问题，并没有真正解决人们的需求。作为一个天才绝对不是成为一个蠢蛋的理由：任何人，不管是不是天才，在社交技能上表现拙劣，都不会成为一个很好的同事。谷歌（以及大多数公司）的绝大多数工作可能不需要天才水平的智力，但百分之百需要最基本的社交技能。决定你职业生涯成败的因素，是你与他人合作的好坏，尤其是在像谷歌这样的公司。

原来“天才神话”只是我们不安全感的另一种表现。许多程序员害怕分享他们刚刚开始的工作，因为这意味着同行会看到他们的错误，知道代码的作者并非天才。

这里引用一位朋友的话：我知道我对于别人看我未完成的事情是非常没有信心的，好像他们会严肃地评判我，认为我是个白痴。这是很多程序员都会有的感觉，很自然地反映就是躲起来，编码、编码、编码，然后优化、优化、优化，以此来确保没有人能够看到你的愚蠢的代码。等到一切都完成了之后，再向全世界展示你的“杰作”。把所有的代码隐藏起来，直到全部都变得完美。另外一个隐藏工作的动机是害怕有别的程序员会抢走你的想法并在你之前完成他。把想法埋藏在心里，你就控制住了想法。我们知道你现在可能在想什么：“那又怎么样，人们难道不应该被允许以他们想要的方式工作吗？”事实上，不是的。在这种情况下，我可以断定你做错了，这是一件大事。这就是原因。

隐藏的危害

Hiding Considered Harmful

如果你把所有时间都花在独自工作上，你就会增加不必要失败的风险，并且会阻碍你的成长和发展。尽管软件开发是一项高度智力型工作，需要很多集中精力思考和独处的时间，但这并不代表不需要协作和评审。

首先，你怎么知道自己走对了路？想象一下，如果你是一个自行车设计爱好者，有一天你有了一个很棒的想法：采用全新的方法来设计换挡器的绝妙想法。你订购零件，然后花上几个星期躲在车库里来试着制造一个原型。当你的邻居，也是一名自行车倡导者，问你在弄什么，你决定不告诉他。你不想让任何人知道你的项目，直到它绝对完美。过了几个月，你会发现很难让原型正常工作了。因为你是秘密工作，所以不可能征求你那些喜欢机械的朋友们的意见。然后，有一天，你的邻居用一种全新的换档构件把他的自行车从车库里骑了出来。原来他一直在做一些与你的发明非常相似的东西，只不过是在自行车店的一些朋友的帮助下完成的。你这个时候很恼火，你给他看你的作品。他指出，你的设计有一些十分简单的缺陷，如果你一开始就给他看的话，这些缺陷可能在第一周就被修复了。我们可以从这个故事里吸取很多的教训。

尽早试错

如果你把你的“伟大”想法对全世界隐藏起来，在全部大功告成之前不对外展示任何东西，那么这将是一场赌博。在项目刚开始的时候，是很容易出现设计上的错误的。你可能冒着重新发明轮子的风险，隐藏起来也会让你失去了合作带来的好处。设想上个案例中你的邻居在朋友的协助下工作推进速度有多快？这就是为什么人们在跳入深水之前一定要先试水的原因：你需要确保你在做正确的事情，你在用正确的方式做事情，以及这件事情之前没有人做过。早期出现失误的可能性很高，记住下面这句久经考验的箴言:“早失败，快失败，经常失败。”

尽早地分享不仅仅关乎你的想法得到认可，避免你走偏方向，同时它对于加强项目的“巴士指数”也是至关重要的。

巴士指数

巴士指数：你的项目在有多少成员被巴士车撞到以后会完全崩溃掉。

liwenbo注：「巴士指数」是美国硅谷就团队凝聚力能力而言的一种民间定义，通俗的意思是你的团队里的某个成员被巴士撞到了，你的团队还能否照常运行，比方说你的团队里一个成员缺席导致工作无法进行那么你的团队的巴士指数为1，也就是比较依赖于某一个人的能力，也就是比较不健康的团队现状。

在你的项目中，知识和特定的技巧是如何传播和分享的？如果你是唯一一个了解原型代码如何工作的人，你可能会享受到良好的工作保障（一旦如果你被一辆公交车撞了，项目就完蛋了）。然而，如果你是和同事一起工作，你的“巴士指数”就翻了一倍。如果你有一个小团队一起设计和输出原型，情况就更好了，这样项目就不会因为某个团队成员离开而卡壳。请记住：团队成员可能不会真的被公交车撞到，但其他不可预知的情况仍然会发生。有些人可能会结婚、搬家、离开公司或请假照顾生病的亲戚。确保每项工作划分除了有一个主要的负责人和一个次要的负责人，另外还有一份**“看得懂”**的文档，这有助于将来确保项目的成功，并能够增加项目的“巴士指数”。希望大多数工程师都能认识到：成为一个成功项目的一部分，要强过成为一个失败项目的关键部分！

除了“巴士指数”，还有整体进度的问题。人们很容易忘记，独自工作往往是一件很苦的差事，要比一群人一起工作慢得多。当你独自工作的时候，你学到了多少？你推进有多快？虽然Google和Stack Overflow是很好的信息参考的地方，但他们并不能替代真实的人的经验。与他人一起工作可以增加工作背后的集体智慧。你是否有过这样的经历，被一个很小的东西卡壳住了，花了不知道多少时间才走出谜团。想象一下，如果你有几个同伴在身后看着你，并能够立即帮你指出，你是如何犯错误的，如何解决这个问题，那会是多么不同的体验。这就是为什么软件工程公司的团队需要坐在一起（或者进行结对编程）。编程是很困难的，软件工程就更难了，你需要更多双的眼睛。

进度的把控

Pace of Progress

这里有另外一个类比，想象一下你是怎样跟编译器一起工作：当你坐下来要写一个大型软件的时候，你是不是花一整天时间写10000行代码，然后在写完之后，都是很完美的代码，在第一次按下“编译”按钮的时候，就大功告成了！当然不是，你能够想象这样做的灾难性后果吧？程序员只有在频繁的反馈循环中才能工作得很好：编写一个新函数，编译；添加一个测试，编译；重构一些代码，编译。通过这样的方式，我们能够尽早地发现和修复拼写错误和缺陷（bug）。我们希望每一步都有编译器在身边，有些IDE环境甚至可以在我们输入代码的时候就开始编译代码。这是我们保证代码高质量的方法，并且这样能够确保我们的软件是正确的，一点一点地不断演进。当前DevOps关于技术生产力的哲学很明确地描述了这些目标：尽早获得反馈，尽早测试，尽早考虑安全和生产环境。这都与开发人员工作流程中的“向左移动”理念捆绑在一起；我们越早发现问题，解决它的成本就越低。

类似的快速反馈机制不仅仅在代码级别需要，整个项目级别也是需要的。目标庞大的项目发展迅速，必须适应不断变化的环境。项目会遇到不可预测的设计障碍、政治风险，或者事情并没有按计划进行，需求未按照预想进行了变动。那么你该如何获得反馈循环，以便立即知道你的计划或设计需要改变？答案是通过团队合作。大多数工程师都知道这句话:“眼睛越多，缺陷越少！（Many eyes make all bugs shallow）”，但更好的说法可能是:“人多眼多，确保项目在正轨。（Many eyes make sure your project stays relevant and on track.）”闭门造车的人们醒来后发现，虽然他们最初的愿景可能是完整的，但世界已经改变了，他们的项目已经变得无关紧要了。

案例学习：工程师和办公室

二十五年前，传统观点认为，工程师要想提高工作效率，就必须有自己的办公室，而且办公室的门必须是关着的。据推测，这是他们能够有大量不间断的时间来深度专注于编写大量代码的唯一方法。

我认为对于大多数工程师来说，呆在私人办公室不仅是没有必要的，而且是非常危险的。今天的软件是由团队而不是个人编写的，与团队其他成员的高频、随时的沟通连接，甚至比网络连接更有价值。你可以拥有世界上所有不受干扰的时间，但如果你把它用来做错误的事情，那么你就是在浪费时间。

不幸的是，现代的科技公司（在某些情况下，也包括谷歌）似乎又走向了另一个极端。走进他们的办公室，你经常会发现工程师们聚集在一个巨大的房间里：一百多人在一起，没有任何墙壁。这种“开放式办公室”现在是一个备受争议的话题，结果就是，对开放式办公室的敌意正在上升。哪怕是最微小的谈话也会成为公共话题，人们最终都不敢说话了，因为可能会惹恼到几十个邻居。这使得开放式办公室跟私人办公室一样糟糕!

我们认为中间的状态才是最好的解决方案。把4~8个人组成的团队放在一个小房间(或大办公室)里，这样可以很容易(也不会尴尬)进行他们内部的谈话。

当然，在任何情况下，个体工程师仍然需要一种方法来过滤噪音和干扰，这就是为什么我所见过的大多数团队都开发了一种方法来沟通，以限制目前很忙的同事免受过多的干扰。我们中的一些人曾经在一个有“语音中断协议”的团队中工作：如果你想说话，你会说“断点玛丽”，玛丽是你想要交谈的人的名字。如果玛丽到了可以停下来的时候，她会把椅子转过来听。如果玛丽太忙了，她只会说“收到”，而你会继续做其他事情，直到她完成手头上的工作。

有些团队，成员会把纪念品或填充动物放在显示器上，表示只有在紧急情况下才可以打断他们。还有一些团队会给工程师提供降噪耳机，以使他们更容易隔绝噪音 — 事实上，在许多公司，戴耳机的行为本身就是一种常见的信号，意思是“除非真的很重要，否则不要打扰我。”许多工程师在编码时倾向于只使用耳机模式，这在短时间内可能有用，但如果一直使用，就会像把自己关在办公室里一样不利于合作。

不要误解—我们仍然认为工程师需要不间断的时间来专注于编写代码，但我们认为他们同样需要与团队之间的高质量、低摩擦的沟通和联系。如果你的团队中缺乏知识的人觉得向你提问存在障碍，那就有问题了：找到正确的平衡是一门艺术。

简言之，不要隐藏

所以，“隐藏”可以归结为：独自工作比团队协作具有内在的风险。即使你可能害怕别人窃取你的想法或认为你不聪明，你也应该更关心不要浪费大量时间在错误的事情上。

不要成为另一个统计数字。

一切为了团队

It’s All About the Team

现在让我们把之前的所有想法放到一起。

我们一直在强调的一点是，在编程领域，孤独的工匠是极其罕见的——即使他们确实存在，他们也不可能在真空中做出超人的成就；他们改变世界的成就几乎总是灵感的火花和英勇的团队努力的结果。

一个伟大的球队会巧妙地利用超级球星，使得整体总是大于部分的总和。但创建一支超级巨星球队是极其困难的。

让我们用更简单的话来说:“软件工程是一个团队的努力”。

这一概念与我们许多人内心中对天才程序员的幻想是截然相反的，但如果你独自呆在黑客小屋时，说明你还不够聪明。你不可能通过隐藏并完成你的秘密发明来改变世界，或取悦数百万的计算机用户。你真正需要的是和其他人一起工作，分享你的愿景，分解工作任务，向他人学习，创造辉煌的团队。

想想看：你能说出多少被广泛使用的、成功的软件是真正有一个人编写的？(有些人可能会说“LaTeX”，但它很少被“广泛使用”，除非你觉得写科学论文的人数在所有计算机用户中占有很大比例!) 高效运作的团队是黄金，也是成功的真正关键。无论如何，你都应该瞄准这个方向。

社会交际的三大支柱

The Three Pillars of Social Interaction

如果团队合作是生产优秀软件的最佳途径，那么如何才能构建(或找到)优秀的团队呢?

为了达到协作的完美境界，你首先需要学习并接受我所说的社交技能的“三大支柱”。这三条原则不仅仅是用来润滑人际关系的，它们也是所有良性互动和合作的基础：

如果你对几乎所有的社会冲突进行根源分析，你可以将他们最终归结为三个方面的原因：谦逊（Humility），尊重（Respect），信任（Trust）。乍一听你可能觉得难以置信，但你不妨试一试。想想一下你生活中一些令人不快或不舒服的社交场景。在最根本上，每个人都适当地保持谦逊了吗？人们真的互相尊重吗？是否存在相互信任？

为什么这三大支柱重要？

Why Do These Pillars Matter?

当你开始阅读这一章的时候，你可能并不打算报名参加某种周末活动小组。我们很理解，处理社交问题可能是困难的：人是各式各样的，不可预测的，而且经常难以接触。与其把精力花在分析社交情况和采取合适的行动上，不如不去管他。跟编译器打交道可是要容易得多，为什么还要在社交方面费心劳力呢?

下面是引用自理查德·汉明的著名演讲:

通过不辞辛苦地给秘书们讲笑话和表现出一点友好，我收获了极好的助理服务。比如，有一次因为某种愚蠢的原因默里山（Murray Hill）的所有再生产都被冻结了。我也不知道具体情况，但他们确实被冻结了。我想做点什么。我的秘书给在霍尔姆德尔（Holmdel）的某个人打了电话，然后跳上公司的车，花了一小时的时间，让它重新开始生产，最后回来了。这应该是我好几次努力使她高兴起来、给她讲笑话、表示友好的结果，就是那一点点额外的工作后来让我得到了回报。当你意识到你必须使用社交系统，并学习如何让这套系统为你工作，你就学会了怎样使系统来适应你的欲望。

这段演讲的寓意是：不要低估社会交际的力量。社会交际不是关于欺骗或操纵别人，而是关于怎样建立好关系，把事情做好。关系总是比项目更持久。如果你和同事的关系更加融洽，当你需要他们的时候，他们会更愿意付出额外的努力。

谦虚，尊敬和信任的实践

Humility, Respect, and Trust in Practice

所有这些关于谦逊、尊重和信任的说教听起来都像是在布道。让我们拨开迷雾，思考一下如何将这些想法应用到现实生活中去。我们将从一系列特定的行为和例子开始。很多错误一开始可能听起来很明显，但当你开始思考这些错误时，你会发现你(和你的同事)经常会因为没有遵循这些错误而感到内疚——我们自己当然也注意到了这一点!

不要过于自我

Lose the ego

好吧，这是一种比较简单的方式，用来告诉那些没有足够的谦虚而失去“态度”的人。没有人愿意和一个总是表现得好像自己是办公室里最重要的人一起工作。即使你知道你是讨论中最聪明的人，也不要在别人面前炫耀。例如，你是否总是觉得在每件事情上，你都需要在开始或者结束的时候说点什么？你是否觉得有必要评论提案或讨论中的每一个细节？或者你认识做这种事的人吗?

虽然谦逊很重要，但这并不意味着你要做一个受气包。自信并没有错，只是不要表现得像个万事通。更好的做法是，考虑“集体”的自我意识；与其担心你个人是否出色，不如试着去建立一种团队成就感和团队自豪感。例如，Apache软件基金会在围绕软件项目创建社区方面有着悠久的历史。这些社区有着难以置信的强烈身份认同，排斥那些更关注于自我推销的人。

过于自我可以表现在很多方面，以及很多时候，它会阻碍你的工作效率，减慢你的工作速度。下面是汉明演讲中的另一个精彩故事，它完美地说明了这一点（强调我们的）:

约翰·杜克几乎总是穿着很随意。当他走进一间重要的办公室，要过很长一段时间，人们才会意识到他是第一流的人，最好听他的。长期以来，杜克都不得不克服这种麻烦。这实在是浪费精力，我不是说你不应该穿得舒服，我的意思是，“过于随意的穿着会让你走很多冤枉路。”如果你选择用任何一种方式来维护你的自我：“我就是要用我的方式去做！”，你就会在你的整个职业生涯中付出长期且稳定的代价。而这，在人的一生中，会积累起来变成大量不必要的麻烦。[…此处省略部分演讲内容…] 通过意识到你必须使用社交系统并学习如何让该系统为你工作，你就学会了如何使系统适应你的欲望。或者，你也可以让它像一场不宣而战的小战争一样，在你的一生中与之斗争到底。

学会给予和接受批评

Learn to give and take criticism

几年前，Joe开始了一份程序员的新工作。第一周后，他开始深入研究代码库。因为他关心正在发生的事情，他开始温和地询问其他团队成员的贡献。他通过电子邮件发送简单的代码审查，礼貌地询问设计中的假设，或指出可以改进的逻辑。几周后，他被叫到主管的办公室。“有什么问题吗?”Joe问。“我做错什么了吗?”主管看上去很关心地说:“Joe，关于你的行为我们已经收到了很多抱怨。显然，你对你的队友非常严厉，到处批评他们。这使得他们心烦意乱。你需要低调一点。”Joe完全懵住了。他理所当然地认为他的代码评审应该受到同行的欢迎和赞赏。在这个案例中，Joe应该更加敏感，因为该团队普遍存在不安全感，Joe应该使用一种更微妙的手段来引入代码评审到文化中。比如提前与团队成员讨论这个想法，并让团队成员尝试几周。

在专业的软件工程环境中，批评几乎从来都不是针对个人的——它通常只是将项目完成地更好的过程中的一部分。诀窍在于确保你(以及你周围的人)理解建设性批评他人成果和公然攻击他人性格之间的区别。后者是无用的——它是琐碎的，几乎不可能采取行动。前者可以(也应该!)提供帮助并指导如何改进。而且，最重要的是，建设性批评充满了尊重：提出建设性批评意见的人是在真诚地关心他人，希望他们改进自己和工作。学会尊重你的同事，礼貌地提出建设性的批评意见。如果你真的尊重某人，你会有动力选择得体的、有益的措辞—-这是一种通过大量实践获得的技能。我们在 [第9章] 中对此有更多的介绍。

在交流的另一方面，你也要学会接受批评。这意味着你不仅要对自己的技术水平保持谦虚，还要相信别人是在真心地关注你(以及你的项目)，他们不会真的认为你是白痴。编程是一种技能，就像其他任何东西一样，它会随着练习而不断提高。如果一位同事指出了你可以改进技巧的方法，你会认为这是对你人格和价值的攻击吗？我们希望没有。同样地，你的自我价值不应该与你写的代码或你建立的任何创造性项目联系在一起。重复一遍：你不是你的代码。把这句话重复地说。你所做的并不是你。你不仅要自己相信，还要让你的同事也相信。

例如，如果你有一个不熟悉的同事，下面的话可不能说:“伙计，你在那个方法上的控制流程完全错了。您应该像其他人一样使用标准的xyzzy代码模式。”这种反馈充满了反模式。你在告诉别人他们是“错误的”(就好像世界是黑白的)，要求他们改变一些东西，并指责他们创造了一些与其他人所做的相反的东西（让他们觉得自己很愚蠢）。你的同事很快就会觉得受到了冒犯，而他们的反应肯定会带有情绪。

更好的表达方式可能是：“嘿，我对你这段的控制流感到困惑。我想知道xyzzy代码模式是否可以使它更清晰、更容易维护？”注意你是如何用谦虚的方式来提问的，这是关于你自己的问题，而不是他们的。他们没有错，你只是无法理解代码。这个建议只是作为一种方式，为可怜的你澄清事情，同时可能有助于项目的长期可持续发展目标。你也没有要求什么—你给了你的同事平静地拒绝建议的能力。讨论集中在代码本身，而不是任何人的价值或编码技能。

快速失败和迭代

Fail fast and iterate

在商界有一个广为人知的传奇故事，说的是一位经理犯了一个错误，损失了数额惊人的1000万美元。第二天，他沮丧地走进办公室，并开始收拾他的办公桌，当他接到意料之中“CEO 想在他的办公室见你”的电话时，他拖着沉重的脚步走进CEO办公室，悄悄地把一张纸从桌子上递了过去。

“那是什么？”CEO问。

“我的辞呈，”经理说。“我觉得你把我叫进来是要解雇我。”

“解雇你？”CEO出人意料地回应道，“为什么要解雇你？我刚交了1000美元的学费训练你！”[6]

这当然是一个极端的故事，但故事中的 CEO 明白，解雇这名高管并不能弥补1000万美元的损失，而且如果失去一位有价值的高管，还会将损失加重。这位高管在以后的职业生涯中肯定不会再犯这样的错误，

在谷歌，我们最喜欢的座右铭之一是**“失败也是一种选择”**。人们普遍认为，如果你没有时不时地失败，你就没有足够的创新或承担足够的风险。失败被视为在下一次尝试时学习和提高的黄金机会。事实上，人们经常引用爱迪生的名言：“如果我找到了一万种行不通的方法，那我还不算失败。我并不气馁，因为每次放弃的错误尝试都是向前迈进的一步。”

在谷歌致力于“登月计划”的X部门，如自动驾驶汽车和气球提供的互联网接入，失败被故意纳入其激励体系。人们想出古怪的想法，积极鼓励同事尽快否定它们。每个人都会得到奖励（甚至是竞争），看他们能在固定的时间内提出多少反驳或否定的观点。只有当一个概念真的不能在白板上被所有人揭穿时，它才会进入早期原型。

复盘文化

Blameless Post-Mortem Culture

从错误中学习的关键在于，分析错误的根本原因并编写“事后复盘”来记录失败，谷歌(以及许多其他公司)就是这么说的。要格外小心，确保“事后复盘”不是一堆无用的道歉、借口或指责，这些都不是复盘的目的。一个恰当的事后复盘应该总是包含：从这次失败（错误)中学到了什么经验，以及学习了这些经验后会做出怎样的改变。然后，要确保复盘记录是很容易访问到的，并且确保团队真的是按照所提的改进建议进行了改进。正确地记录失败还可以让其他人(现在的和将来的)更容易知道发生了什么，并避免重蹈覆辙。不要抹去你的足迹，要为那些追随你的人照亮他们的跑道!

一个好的事后复盘应该包括以下内容：

  • 事件的概要

  • 事件的时间表，从发现到调查到解决事件的主要原因影响和损害评估

  • 事件的主要原因

  • 影响和带来的损失的评估

  • 一组立即修复问题的操作项(与所有者一起)

  • 防止事件再次发生的一组操作项

  • 经验总结

学会耐心

Learn patience

多年以前，我编写了一个将CVS存储库转换为Subversion（后来又转换为Git）的工具。由于CVS的反复无常，我不断地发现奇怪的bug。因为我的老朋友和同事Karl也非常了解CVS，所以我们决定一起修复这些bug。

当我们开始进行结对编程时，出现了一个问题：我是一个自下而上的工程师，我习惯于通过快速尝试许多内容并略去细节来找到我的解决方法。然而，Karl是一个自上而下的工程师，他希望在处理bug之前全面了解并深入研究调用堆栈上几乎所有方法的实现。这导致了一些巨大的沟通冲突、分歧、以及偶尔的激烈争论。事情发展到这样的地步，我们两个根本无法在一起进行配对编程：这对我们俩来说都太沮丧了。尽管如此，我们之间的相互信任和尊重由来已久。再加上耐心，这帮助我们想出了一种新的合作方法。我们会一起坐在电脑前，找到bug，然后我俩分开，从两个方向（自上而下和自下而上）同时解决问题，然后带着我们的解决方法再一起回来。我们的耐心和自愿即兴创作新的工作风格不仅挽救了项目，也挽救了我们的友谊。

乐于接受影响

Be open to influence

你对影响的态度越开放，你就越能施加影响；你越示弱（vulnerability），你就显得越强大。这些说法听起来自相矛盾。但每个人都能想到一些他们共事过的人，他们非常顽固，以致于无论人们怎样劝说他们，他们都更加顽固。这些团队成员最终会怎么样？根据我们的经验，人们不再听取自己的意见或反对意见；相反，团队成员最终会“绕过”他们，就像一个每个人都认为理所当然的障碍。你肯定不想成为那样的人，所以在你的头脑中记住这个想法：别人改变你的想法是没关系的。在本书的开篇，我们说过，工程本质上就是权衡取舍。除非你有一个不变的环境和完善的知识，否则你不可能事事都是正确的，所以当遇到新的情形时，你当然应该改变自己的想法。仔细选择你的“战斗”：要想被恰当地倾听，你首先需要倾听别人。最好是在做出决定或坚定地宣布一个决定之前，先认真倾听—如果你总是改变主意，人们就会认为你优柔寡断。

示弱的想法看起来也很奇怪。如果有人承认对于手头上的话题或问题的解决方案一无所知，那么他们在团队中还能有什么可信度呢？示弱是软弱的表现，这会破坏信任，对吧?

这并不对。从长远来看，承认你犯了一个错误或者你只是不适合自己可以提升你的地位。事实上，愿意表达脆弱是一种谦卑的外在表现，它展示了责任感和承担责任的意愿，这是一个信号，表明你信任别人的意见。作为回报，人们最终会尊重你的诚实和力量。有时候，你能做的最好的事情就是说，“我不知道。”

举个例子，职业政客就因从不承认错误或无知而臭名昭著，即使他们在某个问题上的错误或无知是显而易见的。这种行为的存在主要是因为政客们经常受到他们政敌的攻击，这也正是为什么大多数人不相信政客们所说的话的原因。然而，当你在编写软件时，你不需要一直处于守势—你的队友是合作者，而不是竞争者。你们的目标是一致的。

学习谷歌风格

Being Googley

在谷歌，当涉及到行为和人际交往时，我们有自己的内部版本的“谦逊、尊重和信任”原则。

从谷歌文化的早期开始，我们就经常把行为称为“谷歌式的”或“非谷歌式的”。这个词从来没有明确的定义。相反，每个人只是把它理解为“不作恶”或“做正确的事”或“对彼此好”。随着时间的推移，人们也开始把“Googley”这个词作为一种非正式的文化契合度测试来使用，无论我们在面试工程师职位的候选人时，还是在撰写彼此的内部绩效评估时。人们经常用这个词来表达对他人的看法，比如：“这个人编码很好，但似乎没有很好的谷歌式态度。”

当然，我们最终意识到“Googley”这个词承载了太多的含义。更糟糕的是，它可能成为招聘或评估中无意识偏见的来源。如果“Googley”对每个员工的意义都不一样，那么我们就要冒着这个词开始意味着“就像我一样”的风险。显然，这不是一个很好的招聘准则——我们不想招聘“和我一样”的人，我们更想招聘到拥有不同背景、不同观点和经验的人。面试官想和应聘者（或同事）喝杯啤酒的个人愿望，绝对不能成为衡量那个人的表现或在有谷歌茁壮成长的能力的信号

谷歌最终解决了这个问题，明确定义了“Googleyness”的含义：一组我们寻找的能够代表强大领导力、体现“谦逊、尊重和信任”的特质和行为:

  • 适应歧义（Thrives in ambiguity）：能够处理相互冲突的信息或方向，建立共识，并在问题上取得进展，即使环境在不断变化。

  • 值的反馈：能够谦恭地接受和给予反馈，理解反馈对个人(和团队)发展的价值。

  • 挑战现状：能够设定雄心勃勃的目标，并在可能受到他人阻力或惰性的情况下继续追求。

  • 用户至上：理解并尊重谷歌产品的用户，并采取符合他们最大利益的行动。

  • 关心团队：理解并尊重同事，主动帮助他们，提高团队凝聚力。

  • 正确做事：对他们所做的每件事都有强烈的道德感；愿意做出困难或不便的决定，以保护团队和产品的完整性。

现在我们已经更好地定义了这些最佳实践行为，我们就开始回避使用“Googley”这个词了。对于期望的具体说明总是比泛泛而谈要好一些。

总结

Conclusion

几乎所有的软件项目（不管什么规模）的基础都是一个功能良好的团队。尽管独自开发软件的天才神话依然存在，但事实是没有人真正独自开发软件。对于一个经得起时间考验的软件组织而言，它必须有一种健康的文化，根植于围绕着团队而非个人的谦逊、信任和尊重。此外，软件开发的创造性本质决定了人们需要承担风险，偶尔也会失败；为了让人们接受失败，必须有一个良性的的团队环境。

TL;DRs 速览

了解独立工作的利弊。承认你和团队成员在沟通和处理人际冲突上所花的时间。在了解自己和同事的个性及工作风格上做一点小小的投资，能够大大地提高工作效率。如果你想在一个团队或大型组织中高效地工作，要了解自己和其他人喜欢的工作方式。

1 Ben Collins-Sussman, also an author within this book.

2 Literally, if you are, in fact, a bike designer.

3 I should note that sometimes it’s dangerous to get too much feedback too early in the process if you’re still unsure of your general direction or goal.

4 I do, however, acknowledge that serious introverts likely need more peace, quiet, and alone time than most people and might benefit from a quieter environment, if not their own office.

5 This is incredibly difficult if you’ve been burned in the past by delegating to incompetent people.

6 You can find a dozen variants of this legend on the web, attributed to different famous managers.

7 By the same token, if you do the same thing over and over and keep failing, it’s not failure, it’s incompetence.