隐藏是不利的

由于本章是从文化和社会的角度来讲谷歌内部的软件工程，所以我们先从你一个可以掌控的因素说起： 你自己。

人天生就是不完美的——我们经常说人类大都是一个个bug的集合体。但是在了解同事的bug之前，你需要先了解自己的bug，可以从自己的反应、行为和态度方面来了解。看完本章后，我们希望你能真正了解如何成为一名更高效、更成功的软件工程师，能够少花精力处理与人有关的问题，有更多时间编写出色的代码。

本章的核心观点是软件开发是要由团队协作来完成的。要在你的工程团队或者其他创造性的组织中取得成功，你需要围绕谦逊、尊重和信任这三个核心原则来组织你的行为。

我们先观察下软件工程师的一些常见行为，然后我们再讲讲如何提升自己。

帮我隐藏代码

在过去的20年间，我和我的同事Ben多次在编程会议上发表演讲。 2006年，我们推出了Google的开源项目托管服务（现已弃用），起初，我们还会收到很多关于该产品的问题和建议。但是在08年年中，我们发现收到越来越多这样的请求： “你能不能让Google Code上的SVN可以隐藏某个特定的分支？” “你能不能让创建开源项目一开始就对外隐藏，然后等它们准备好再公开？” “嗨，我想从头开始重写我所有的代码，你能抹掉所有的历史吗？”

你能找出这些请求的共同点吗？

答案是缺乏安全感。人们害怕别人看到和评判他们正在进行的工作。从某种意义上说，缺乏安全感只是人性的一部分——没有人喜欢被批评，尤其是因为尚未完成的事情被批评。认识到这点让我们看到了软件开发中的总趋势：缺乏安全感实际上是一个更大的问题的征兆。

天才神话

许多人会本能地寻找和崇拜偶像。对于软件工程师来说，他们的偶像有可能是Linus Torvalds、Guido Van Rossum、Bill Gates——这些都是改变世界的英雄。Linus自己完成了Linux，对吧？

实际上，Linus完成了类Unix内核验证理论的开头，并通过电子邮件发出去。这是不小的成就，绝对是了不起的成就，但这仅仅是Linux的冰山一角。现在的Linux比最初的内核大数百倍，而且是由数千名聪明人开发的。Linus的真正成就是带领这些人并协调他们工作；Linux的光辉得益于社区的集体努力，而不是Linus的最初创意。（还有，Unix本身并不完全是由Ken Thompson和Dennis Ritchie编写的，而是出自于贝尔实验室的一群聪明人。）

同样，是Guido Van Rossum一个人独自编写了全部的Python？当然，他的确编写了第一个版本，但还有其他数百人负责为后续版本做出贡献（包括创意、功能和bug修复）。史蒂夫·乔布斯领导了构建Macintosh的整个团队，尽管比尔·盖茨以为早期家用计算机编写BASIC解释器而闻名，但他更大的成就是围绕MS-DOS建立了一家成功的公司，他们都成为了领导者，成为了集体成就的和象征。天才神话是我们人类将团队的成功归因于一个人/领导者的现象。

那么迈克尔·乔丹呢？

是一样的，我们崇拜他，但事实上他并没有一个人赢得每一场篮球比赛。 他真正的天才之处在于他与团队合作的方式。球队的教练菲尔杰克逊非常聪明，他的教练技术堪称传奇。

他认识到只有一个球员永远无法赢得冠军，因此他围绕MJ组建了一支完整的“梦之队”。这支球队是一台运转良好的机器——至少和迈克尔本人一样令人印象深刻。

那么，为什么我们一而再再而三地崇拜这些故事中的个人呢？为什么人们会购买名人代言的产品？为什么我们要买米歇尔奥巴马的裙子或迈克尔乔丹的鞋子？

名人效应是一个重要原因。人类会本能地寻找领导者和榜样、崇拜他们并试图模仿他们。我们都需要英雄来激发灵感，而我们的编程世界也有英雄，“科技名人”已经几乎被神化。我们都想写一些像Linux一样改变世界的东西，或者设计出下一个优秀的编程语言。

许多工程师在内心深处都暗自幻想被视为天才，幻想一般是一样的： • 首先，你被一个很棒的新概念所震撼。 • 你会在数周或数月的时间里隐藏在自己的洞穴中，努力实现你的想法。 • 然后，你在世界上“发布”你的软件，用你的天赋震惊所有人。 • 你的同行为你的聪明感到惊讶。 • 人们排队使用你的软件。 • 名利自然随之而来。

但是，请稍等，是时候回归现实了，那就是你很可能不是天才。

当然，无意冒犯——我们确信你是一个非常聪明的人。但是你知道真正的天才是多么罕见吗？当然，你会编写代码，这是一项较难掌握的技能。 但即使你是天才，事实证明，仅仅会编写代码这还不够，天才也会犯错误，仅仅拥有绝妙的想法和高超的编程技能，并不能保证你的软件会大受欢迎。 更糟糕的是，你可能会发现自己可以通过分析解决很多问题，但是却不擅长解决人际交往问题。 而成为天才绝对不是变成混蛋的借口：任何社交能力差的人——不管是不是天才——往往是一个糟糕的队友。 谷歌（以及大多数公司！）的绝大多数工作并不需要天才级别的智力，但100%的工作都需要最低水平的社交技能。决定你职业生涯的成败，尤其是在谷歌这样的公司，取决于你与他人合作的程度。

事实证明，这个天才神话只是我们缺乏安全感的另一种表现。

许多程序员害怕分享他们刚刚着手的工作，因为这意味着同行会看到他们的错误，并且知道代码的作者不是天才。

引用一位朋友的话： “别人在我完成某事之前就来看，这会让我感到非常不安全，就好像他们会认真地评判我并认为我是个白痴一样。”

在程序员群体中，这是极其常见的感觉，他们的自然反应是躲在山洞里，工作，工作，工作，然后打磨，打磨，打磨，确定没有人会看到你丢脸，这样你就能够在完成后展示你的杰作。隐藏起来，直到你的代码变得完美。

隐藏你的工作的另一个常见动机，是担心其他程序员可能会在你开始工作之前借走你的想法并执行它。你可以通过保守秘密来掌控这个想法。

我们知道你现在很可能在想什么：那又怎样？难道不应该允许人们随心所欲地工作吗？

实际上，不应该。在这种情况下，我们很肯定你做错了，而且这是一个大问题。

接下来看看为什么。

隐藏是不利的

如果你把所有时间都花在一个人工作上，不必要的失败的风险就增加了，而且还会耽误你的成长潜力。尽管软件开发是深度智力型工作，它需要高度集中的注意力和独处的时间，但你必须要同等重视协作和评审的重要性（和必要性！）。

首先，你怎么知道你是不是在正确的轨道上？

想象一下，你是一名自行车设计爱好者，有一天，你有了一个绝妙的主意，可以用一种全新的方式来设计变速杆。你订购了零件，然后在车库里花好几周时间尝试构建原型产品。当你的邻居——也是自行车爱好者——问你发生了什么事时，你不打算谈论你的想法。在你的原型产品绝对完美之前，你不希望任何人知道它的存在。又过了几个月，你的原型作品遇到了麻烦，没法正常工作。但是因为你在秘密工作，所以不可能从你的机械专家朋友那里征求帮助。

然后，有一天，你的邻居将他的自行车从车库中拉出，这辆自行车使用一种全新的换档结构。事实上，他一直在建造与你的发明非常相似的东西，只不过他得到了在自行车店的一些朋友的帮助。这时候，你很生气。于是你给他看你的作品，而他指出你的设计中的一些简单的缺陷——如果你早些向他展示，那就可能会在第一周修复这些缺陷。 这个故事里有很多教训可以学习。

提早发现（问题）

如果你隐藏你的好点子，并且在打磨好它之前拒绝向任何人展示它，你是在下大赌注。首先，在实现点子的早期，很容易犯下明显的设计错误，同时你也冒着重复造轮子的风险，而且也失去了协作的优势：你也看到你的邻居与别人合作的速度有多快了。这就是为什么人们在跳入深水之前将脚趾浸入水中的原因：你需要确保自己在做正确的事情，这个事情你做对了，而且以前没有人做过。前期失误的可能性很高，你提早征求的反馈越多，这种可能性就越低。 记住“早早失败、快快失败、常常失败”这句久经考验的格言。

提早分享不仅仅能检查你的想法，防止个人失误，同样重要的是能够提升项目的巴士指数。

巴士指数

巴士指数（名词）：被公交车撞到多少人，你的项目会彻底失败。

你的项目中所用到的知识和技能是怎么分布的？如果你是唯一了解项目代码的人，那么你可能会享有良好的工作待遇——不过如果你被公交车撞了，这个项目就完蛋了。但是，如果你是和一位同事一起工作的，那么你的巴士指数就翻了一番。如果你有一个小团队，大家一起设计和制作项目，情况会更好——当团队成员不在时，项目不会停滞。当然：团队成员可能不会真的被公共汽车撞到，但仍然会发生其他不可预测的事情，他们可能结婚、搬家、离职或请假照顾病人。除了确保项目的每个重要环节有第一和第二负责人外，至少还应该有清晰的文档，这样才有助于确保项目在未来取得成功，并增加项目的巴士指数。希望大多数工程师认识到一点，那就是与其成为失败项目的核心，不如成为成功项目的一员。

除了巴士指数之外，还要说下项目的整体进展方面。我们经常忘记一点，独自工作通常是非常慢的，慢到我们不想对外说。在独自工作时，你能学到多少？你能前进多快？的确Google和Stack Overflow能提供建议和信息，但它们不能代替人类的实际经验。与其他人一起工作，能直接增加努力带来的集体智慧。当你被一些荒谬的事情卡住时，你浪费了多少时间把自己从洞里拉出来？想想看，如果你有几个同事关注着你，立即告诉你哪儿错了，要怎么改，这和独自工作的情况是不一样的。

这正是软件工程公司中一个团队要坐在一起（或进行结对编程）的原因。编程很难，软件工程更难。你需要第二双眼睛（来帮助你）。

进展速度

再来举个例子，想一下，你是如何使用编译器的。当你坐下来写软件的一大块功能时，你会不会花几天时间写一万行代码，在写完最后一行完美的代码后，第一次按下编译按钮？当然不会。你能想象这样做会造成什么样的灾难吗？所处的反馈环越短，程序员工作得越好。比如编写一个新函数、编译；添加测试代码、编译；重构一些代码、编译。这样的话，我们可以在生成代码后，尽快发现并修复错别字和错误，我们希望每完成一小步都使用编译器，有些开发环境甚至可以在我们敲代码时自动编译我们的代码，这就是我们保持高代码质量，以及确保我们的软件逐渐向好发展的方法。当下针对技术生产力的DevOps哲学明确提出了以下目标：尽早获得反馈，尽早测试，并尽早考虑安全和生产环境。这一切都固定在开发流程的“左移”理念中，越早发现问题，修复它的成本就越低。

不仅是代码级别，整个项目级别都需要这样的快速反馈环。雄心勃勃的项目发展迅速，必须适应不断变化的环境，比如遇到不可预测的设计阻碍或政治风险，又比如只是没有按计划进行或者需求发生意外变化。你如何获得反馈环，以便你立即知道需要更改你的计划或设计？答案是：通过团队合作。大多数工程师都知道这句话，“人一多，Bug自然而然就冒出来了。”，但更好的一句话是，“人多起来，项目就好起来了。” 在洞穴中工作的人们醒来后发现，虽然他们最初的愿景可能已经完成，但世界已经改变，他们的项目变得无关紧要。

案例分析: 工程师和办公室

25年前，传统观点认为工程师要想提高工作效率，他们需要有自己的办公室，办公室的门是关着的。这应该是他们能够拥有大量不间断的时间，专注于编写大量代码的唯一方法。我认为，大多数工程师不仅没有必要呆在独立办公室里，而且非常危险。在当下，软件是由团队而不是个人编写的，与团队其他成员的高带宽、随时可用的连接，比你和互联网的连接更有价值。你可以拥有所有不受干扰的时间，但如果你用它来做错误的事情，你就是在浪费时间。

不幸的是，现代科技公司（在某些情况下也包括谷歌）似乎已经走向了了另一个极端。走进他们的办公室，你经常会发现工程师们聚集在巨大的房间里——一百或更多人在一起——没有任何墙壁。这种“开放式平面图”在当下引起很大争议，结果是对开放式办公室的敌意逐步上升。毕竟最轻声细语的谈话都会被听到，人们最终不再说话，因为不想冒着惹恼几十个邻居的风险。这和独立办公室一样糟糕！

我们认为折中的解决方案确实是最好的。在小房间（或大办公室）中将4到8人的团队分组在一起，以便轻松（且不尴尬）地随意对话。

当然，不管是哪一种情况，单个工程师仍然需要一种方法来屏蔽噪音和干扰。正是因为这个原因，我见过的大多数团队都使用一些方法来表示他们目前很忙，我们应该尽量少去打扰。我们中的一些人待过有“声音中断协议”的团队：如果你想说话，你会说“中断玛丽”，其中玛丽是你想对话的人的名字。如果玛丽到了可以停下来的时候，她会转过椅子来听一听。如果玛丽太忙，她只会说“收到”，然后你继续做其他事情，直到玛丽退出当下的工作状态。

还有一些团队用的是吉祥物或毛绒动物玩具，他们会放在显示器上，以代表只有在紧急情况下才可以打扰他们。还有一些团队向工程师提供降噪耳机，以便更轻松地处理背景噪音——事实上，在许多公司中，戴耳机的行为本身就是一个常见的信号，意思是“不要打扰我，除非它真的很重要”。 许多工程师在编码时喜欢进入耳机隔离模式，这有助于短时间的提高效率，但如果一直这么做，则好像在办公室中把自己隔离了起来，这样不利于协作。

不要误会——我们仍然认为工程师需要不间断的时间来专注于编写代码，但我们同样认为他们需要与团队建立高带宽、低摩擦的连接。如果你团队中的新手觉得向你提问有障碍，那就有问题了，因此，找到正确的平衡是一门艺术。

简而言之，不要隐藏

所以，“隐藏”问题归结为：独自工作的风险大于和他人合作的风险。你可能害怕的是有人窃取你的想法或认为你不聪明，其实你更应该担心在错误的事上浪费大量时间。

不要成为另一个失败案例。

关于团队的那些事

现在我们来汇总下以上的所有观点。

我们一直在强调的一点是，在编程领域，孤独的工匠是极其罕见的——即使他们确实存在，他们的天才般的成就也不是凭空做出来的，而几乎总是源于灵感的火花以及之后英勇团队的努力。

一个优秀的团队会巧妙地利用他们的超级巨星，产生的总体效应总是大于局部效应之和。但是打造一支超级团队是极其困难的。

用更简单的话来说就是，软件工程是需要团队共同努力的。

这个道理和我们很多人内心中的天才程序员幻想相悖，但独处在自己的黑客巢穴中是不够明智的。你无法通过隐藏起来准备你的秘密发明，来改变世界或取悦数以百万计的电脑用户。你需要和他人共事，分享你的创意，分工合作，向他人学习，打造优秀的团队。

想一下，你能说出多少个，真正由一个人编写的得到广泛使用的成功软件？ （有些人可能会说“LaTeX”，但它很难“广泛使用”，除非你认为写科学论文的人在所有电脑用户中占一大部分！）

高效能的团队是金子，是成功的真正关键。你应该尽可能地追求这种体验。

社交的三大支柱

既然团队合作是制作优秀软件的最佳途径，那如何建立（或找到）一个优秀的团队呢？

要达到协作的最佳效果，你首先需要学习并接受三个原则，我称之为社交的“三大支柱”。这三个原则不仅仅是人际关系的润滑剂，更是所有高质量互动和协作的基础：

支柱 1：谦逊 你不是宇宙的中心（你的代码也不是！），你既不是无所不知也不是万无一失的。你愿意不断自我提升。

支柱 2：尊重 你真诚地关心与你共事的其他人。你善待他们，欣赏他们的能力和成果。

支柱 3：信任 你相信其他人有能力并且会做正确的事情，而且你愿意在适当的时候让他们来带头。

如果你对近乎所有的社交冲突进行根本性分析，你最终都可以将其归结为缺乏谦逊、尊重和信任。乍一听，这可能令人难以置信，但可以尝试一下。想想你目前生活中的某个令人讨厌或不舒服的社交场景，从根本上看，每个人都适当的谦虚吗？人们真的互相尊重吗？有没有相互信任？

为什么这些支柱很重要？

当你开始阅读本章时，你可能并不打算加入某种周末互助小组。我们感同身受，处理社交问题可能会遇到困难：人是麻烦的、不可预测的，与他们打交道经常很烦人。与其花精力分析社交问题和采取战略行动，不如什么都不做。和编译器交流要容易得多，不是吗？毕竟编译器的结果是可预测的。为什么要费心社交呢？

以下引自理查德·汉明 (Richard Hamming) 著名演讲：

我不厌其烦地给秘书讲笑话并表现友好点，也因此得到了秘书的出色帮助。例如，有一次，因为某种愚蠢的原因，Murray Hill的所有复制服务都绑在一起了。不要问我为什么，但事实就是如此。而我想要完成某件任务，我的秘书打电话给Holmdel的某个人，然后跳上他们公司的车，经过长达一小时的旅行后恢复了服务，然后又回来了。我之前努力让她振作起来，给她讲笑话并保持友好，这件事是给我的一种回报，正是这些额外的一点工作为我带来了回报。你要意识到必须使用系统，研究如何让系统完成你的工作，还要学习如何让系统适应你的需求。

这个道理便是不要低估玩社交游戏的力量。这不是说要欺骗或操纵人们，这指的是建立社交关系来完成工作，关系总是比项目更持久。当你与同事建立更多的连接时，他们会更愿意在你需要时帮助你更多。

谦逊、尊重和信任的实践 上面讲的关于谦逊、尊重和信任的道理听起来像是在传教，现在我们跳出来想一下，如何将这些道理应用到现实当中。

首先，我们检查一些特定的行为和案例，这些行为乍听起来很明显有问题，但是仔细想一下后你会发现，你和你的同事有多少次后悔没有遵循这些原则 — 我们自己也注意到了这一点。

放下自尊心

好吧，这是一种更简单的方式来告诉没有足够谦逊的人失去他们的“tude”。没有人愿意与始终表现得像房间里最重要的人一样的人一起工作。即使你知道自己是讨论中最聪明的人，也不要当着人们的面挥手。例如，你是否总是觉得你需要在每个主题上说出第一个词或最后一个词？您是否觉得有必要对提案或讨论中的每一个细节发表评论？或者你认识做这些事情的人吗？

尽管谦虚很重要，但这并不意味着您需要成为门垫；自信没有错。只是不要像一个无所不知的人一样。

更好的是，考虑去追求“集体”自我；与其担心你个人是否出色，不如试着建立一种团队成就感和集体自豪感。例如，Apache 软件基金会在围绕软件项目创建社区方面有着悠久的历史。这些社区具有令人难以置信的强烈认同感，并拒绝那些更关心自我推销的人。

自我以多种方式表现出来，而且很多时候，它会妨碍你的工作效率并减慢你的速度。这是 Hamming 讲座中的另一个精彩故事，完美地说明了这一点（强调我们的）：