本章核心觀點#

這是一本關於軟體開發中社交挑戰的書，而你唯一能確實掌控的變數就是你自己。在理解同事的問題之前，你需要先理解自己的問題。本章的關鍵訊息是：軟體開發是一項團隊運動，要在工程團隊中成功，你必須圍繞謙遜、尊重與信任這三大核心原則來調整自己的行為。

天才程式設計師的迷思#

程式設計師天生有一種崇拜偶像的本能。我們崇拜 Linus Torvalds、Richard Stallman、Bill Gates 這些英雄，認為他們以一己之力改變了世界。Linus 獨自寫出了 Linux，對嗎？

事實並非如此。 Linus 只是寫了一個類 Unix 核心的概念驗證，然後分享到郵件列表上。這固然是了不起的成就，但只是冰山一角。Linux 的規模是原始版本的數百倍，由數百位優秀的工程師共同開發。Linus 真正的成就在於領導這些人並協調他們的工作。

同樣的模式反覆出現：

• Richard Stallman 撰寫了第一代 Emacs，但 bash、GCC 工具鏈以及其餘在 Linux 上運行的軟體，都是數百人的貢獻
• Steve Jobs 領導的是打造 Macintosh 的整個團隊
• Bill Gates 雖因撰寫 BASIC 直譯器聞名，但更大的成就是建立一間成功的公司
• Michael Jordan 的真正天才在於他與團隊合作的方式，而非獨自贏得每場比賽

他們都成為了集體成就的領袖與象徵。

天才迷思其實是不安全感的另一面。大多數程式設計師害怕分享剛起步的工作，因為同儕會看到自己的錯誤，知道程式碼的作者並非天才。

為什麼要隱藏程式碼？#

作者在 Google 推出開源專案託管服務後，收到了大量類似的請求：

• 「能不能讓 Subversion 隱藏特定分支？」
• 「能不能建立先隱藏、準備好再公開的開源專案？」
• 「我想從頭重寫程式碼，能不能清除所有歷史記錄？」

這些請求背後的共同主題是不安全感（insecurity）。人們害怕別人看到自己進行中的工作並加以批判。這是人性的一部分——沒有人喜歡被批評未完成的東西。

隱藏程式碼的另一個動機是恐懼：擔心其他程式設計師會偷走你的想法，搶先實作。透過保密，你覺得自己掌控了這個點子。

隱藏是有害的#

獨自工作實際上會增加失敗的風險，並剝奪你的成長潛力：

• 你可能走錯方向 —— 如果將想法藏起來、拒絕在實作完善前展示給任何人看，你是在冒巨大的賭注。很容易在早期犯下根本性的設計錯誤
• 重複造輪子的風險 —— 你可能在不知情的情況下重複別人的工作
• 失去協作加速 —— 注意你的鄰居與朋友合作時進展有多快
• Bus factor 降低 —— 如果你是唯一理解原型程式碼的人，你被公車撞到的那天，專案就完了

獨自工作本質上比與他人合作更具風險。比起擔心別人偷走你的想法或覺得你笨，你更應該擔心浪費大量時間在錯誤的方向上辛苦耕耘。

Bus Factor#

Bus factor（公車因子）的定義：在你的專案徹底完蛋之前，需要被公車撞到的人數。

• 如果你是唯一理解程式碼的人，bus factor 就是 1
• 與一位朋友合作，bus factor 翻倍
• 小型團隊一起設計與開發原型，情況更好——即使有成員離開，專案也不會結束

團隊成員不一定要被公車撞到——結婚、搬家、離職、照顧生病的親人，這些都是現實中會發生的事。你需要透過管理 bus factor 來為專案的未來做好準備。

快速回饋的價值#

作者用編譯器做比喻：身為程式設計師，我們在緊密的回饋迴圈中工作效果最好——寫一個函式、編譯、加一個測試、編譯。我們不會寫五萬行程式碼再按下編譯按鈕。

同樣的快速回饋迴圈不只適用於程式碼層級，也適用於整個專案：

• 專案會遇到不可預期的設計障礙、政治障礙
• 需求會意外地改變
• 在團隊中工作能讓你在計畫或設計需要改變時立即獲得回饋

Eric Raymond 常被引用的名言「眾目之下，所有 bug 都無所遁形」，更好的版本應該是：「眾目之下，能確保你的專案保持在正確方向上。」

一切都關乎團隊#

在程式設計領域，獨行俠式的工匠極為罕見。即使他們真的存在，他們改變世界的成就也幾乎總是「一點靈感火花加上英雄式團隊努力」的結果。

軟體開發是一項團隊運動。 把這句話當成口號反覆唸誦。光靠自己在駭客密室裡出類拔萃是不夠的。你需要與他人合作、分享願景、分擔工作、向他人學習，創造一個出色的團隊。

打造一支超級明星團隊才是真正的目標。最好的團隊善用每位成員的優勢，整體永遠大於部分之和。

HRT 三大支柱#

如果團隊合作是生產偉大軟體的最佳途徑，那麼如何建立或找到一個好團隊？你首先需要學習並擁抱三大社交技能支柱：

Humility（謙遜）#

你不是宇宙的中心。你既非全知也非永遠正確。你對自我提升持開放態度。

Respect（尊重）#

你真心在乎與你共事的人。你把他們當作有血有肉的人看待，欣賞他們的能力與成就。

Trust（信任）#

你相信他人是有能力的，會做正確的事。你願意在適當的時候讓他們主導。

這三個原則合稱為 HRT，發音為「heart」（心）而非「hurt」（傷害），因為重點在於減少痛苦而非造成傷害。

幾乎所有社交衝突最終都能追溯到缺乏謙遜、尊重或信任。回想你生活中任何糟糕或不舒服的社交情境——最根本的層面上，是否每個人都表現得恰當地謙遜？人們是否真的彼此尊重？是否存在相互的信任？

實踐 HRT#

放下自我#

這是用更簡單的方式在說：展現足夠的謙遜。沒有人想和一個總是表現得自己是房間裡最重要的人共事。即使你知道自己是討論中最聰明的人，也不要炫耀。

實踐建議：

• 不要總覺得自己需要在每個話題上搶先或搶最後一句話
• 不要覺得需要對每個提案或討論中的每個細節發表評論
• 追求集體自尊而非個人光環——建立團隊成就感與團體榮譽感
• Apache 軟體基金會就有悠久的以社群為核心的傳統，這些社群擁有強烈的認同感，並拒絕那些更關心自我宣傳的人

「謙遜」不等於當個受氣包。自信沒有問題，但不要表現得像個萬事通。用「集體自尊」取代個人自尊。

學會給予和接受批評#

批評在專業軟體工程環境中幾乎從來不是針對個人的——它只是打造更好產品的過程的一部分。關鍵是區分：

• 建設性批評：針對他人的創作產出，旨在幫助改進
• 人身攻擊：針對某人的人格，幾乎不可能據此改善

給予批評時要帶著尊重：真心在乎對方，希望幫助他們進步。學會用委婉但有建設性的措辭。

例如，不要這樣說：

「你的控制流程完全搞錯了。你應該用標準的 xyzzy 模式。」

應該這樣說：

「我對這段程式碼的控制流程有些困惑。我在想 xyzzy 模式是不是能讓這裡更清楚、更容易維護？」

接受批評時，要記住一個核心觀念：

你不等於你的程式碼。 反覆告訴自己這句話。程式設計是一項技能，會隨著練習進步。如果同儕指出你的程式碼可以改進的地方，不要把它當作對你人格和價值的攻擊。

快速失敗、學習、迭代#

Google 最喜歡的座右銘之一是「失敗是一種選項」。如果你從不失敗，那代表你不夠創新或沒有承擔足夠的風險。失敗被視為學習和改進的黃金機會。

從錯誤中學習的關鍵是記錄你的失敗。撰寫「事後分析報告」（postmortem），一份好的報告應包含：

• 事件簡要摘要
• 從發現到調查到解決的時間線
• 事件的根本原因
• 影響與損害評估
• 立即修復問題的行動項目
• 防止事件再次發生的行動項目
• 學到的教訓

留出學習時間#

書中提到一位名叫 Cindy 的超級明星工程師。她精通自己的專業領域，晉升為技術負責人，指導所有人，在研討會上發表演講。然而她最終開始感到無聊，因為她停止學習新東西了。當某天她意識到自己的領域已經不再那麼相關時，才發現人們早已轉向其他議題。

教訓是：一旦你在團隊中達到了局部最大值，就會停止學習。而當你停止學習，你就會變得過時。要增加謙遜，願意學習也願意教導。讓自己離開舒適圈，去更大的池塘裡和更大的魚一起游。

學習耐心#

作者分享了 Fitz 和 Karl 一起做 pair programming 的故事。Fitz 是自下而上的工程師，喜歡快速深入細節；Karl 是自上而下的工程師，想先了解全貌再行動。這導致了衝突與分歧。最終靠著大量的 HRT——努力、專注以及不少的謙遜、尊重和信任——他們不僅拯救了專案，也拯救了友誼。

對影響保持開放#

你越願意被影響，你就越能影響他人；你越展現脆弱，你就顯得越強大。這些聽起來矛盾，但確實如此。

每個人都能想到一個固執到令人抓狂的人——無論別人怎麼說，他都不為所動。這種人最終會被「繞過」，人們不再聽取他的意見。

實踐要點：

• 願意改變想法 —— 記住：要被聽到，你首先要學會傾聽
• 選擇你的戰場 —— 不是每件事都值得堅持
• 在表態之前先傾聽 —— 如果你不斷改變立場，別人會覺得你搖擺不定；但在你下定決心之前，應該認真聆聽

關於脆弱的議題：承認自己犯了錯或不懂某件事，長期來看實際上會提升你的地位。這體現了 HRT 的全部精神——展示謙遜、承擔責任、信任他人的意見，最終獲得他人的尊重。

有時候你能做的最好的事就是說：「我不知道。」誠實和謙遜不是弱點——你的隊友是合作者，不是競爭者。

本章小結#

本章的核心訊息是讓你開始檢視和反思自己的行為。一旦你將 HRT 的策略融入日常生活，你會發現協作變得更加自然，工程生產力也會明顯提升。重要的改變從你自身開始，然後向外擴散到他人。