假如你一直都是單打獨斗的話，你其實是增加了自己失敗的風險，而且浪費了自己成長的可能性。 首先，你怎么知道自己選的路是對的？ 假設你是一名狂熱的自行車設計師，有一天你想到了一個絕妙的主意，設計出一個具有顛覆性的換擋裝置。你訂購了零件，然后在車庫里泡了好幾個星期來制作原型。當你的鄰居（他也是自行車愛好者）問你最近在忙什么的時候，你想還是先保密好了。在這個設計完善之前，你不想任何人知道它的存在。幾個月以后，你遇到了瓶頸，沒有辦法令原型正常工作，但由于這個項目是保密的，所以也沒辦法向你的機械師朋友們尋求幫助。 直到有一天，你的鄰居從他的車庫里推出一輛自行車，上面有一個全新設計的換擋裝置。其實他也一直在建造一個和你的設計類似的東西，只不過他有自行車行的朋友幫他的忙。這時你一定非常窩火吧。你把自己的東西拿給他看，他立刻就指出了你在設計上存在的缺陷——要是你早點拿出來的話，搞不好這些缺陷在一開始就修復了。  單打獨斗的結果往往令人失望 這里我們可以得到好幾個教訓。真正做出產品之前不愿分享好創意實際上是一場很大的賭博，你很容易在一開始就犯下很基本的錯誤，你有可能是在重新發明輪子² 。還有你完全喪失了合作的好處。注意到你的鄰居和別人合作后進展有多快了嗎？這正是為什么人們在跳進泳池前會拿腳趾試試水的原因：你需要確定自己在做的事情是對的，方法也是對的，而且不是重復勞動。一開始就踏錯步的概率總是很高的，越早征求意見和反饋，就越能把風險降低³。記住這句久經考驗的原則——“確保失敗盡早發生，盡快發生，經常發生”——我們會在本書稍后詳細討論失敗的重要性。 盡早分享不僅僅可以防止一開始就步入歧途和檢驗創意，它還可以強化所謂的“公車因子”。 公車因子（名詞）：一個項目里，需要有多少人被公車撞到才能令其完全癱瘓。  你的團隊的公車因子是多少 你的項目里知識的分散程度是多少？假如只有你一個人理解原型代碼是怎么工作的，那么或許對你的職位的安全程度來說是很高，但要是你被車撞了的話，對項目本身來說就是滅頂之災了。但如果有一個朋友和你合作的話，公車因子就可以翻倍。要是有一個小組一起設計制作原型的話就更好了——項目不會因為某位成員的消失而完蛋。記住：這里只是比喻，并非真的是被車撞，而是指任何生活中都會發生的意外情況，比如結婚、搬家、離職或是照顧生病的家人等。你若想要確保項目有一個光明的前景，就一定要把公車因子納入考量。 除了公車因子之外，還有整體進展的速度。人們往往會忘記單獨工作通常都是很艱辛的，進展有時會慢得令人難以接受。獨自工作能讓你學到多少東西？你的進展如何？網絡雖然是觀點和信息的大熔爐，但是它是替代不了人與人之間真正的交流的。直接和別人一起工作能潛移默化地提升集體智慧。每次遇到事后覺得可笑的障礙時，你浪費了多少時間才走出死胡同？想想如果有同事在旁邊幫你一把的話會有什么不同——他們會立刻指出你哪里弄錯了，該怎么解決它。這就是軟件公司里團隊通常都是坐在一起（或是在一起結對編程）的原因：你需要一位旁觀者。 再打一個比方。想想你是怎么用編譯器的。當你編譯一個有一定規模的軟件的時候，你會花好幾天甚至好幾個星期坐在那里寫代碼，然后在全部寫完確保一切完美后才第一次進行編譯么？肯定不會啦。你能想象一口氣編譯50 000行代碼會有什么后果么？程序員是最需要不斷反饋的：寫一個新函數，編譯，加了一個測試用例，再編譯一下，又重構了一部分代碼，再編譯一下。這樣就能在生成代碼的時候盡快地改正筆誤和 bug。我們的每一步都離不開編譯器，好像僚機一樣。有些開發環境甚至能在我們打字的同時進行編譯。正是依靠這種方式我們才能保持高質量的代碼并確保軟件在正確的軌道上演化。 這種快速反饋不僅在代碼層面，對整個項目來說也是必不可少的。有抱負的項目都必須快速演化并不斷適應環境的變化。項目可能會遇到意料之外的設計瓶頸，或者行政上的阻力，又或者只是發現事與愿違。需求總是在往意想不到的方向變化。你要如何通過反饋來發現自己的計劃和設計中需要修改的地方？答案是：團隊合作。埃里克·雷蒙說過，“只要有足夠多雙眼睛，就能發現所有的bug，”而更好的說法是，“足夠多雙眼睛可以確保你的項目保持正確的方向。”閉門造車的結果往往是當實現最初的創意后，卻發現世界已經完全改變，原本的產品已經失去意義了。 ### 工程師和辦公室 20 年前的傳統看法是工程師需要自己獨立的辦公室，關上門安靜工作才會有生產力。這樣才能保證他有大把不受干擾的時間可以專心編程。 而我們卻認為把絕大多數工程師 ⁴ 關在獨立辦公室里不但毫無必要而且還很危險。今時今日，軟件業已經不是個人英雄的行業了，它需要團隊的合作，保持溝通渠道的通暢甚至比隨時在線的網絡連接更重要。雖然得到了不受干擾的環境，但如果方向錯了，那也只是在浪費時間罷了。走進任何一家21世紀以來創建的、快速成長的高科技公司，你會發現工程師都是圍坐在共享的小格間（也叫“牛棚”）里，或是共用一張桌子，很少見到各自把自己鎖在辦公室里的情況。 當然啦，你還是需要找到辦法來過濾雜音和干擾的，我們發現很多團隊因此發展出一套自己的溝通技巧來表達自己現在很忙，有事等會再說。以前和我們合作過的一支團隊就有這樣一套語音中斷協議：假如你有事找瑪麗談，你要說，“breakpoint 瑪麗”。如果瑪麗正好有空檔可以停下來，她就會轉過來和你談。要是她正在忙，她會說“ack”表示知道了，然后你就先去忙其他事情吧，她那邊忙完了就會來找你。 有些團隊會給工程師發降噪耳機來解決背景噪音的問題——事實上在很多公司里，帶著耳機實際上就表示“不是重要的事情就別煩我”。另外一些團隊則會用在顯示器上放置記號和玩具的辦法來表示自己不愿被打擾。 請別誤解我們——我們完全認同工程師應該有不受干擾的時間來全情投入編碼之中，但是我們認為他們更需要團隊之間高效通暢的溝通渠道。 因此用一句話來總結就是：本質上，單打獨斗比合作風險更高。相比擔心自己的創意被偷走或是被人笑話，你更應該擔心自己是不是在錯誤的方向上浪費了大量時間。 令人遺憾的是，這種“創意要保密”的想法并非軟件行業獨有的，所有領域都普遍存在這個問題。就拿學術界來說，科學原本應該是自由開放、信息共享的。但是“不發表即滅亡”的迫切需求，以及對基金撥款的競爭卻造成了反效果。學者們不再樂于分享。他們小心翼翼地保護著自己的想法，秘密地進行研究，把犯過的錯誤都掩蓋起來，使最終發表的論文看起來似乎得來全不費功夫一般。其結果往往都是災難性的：要么不小心重復了前人的工作，要么在一開始就不知不覺犯下了錯誤，最糟糕的是創造了一些原本有趣，但現在完全過時無用的東西。其中浪費的時間和精力都是無法估量的。 別再把自己變成上述統計結果的一部分。