假如你一直都是单打独斗的话，你其实是增加了自己失败的风险，而且浪费了自己成长的可能性。 首先，你怎么知道自己选的路是对的？ 假设你是一名狂热的自行车设计师，有一天你想到了一个绝妙的主意，设计出一个具有颠覆性的换挡装置。你订购了零件，然后在车库里泡了好几个星期来制作原型。当你的邻居（他也是自行车爱好者）问你最近在忙什么的时候，你想还是先保密好了。在这个设计完善之前，你不想任何人知道它的存在。几个月以后，你遇到了瓶颈，没有办法令原型正常工作，但由于这个项目是保密的，所以也没办法向你的机械师朋友们寻求帮助。 直到有一天，你的邻居从他的车库里推出一辆自行车，上面有一个全新设计的换挡装置。其实他也一直在建造一个和你的设计类似的东西，只不过他有自行车行的朋友帮他的忙。这时你一定非常窝火吧。你把自己的东西拿给他看，他立刻就指出了你在设计上存在的缺陷——要是你早点拿出来的话，搞不好这些缺陷在一开始就修复了。  单打独斗的结果往往令人失望 这里我们可以得到好几个教训。真正做出产品之前不愿分享好创意实际上是一场很大的赌博，你很容易在一开始就犯下很基本的错误，你有可能是在重新发明轮子² 。还有你完全丧失了合作的好处。注意到你的邻居和别人合作后进展有多快了吗？这正是为什么人们在跳进泳池前会拿脚趾试试水的原因：你需要确定自己在做的事情是对的，方法也是对的，而且不是重复劳动。一开始就踏错步的概率总是很高的，越早征求意见和反馈，就越能把风险降低³。记住这句久经考验的原则——“确保失败尽早发生，尽快发生，经常发生”——我们会在本书稍后详细讨论失败的重要性。 尽早分享不仅仅可以防止一开始就步入歧途和检验创意，它还可以强化所谓的“公车因子”。 公车因子（名词）：一个项目里，需要有多少人被公车撞到才能令其完全瘫痪。  你的团队的公车因子是多少 你的项目里知识的分散程度是多少？假如只有你一个人理解原型代码是怎么工作的，那么或许对你的职位的安全程度来说是很高，但要是你被车撞了的话，对项目本身来说就是灭顶之灾了。但如果有一个朋友和你合作的话，公车因子就可以翻倍。要是有一个小组一起设计制作原型的话就更好了——项目不会因为某位成员的消失而完蛋。记住：这里只是比喻，并非真的是被车撞，而是指任何生活中都会发生的意外情况，比如结婚、搬家、离职或是照顾生病的家人等。你若想要确保项目有一个光明的前景，就一定要把公车因子纳入考量。 除了公车因子之外，还有整体进展的速度。人们往往会忘记单独工作通常都是很艰辛的，进展有时会慢得令人难以接受。独自工作能让你学到多少东西？你的进展如何？网络虽然是观点和信息的大熔炉，但是它是替代不了人与人之间真正的交流的。直接和别人一起工作能潜移默化地提升集体智慧。每次遇到事后觉得可笑的障碍时，你浪费了多少时间才走出死胡同？想想如果有同事在旁边帮你一把的话会有什么不同——他们会立刻指出你哪里弄错了，该怎么解决它。这就是软件公司里团队通常都是坐在一起（或是在一起结对编程）的原因：你需要一位旁观者。 再打一个比方。想想你是怎么用编译器的。当你编译一个有一定规模的软件的时候，你会花好几天甚至好几个星期坐在那里写代码，然后在全部写完确保一切完美后才第一次进行编译么？肯定不会啦。你能想象一口气编译50 000行代码会有什么后果么？程序员是最需要不断反馈的：写一个新函数，编译，加了一个测试用例，再编译一下，又重构了一部分代码，再编译一下。这样就能在生成代码的时候尽快地改正笔误和 bug。我们的每一步都离不开编译器，好像僚机一样。有些开发环境甚至能在我们打字的同时进行编译。正是依靠这种方式我们才能保持高质量的代码并确保软件在正确的轨道上演化。 这种快速反馈不仅在代码层面，对整个项目来说也是必不可少的。有抱负的项目都必须快速演化并不断适应环境的变化。项目可能会遇到意料之外的设计瓶颈，或者行政上的阻力，又或者只是发现事与愿违。需求总是在往意想不到的方向变化。你要如何通过反馈来发现自己的计划和设计中需要修改的地方？答案是：团队合作。埃里克·雷蒙说过，“只要有足够多双眼睛，就能发现所有的bug，”而更好的说法是，“足够多双眼睛可以确保你的项目保持正确的方向。”闭门造车的结果往往是当实现最初的创意后，却发现世界已经完全改变，原本的产品已经失去意义了。 ### 工程师和办公室 20 年前的传统看法是工程师需要自己独立的办公室，关上门安静工作才会有生产力。这样才能保证他有大把不受干扰的时间可以专心编程。 而我们却认为把绝大多数工程师 ⁴ 关在独立办公室里不但毫无必要而且还很危险。今时今日，软件业已经不是个人英雄的行业了，它需要团队的合作，保持沟通渠道的通畅甚至比随时在线的网络连接更重要。虽然得到了不受干扰的环境，但如果方向错了，那也只是在浪费时间罢了。走进任何一家21世纪以来创建的、快速成长的高科技公司，你会发现工程师都是围坐在共享的小格间（也叫“牛棚”）里，或是共用一张桌子，很少见到各自把自己锁在办公室里的情况。 当然啦，你还是需要找到办法来过滤杂音和干扰的，我们发现很多团队因此发展出一套自己的沟通技巧来表达自己现在很忙，有事等会再说。以前和我们合作过的一支团队就有这样一套语音中断协议：假如你有事找玛丽谈，你要说，“breakpoint 玛丽”。如果玛丽正好有空档可以停下来，她就会转过来和你谈。要是她正在忙，她会说“ack”表示知道了，然后你就先去忙其他事情吧，她那边忙完了就会来找你。 有些团队会给工程师发降噪耳机来解决背景噪音的问题——事实上在很多公司里，带着耳机实际上就表示“不是重要的事情就别烦我”。另外一些团队则会用在显示器上放置记号和玩具的办法来表示自己不愿被打扰。 请别误解我们——我们完全认同工程师应该有不受干扰的时间来全情投入编码之中，但是我们认为他们更需要团队之间高效通畅的沟通渠道。 因此用一句话来总结就是：本质上，单打独斗比合作风险更高。相比担心自己的创意被偷走或是被人笑话，你更应该担心自己是不是在错误的方向上浪费了大量时间。 令人遗憾的是，这种“创意要保密”的想法并非软件行业独有的，所有领域都普遍存在这个问题。就拿学术界来说，科学原本应该是自由开放、信息共享的。但是“不发表即灭亡”的迫切需求，以及对基金拨款的竞争却造成了反效果。学者们不再乐于分享。他们小心翼翼地保护着自己的想法，秘密地进行研究，把犯过的错误都掩盖起来，使最终发表的论文看起来似乎得来全不费功夫一般。其结果往往都是灾难性的：要么不小心重复了前人的工作，要么在一开始就不知不觉犯下了错误，最糟糕的是创造了一些原本有趣，但现在完全过时无用的东西。其中浪费的时间和精力都是无法估量的。 别再把自己变成上述统计结果的一部分。