在科技巨頭 Google 待了 14 年是什麼樣的體驗？出版過許多書籍的知名軟體工程師、Google Chrome 工程經理 Addy Osmani 近日發表了一篇深具啟發性的文章 21 Lessons From 14 Years at Google，把他 Google 工作 14 年，從一名專注於程式碼的工程師，蛻變為管理與領導者的心路歷程。
Addy Osmani 個人網頁的首頁截圖
Addy Osmani 直言，剛加入 Google 時，他以為工作的核心就是「寫出完美的程式碼」。但他逐漸發現，那些真正脫穎而出的工程師，未必是寫程式最厲害的人，而是那些懂得處理程式碼以外事務（人、政治、目標對齊、模糊性）的人。
這 21 條經驗法則，不是關於特定的技術，畢竟我們常看到各種技術的變遷真的很快，而是關於那些在不同團隊、不同專案中反覆出現的「模式」。無論你是剛入行的菜鳥，還是資深工程師，這些建議都極具參考價值。
以下為 Addy Osmani 的 21 堂課精華編譯與整理：
關於「解決問題」與「行動」
1、最優秀的工程師沈迷於解決用戶問題。不要先愛上某個技術然後硬找地方用。最有價值的工程師是「以終為始」（work backwards），深入了解用戶痛點，讓解決方案從中浮現。先有技術再找問題，往往只會製造不必要的複雜度。
2、「你是對的」很廉價，「一起達成共識」才是真功夫。你可以在每一場技術辯論中獲勝，但最後輸掉整個專案。真正的技能不是證明自己最聰明，而是引導討論以對齊問題，並對自己的確定性保持懷疑。採納「強烈觀點，但弱堅持」（Strong opinions, weakly held）的態度。
3、偏向行動，發佈產品 (Ship) 追求完美會導致癱瘓。完美的解決方案很少來自空想，而是來自與現實的碰撞。先做出來，再做對，最後再做好。醜陋的初版原型帶來的回饋，遠勝一個月的理論辯論。
關於「程式碼品質」與「維護」
4、清晰即資深，聰明即負債。寫出「聰明」的程式碼感覺很棒，但在團隊協作中，清晰度不是風格偏好，而是降低營運風險。你的程式碼是寫給半夜兩點起來修修復故障的陌生人看的。資深工程師懂得用「聰明」交換「清晰」。
5、「新奇」是一種貸款，你將用故障、招募難度和認知負擔來償還。把你對新技術的選擇想像成只有極少額度的「創新代幣」。只在你最有優勢的地方創新，其他地方盡量選擇無聊但穩定的方案。
6、程式碼不會為你辯護，人透過人來辯護。在大型組織中，決定你命運的會議往往你不在場。如果沒有人能在你不在場時說出你的影響力，你的影響力就等於不存在。這不是要你搞政治，而是要讓你的價值鏈對所有人（包括你自己）都清晰可見。
7、最好的程式碼是你沒寫的那一行。沒人會因為刪除程式碼而升職，但刪除往往比增加更能改善系統。每一行沒寫的程式碼，就是不需要除錯、維護或解釋的一行。在動手前先問：「如果我們什麼都不做會怎樣？」
8、在規模化之下，即便是你的 Bug 也有用戶依賴 當用戶夠多，你的任何行為（包含 Bug）都會被視為功能特性。相容性工作就是產品本身。大部分的 API 設計其實都是「API 退休計畫」。
關於「團隊協作」與「影響力」
9、大多數「慢」的團隊其實是「沒對齊」的團隊。專案拖延通常不是因為大家不努力或技術太爛，而是目標不一致。資深工程師花更多時間在釐清方向和介面，而不是單純想辦法「寫快一點」。
10、專注於你能控制的。你無法控制組織改組或市場變化，但你可以控制你的工作品質和反應。專注於你的影響力圈，把焦慮轉化為具體的行動。
11、抽象層並未移除複雜性，只是把它延後到你值班那天。每個抽象層都是一個賭注，賭你不需要知道底層運作。但抽象層總會洩漏（Leaky Abstractions），當它失效時，你需要知道你站在什麼之上。了解底層原理不是為了懷舊，而是為了生存。
12、寫作強迫清晰。把事情教給別人的過程，是檢視自己理解漏洞最快的方法。寫作和教學不是無私的奉獻，而是一種自私的學習駭客技巧（hack）。
13、那些讓其他工作得以進行的工作是無價的，也是隱形的 「膠水工作」（文件、新人教育訓練、協調）至關重要。但如果你無意識地做，它會燒盡你的精力卻不被看見。要把這些工作時間箱化（Timebox）、輪替，並轉化為可見的產出（如文件、自動化工具）。
14、如果你贏了每一場辯論，你可能正在累積沉默的阻力。當人們不再反對你，可能不是被你說服了，而是放棄嘗試了。真正的共識需要時間，甚至需要你公開改變心意。
關於「職業生涯」與「成長」
15、當指標變成目標，它就不再是個好指標，這是古德哈特定律（Goodhart’s Law）。如果你考核程式碼行數，你就會得到一堆廢話程式碼。資深的做法是，對每一個速度指標，都要配對一個品質或風險指標，並堅持解讀趨勢而非盲目崇拜數字。
16、承認「我不知道」比假裝懂更安全。 資深工程師說「我不知道」不是示弱，而是授權。這創造了一個心理安全的環境，讓團隊敢於提問和挑戰假設。
17、你的人脈比任何一份工作都長久。工作不是永遠的，但人脈是。用好奇心和慷慨來經營關係，而不是交易心態。當你要轉換跑道時，往往是這些關係為你開門。
18、大多數的效能提升來自「移除工作」，而非增加聰明才智。最快的程式碼就是「不執行的程式碼」。在優化之前，先質疑這個計算是否真的有必要存在。
19、流程是為了減少不確定性，而不是製造文書作業。最好的流程讓協作更容易；最壞的流程只是為了在出事時找人背鍋。如果流程不能解釋如何降低風險，那它可能只是累贅。
20、最終，時間比金錢更有價值。職涯早期你用時間換金錢，但某個時間點後，你會發現時間才是不可再生資源。不要盲目追求下一個職級，要清楚你正在交換什麼。
21、沒有捷徑，只有複利。專業來自刻意練習。學習是可以複利的，特別是當你創造出新的選項而不只是新的知識瑣事時。寫作、建立可重用的模組、將經驗總結成劇本（Playbooks）。把職涯當作複利投資，而非買彩券。
回歸「人」的本質
Addy Osmani 最後總結，這 21 條教訓其實核心只有幾點，保持好奇、保持謙遜，並記住工作永遠是關於「人」，不管是你服務的用戶，還是與你並肩作戰的隊友。
在 AI 快速發展的今天，技術本身變得越來越容易獲取，但如何運用技術解決人的問題、如何領導團隊穿越迷霧，這些軟實力反而成為了工程師最硬的護城河。
同場加映：Hacker News 網友犀利評論
他寫的這篇文章在科技論壇 Hacker News 上引發了超過 300 則討論，許多資深工程師與前 Google 員工提出了更為現實、甚至是殘酷的補充觀點。
1、Google 真的「痴迷於用戶」嗎？前員工的逆風爆料
雖然 Addy Osmani 的第一條教訓是「痴迷於解決用戶問題」，但知名開發者、前 Google 工程師 Mike Hearn 在討論串中現身說法，直言這一點讓他感到「格外刺耳（jarring）」。
Mike Hearn 表示： 「當我在 Google 負責面向用戶的產品（地圖、Gmail、帳戶）時，我經常閱讀公開的用戶支援論壇。但我學到的是：
幾乎沒有其他工程師會這麼做。
我這樣做被認為很怪。
經理和晉升委員會對此持負面看法。
理論上有專門的員工負責監控這些論壇，但實際上工程經理很少關注。這導致了一種普遍與外界脫節的現象。」
這段評論呈現另一個觀點，大公司內部的「晉升導向開發」（Promotion Oriented Development）文化往往與「用戶導向」背道而馳。
2、為什麼工程師被禁止接觸用戶？
網友 avidiax 提供了一個深刻的組織學觀點，解釋為何在大公司，工程師想接觸用戶往往會受到阻礙：
「PM（產品經理）不希望來自用戶的內容破壞他們對產品的願景，工程經理不希望用戶反饋破壞品質觀感，或打亂已經排定好的有影響力的工作。 甚至連法律部門也不希望你公開承認產品有缺陷。這導致了一種結構性的隔離，保護了內部的權力結構，卻犧牲了真實的理解。」
3、殘酷的戰爭格言：90% 的人其實不該在那裡
針對大部分「慢」的團隊其實是「沒對齊」的團隊這一點，網友 wood_spirit 引用了一句戰爭格言來形容現代軟體開發的現狀：
「在 100 個人中，1 人應該是戰士，9 人應該是士兵，而剩下的 90 人根本不應該出現在戰場上。 這在軟體開發中也是真實的：在大公司裡，這 90% 的人並不知道自己不該在那裡，他們只是建立了一整個與公司實際需求平行的系統與專案世界（parallel world of systems）。」
這段評論犀利地指出了大公司內部為何會有這麼多「為了技術而技術」或「為了升遷而造輪子」的現象。
理想與現實
CyberQ 認為，將 Addy Osmani 的「理想建議」與 Hacker News 上的「現實吐槽」放在一起看，其實也讓我們理解，Osmani 提供的是「為了成為卓越工程師應該追求的目標」，而網友們指出的是「在追求這些目標時會遇到的組織阻力」。
首圖由 Nano Banana AI 生成
