總覽#
本章聚焦於軟體工程中最根本卻常被忽視的變數——人。軟體開發是一項團隊事業，而非個人英雄主義的舞台。要在工程團隊中成功，你需要圍繞三大核心原則重新組織自己的行為：謙遜（Humility）、尊重（Respect）、信任（Trust）。
作者從軟體工程師常見的「不安全感」出發，拆解了「天才迷思」的危害，說明隱藏工作的風險，最終提出以團隊為中心的社交互動三支柱，並給出大量可實踐的建議。
幫我藏住程式碼——工程師的不安全感#
Google 在 2006 年推出開源專案託管服務後，陸續收到許多類似的請求：
- 「能不能讓 Subversion 隱藏特定分支？」
- 「能不能建立一開始不公開、準備好才發佈的專案？」
- 「能不能清除所有歷史紀錄，讓我從頭來過？」
這些請求有一個共同的主題：不安全感（Insecurity）。人們害怕別人看到並評判他們尚未完成的作品。沒有人喜歡被批評，尤其是還沒完成的東西。然而，這種不安全感其實是一個更大問題的症狀。
天才迷思（The Genius Myth）#
我們為何崇拜英雄#
人類天生有尋找偶像並崇拜的本能。在軟體工程界，這些偶像可能是 Linus Torvalds、Guido van Rossum、Bill Gates——他們被視為以一己之力改變世界的英雄。
但事實是：
- Linus Torvalds 撰寫了最初的概念驗證（proof-of-concept）Unix-like kernel，但 Linux 是由數千位聰明的開發者共同打造的。Linus 真正的成就在於領導與協調這些人的工作。
- Guido van Rossum 寫了 Python 的第一個版本，但數百人貢獻了後續版本的想法、功能與修復。
- Steve Jobs 率領了一整個團隊打造 Macintosh。Bill Gates 更大的成就是圍繞 MS-DOS 建立了一家成功企業。
- Michael Jordan 的真正天才在於他與團隊合作的方式。教練 Phil Jackson 組建了一支圍繞 MJ 的「夢幻隊」，這支隊伍本身就和 Jordan 一樣令人印象深刻。
天才迷思（Genius Myth）是人類傾向於將團隊的成功歸功於單一個人或領導者的現象。
天才幻想的陷阱#
許多工程師內心深處渴望被視為天才，幻想著這樣的劇本：
- 你被一個絕妙的新概念擊中
- 你躲進洞穴裡花數週或數月打造完美實作
- 你向世界「釋出」你的軟體，令所有人震驚
- 同儕驚嘆於你的聰明才智
- 名聲與財富隨之而來
現實是：即使你是天才，這也不夠。天才仍會犯錯，擁有出色的程式設計技巧並不保證你的軟體會成功。更糟的是，你可能只解決了分析性問題，卻無法解決人的問題。
Google（以及大多數公司）的絕大多數工作不需要天才級的智力，但 100% 的工作需要基本的社交能力。決定你職涯成敗的，是你與他人協作的能力。
不安全感驅動隱藏行為#
天才迷思本質上是不安全感的另一種表現。程式設計師害怕分享剛起步的工作，因為這意味著同儕會看到錯誤，並知道程式碼的作者不是天才。於是自然反應就是：
- 躲進洞穴，工作、工作、工作，然後打磨、打磨、打磨
- 直到程式碼完美才敢亮相
- 或者害怕別人搶先實現自己的點子，所以選擇保密
隱藏的危害（Hiding Considered Harmful）#
如果你把所有時間都花在獨自工作上，你正在增加不必要的失敗風險，並且浪費成長的潛力。即便軟體開發需要深度專注和獨處時間，你必須在此與協作、審查的價值之間取得平衡。
及早發現問題（Early Detection）#
作者用一個自行車設計的比喻說明：如果你把絕妙的點子藏起來，獨自花數月打造原型，結果鄰居在朋友的幫助下更快完成了類似的設計，而你的設計有著在第一週就能被指出的簡單缺陷。
隱藏工作的核心風險：
- 容易在早期犯下根本性的設計錯誤
- 可能重新發明輪子
- 錯過協作帶來的加速效果
牢記經過驗證的格言：「儘早失敗、快速失敗、經常失敗」（Fail early, fail fast, fail often）。越早徵求回饋，越能降低走錯方向的風險。
巴士因子（Bus Factor）#
巴士因子（Bus Factor）的定義：
需要多少人被巴士撞到，你的專案才會完全失敗。
- 如果你是唯一了解原型程式碼的人，你也許享有良好的工作保障——但如果你被巴士撞了，專案就完了。
- 與同事合作可以將巴士因子加倍。
- 小型團隊一起設計和打造原型，情況更好。
團隊成員不會真的被巴士撞到，但不可預測的生活事件確實會發生：結婚、搬家、離職、照顧家人。確保每個職責領域至少有良好的文件，以及主要和次要負責人，才能為專案的未來做好準備。
成為成功專案的一份子，好過成為失敗專案的關鍵人物。
進度的速度（Pace of Progress）#
獨自工作往往比人們願意承認的還要慢得多。與他人合作能直接增加整體的集體智慧。
作者用編譯器做類比：程式設計師在緊密的回饋循環中工作效率最高——寫一個新函式、編譯；加一個測試、編譯；重構一些程式碼、編譯。這與現代 DevOps 理念中「左移（Shifting Left）」的概念一致：越早發現問題，修復的成本越低。
同樣的快速回饋循環不僅適用於程式碼層面，也適用於整個專案層面：
- 需求會意外地變化
- 專案會遭遇不可預見的設計障礙或政治風險
- 人們獨自在洞穴中工作，醒來後可能發現世界已經改變，專案已經變得無關緊要
「眾目睽睽之下，所有 bug 都無所遁形」（Many eyes make all bugs shallow）——更好的版本是：「眾目睽睽之下，確保你的專案保持相關且走在正軌上。」
案例研究：工程師與辦公空間#
關於工程師的工作環境，作者提出了一個平衡觀點：
- 25 年前的傳統智慧：工程師需要有門可關的獨立辦公室才能高效工作
- 現代科技公司的極端：開放式辦公空間，上百人擠在沒有牆壁的大房間——最小的對話都變成公開的，人們反而不敢交談
- 最佳的中間地帶：將 4-8 人的團隊分組在小房間（或大辦公室）中，讓自發的對話能輕鬆自然地發生
針對「不被打擾」的需求，團隊發展出各種協議：
- 語音中斷協議：「Breakpoint Mary」——如果 Mary 能停下來就轉過來聽，太忙就說「ack」
- 物理信號：在螢幕上放置代幣或布偶表示「緊急情況才打斷」
- 降噪耳機：戴耳機本身就是「非重要事情勿擾」的通用信號
工程師確實需要不被打擾的專注時間來寫程式碼，但同樣需要與團隊之間的高頻寬、低摩擦連線。如果知識較淺的團隊成員覺得向你提問有障礙，這就是一個問題——找到正確的平衡是一門藝術。
簡而言之：不要隱藏#
隱藏歸結為一件事：獨自工作本質上比與他人合作風險更高。即便你可能害怕有人偷走你的點子或覺得你不夠聰明，你更應該擔心的是把大量時間浪費在錯誤的事情上。
一切都關乎團隊#
在程式設計領域，獨行俠極其罕見——即使存在，他們的改變世界的成就幾乎總是靈感火花之後的英雄團隊努力的結果。
- 一個偉大的團隊善用其超級明星，但整體永遠大於各部分之和
- 軟體工程是一項團隊事業
- 你不可能通過躲藏和準備秘密發明來改變世界或取悅數百萬使用者
- 你需要與他人合作、分享願景、分配勞動、向他人學習
高效能團隊是無價之寶，也是成功的真正鑰匙。 你應該盡一切可能追求這樣的體驗。
社交互動的三支柱（The Three Pillars of Social Interaction）#
要達到協作的最佳境界，你首先需要學習和擁抱社交技能的「三支柱」。這三個原則不僅僅是潤滑人際關係的工具——它們是所有健康互動與協作的基礎：
支柱一：謙遜（Humility）#
你不是宇宙的中心（你的程式碼也不是！）。你既不是全知的也不是不會犯錯的。你對自我改善持開放態度。
支柱二：尊重（Respect）#
你真心關心與你共事的人。你善待他們，並欣賞他們的能力和成就。
支柱三：信任（Trust）#
你相信他人是有能力的，會做正確的事，並且在適當的時候你願意讓他們主導。
如果你對幾乎任何社交衝突進行根因分析（Root-Cause Analysis），最終都可以追溯到謙遜、尊重和／或信任的缺失。
為什麼這三支柱重要？#
Richard Hamming 在一場著名演講中分享了一個故事：透過花時間對秘書友善、講笑話，他獲得了出色的秘書支持。在一次緊急情況下，秘書主動驅車一小時到另一個辦公室幫他完成工作。
這個故事的寓意是：不要低估經營社交關係的力量。 這不是操控或欺騙——而是建立關係以完成事情。
- 關係總是比專案更持久
- 當你與同事有更豐富的關係時，他們在你需要時更願意多走一哩路
謙遜、尊重與信任的實踐#
放下自我（Lose the Ego）#
沒有人想和一個總是表現得自己是房間裡最重要的人共事。即使你知道自己是討論中最有智慧的人，也不要在別人面前炫耀。
自問：
- 你是否總覺得需要在每個議題上有第一個或最後一個發言？
- 你是否覺得需要對提案或討論中的每個細節發表評論？
謙遜不代表當門墊——自信沒有錯。但不要表現得像個萬事通。更好的做法是追求**「集體的自我」**：與其擔心自己是否傑出，不如建立團隊成就感和集體榮譽感。
Hamming 演講中的另一個故事說明了自我如何拖慢你的腳步：John Tukey 穿著隨意，導致他總要花很長時間才能讓人認真對待他。Hamming 的結論是：
「表面上的從眾能讓你走很遠。」 如果你選擇以各種方式堅持自我，你在整個職涯中都會持續付出微小的代價，而這些代價在一生中累積起來會是一筆巨大的不必要麻煩。
學會給予和接受批評#
一個關於「Joe」的故事：新工程師 Joe 出於好意，開始透過電子郵件發送程式碼審查，禮貌地詢問設計假設或指出邏輯可改進之處。幾週後，他被主管叫去辦公室——團隊成員投訴他行為苛刻。
問題不在於 Joe 做了什麼，而在於他沒有考慮到團隊的不安全感，應該使用更巧妙的方式引入程式碼審查文化。
在專業環境中，批評幾乎從來不是針對個人的——它通常只是打造更好專案的過程的一部分。關鍵是區分：
- 建設性批評：針對創作成果，出於真心關懷，帶有尊重，並提供改進指引
- 人身攻擊：針對性格的貶低，瑣碎且無法據以行動
反面示範：
「老兄，你那個方法的控制流程完全搞錯了。你應該像其他人一樣使用標準的 xyzzy 模式。」
這句話充滿反模式：告訴別人他們「錯了」、要求他們改變、暗示他們做的東西與眾不同（讓他們感到愚蠢）。
正面示範：
「嘿，我對這段的控制流程有點困惑。我在想 xyzzy 模式是不是可能讓這裡更清晰、更容易維護？」
這種說法的巧妙之處：
- 用謙遜讓問題關於你，而不是他們
- 他們沒有錯——你只是在理解程式碼上有困難
- 建議只是以一種方式提出，對方可以和平地拒絕
- 討論聚焦在程式碼本身，而非任何人的價值或技能
你不是你的程式碼。 反覆對自己說這句話。你的自我價值不應與你寫的程式碼或任何你建造的創意作品掛鉤。你需要自己相信，也要讓同事相信這一點。
快速失敗並迭代（Fail Fast and Iterate）#
一個廣為流傳的商業故事：一位經理犯了一個錯誤，損失了 1,000 萬美元。他準備辭職，但 CEO 說：「開除你？我剛花了 1,000 萬美元訓練你，為什麼要開除你？」
在 Google，最受歡迎的座右銘之一是：「失敗是一個選項」（Failure is an option）。如果你從來不失敗，代表你不夠創新或沒有承擔足夠的風險。失敗被視為學習和改進的黃金機會。
Google X（負責「登月計畫」如自駕車、氣球網路的部門）更是將失敗刻意納入激勵機制：
- 人們提出大膽的點子
- 同事被積極鼓勵盡快推翻這些點子
- 個人會被獎勵（甚至競賽）看誰能在固定時間內否證最多想法
- 只有在白板上經所有同儕無法推翻的概念，才會進入早期原型階段
無責事後分析文化（Blameless Post-Mortem Culture）#
從錯誤中學習的關鍵在於透過根因分析（Root-Cause Analysis）記錄失敗，撰寫事後分析報告（Postmortem）。
一份好的事後分析報告應包含：
- 事件的簡要摘要
- 從發現、調查到解決的事件時間線
- 事件的主要原因
- 影響與損害評估
- 一組立即修復問題的行動項目（含負責人）
- 一組防止事件再次發生的行動項目
- 學到的教訓
事後分析報告不應該是道歉、藉口或指責的清單。它的目的是記錄學到了什麼以及將因此改變什麼。確保報告可被輕易存取，且團隊確實執行了提出的改進措施。不要抹去你的足跡——把它們像跑道一樣照亮，給後來者指引方向。
學習耐心（Learn Patience）#
作者分享了與朋友 Karl 一起配對程式設計的經驗。兩人的風格截然不同：
- 作者是**由下而上（Bottom-up）**的工程師：喜歡快速嘗試、深入泥潭再挖出來
- Karl 是**由上而下（Top-down）**的工程師：想要全面了解整體狀況，深入研究每個方法的實作
這導致了嚴重的衝突和爭論。但因為他們有長期建立的信任與尊重基礎，加上耐心，他們找到了新的合作方式：一起坐下來確認 bug，然後分頭從兩個方向（由上而下和由下而上）攻克問題，最後再彙合結果。
耐心和願意即興創造新的工作方式，不僅拯救了專案，也拯救了友誼。
對影響持開放態度（Be Open to Influence）#
- 你越容易被影響，你就越能影響他人
- 你越展現脆弱，你看起來越強大
這聽起來矛盾，但想想那些固執到底的同事——無論別人如何說服，他們都越挖越深。最終的結果是：人們停止聽他們的意見，開始像繞過障礙物一樣「繞過」他們。
記住：讓別人改變你的想法是可以的。 工程本質上就是在做取捨（Trade-offs）。你不可能永遠都是對的。當有新的證據出現時，你應該改變想法。但要慎選戰場——要被正確地聽到，你首先需要傾聽他人。
關於脆弱性（Vulnerability）：承認自己犯了錯或不在自己的能力範圍內，長遠來看實際上會提升你的地位。表達脆弱性是謙遜的外在展現，展示了負責任的態度，並且是你信任他人意見的信號。有時候，你能做的最好的事情就是說：「我不知道。」
做一個「Googley」的人#
Google 內部有自己版本的「謙遜、尊重與信任」原則——早期被非正式地稱為**「Googley」**。這個詞從未被明確定義，大致意思是「不作惡」、「做正確的事」、「善待彼此」。
「Googley」的問題#
隨著時間推移，Google 意識到這個詞被過度使用，更糟的是，它可能成為招聘或評估中無意識偏見的來源。如果「Googley」對每個員工的意義都不同，這個詞就可能開始意味著「像我一樣」——這顯然不是招聘的好標準。
明確定義的「Googleyness」特質#
Google 最終透過明確定義一套代表強大領導力的屬性和行為來解決這個問題：
- 在模糊中茁壯（Thrives in Ambiguity）：能處理矛盾的訊息或方向，建立共識，在環境不斷變化時仍能推進問題解決
- 重視回饋（Values Feedback）：有謙遜去優雅地接受和給予回饋，理解回饋對個人（和團隊）發展的價值
- 挑戰現狀（Challenges Status Quo）：能設定雄心勃勃的目標，即使面對他人的抵抗或慣性也能追求
- 以使用者為先（Puts the User First）：對 Google 產品的使用者有同理心和尊重，追求符合使用者最佳利益的行動
- 關心團隊（Cares About the Team）：對同事有同理心和尊重，主動幫助他人而無需被要求，提升團隊凝聚力
- 做正確的事（Does the Right Thing）：對所做的一切有強烈的道德感；願意做出困難或不方便的決定來保護團隊和產品的完整性
有了這些明確定義的最佳實踐行為後，Google 已經開始避免使用「Googley」這個詞。具體說明期望永遠比模糊的標籤好。
結論#
幾乎任何規模的軟體事業的基礎，都是一個運作良好的團隊。儘管獨行天才的迷思仍然存在，事實是沒有人真的獨自完成一切。
一個軟體組織要經得起時間的考驗，必須擁有植根於謙遜、信任與尊重的健康文化，以團隊而非個人為中心。此外，軟體開發的創造性本質要求人們承擔風險並偶爾失敗——要讓人們能接受失敗，就必須存在一個健康的團隊環境。
TL;DRs#
- 注意獨立工作的取捨：隱藏工作會增加走錯方向的風險，降低巴士因子，減慢進度
- 投資理解人際互動：認識到你和團隊花在溝通和人際衝突上的時間。對自己和他人的個性與工作風格做少量投資，可以大幅提高生產力
- 了解工作風格的差異：如果你想在團隊或大型組織中有效工作，要注意自己偏好的工作風格以及他人的工作風格
- 實踐三支柱：將謙遜、尊重與信任融入日常工作——從放下自我、學會給予和接受批評、對影響持開放態度做起
- 擁抱失敗文化：快速失敗並迭代，透過無責事後分析從錯誤中學習，將失敗視為成長的黃金機會