寫程式不難，難在處理「人」與「複雜」。資深 Google 工程師分享 14 年心得，從用戶思維到團隊協作，這 21 條金律助你成就更深遠的職涯。
（前情提要：Google 即時翻譯正式開放所有耳機品牌：70+ 語言上線，美墨印 Android 手機先發 ）
（背景補充：Google 正式推出「Gemini 3」！登頂全球最聰明 AI 模型，有什麼亮點？）

本文目錄

• 1. 頂尖工程師痴迷於解決用戶問題
• 2. 「證明自己是對的」毫無價值，共同達成正確目標才是重點
• 3. 偏向行動。上線吧！你可以修改爛頁面，但無法修改空白頁
• 4. 資深體現在清晰，聰明體現在負擔
• 5. 「新奇」是向維修、招聘和認知負荷借的高利貸
• 6. 程式碼不會為你發聲，人會
• 7. 最好的程式碼是你從未寫下的那行
• 8. 當規模夠大時，連你的 Bug 都有用戶
• 9. 大多數「緩慢」的團隊實際上是「失焦」的團隊
• 10. 專注於你能控制的事，忽略你不能控制的
• 11. 抽象並不消除複雜性，只是將其轉移
• 12. 寫作強迫清晰，教學是學習最快的方法
• 13. 讓其他工作成為可能的工作是無價的，卻也是隱形的
• 14. 如果你贏了每一場爭論，你可能正在累積無聲的阻力
• 15. 當指標變成目標時，它就不再是好指標了
• 16. 承認「我不知道」比裝懂更能創造安全感
• 17. 你的脈絡比你做過的任何一份工作都長久
• 18. 大多數性能提升來自「移除工作」，而非「聰明的算法」
• 19. 流程的存在是為了減少不確定性，而非創造文書記錄
• 20. 最終，時間會比金錢更值錢，請據此行動
• 21. 沒有捷徑，但有複利效應

• 最後的一點想法

Google Cloud AI 總監 Addy Osmani，是一名經驗豐富的軟體工程師與思想者，曾在 Chrome 擔任開發者體驗負責人近 14 年，參與 DevTools、Lighthouse 和 Core Web Vitals 等專案。如今，他負責協調 Google DeepMind 、工程、產品和開發者關係團隊之間的工作。

他在 3 日在他個人部落格發布了一篇深度職場心得文。將他多年在 Google 的工作經驗與職業素養結合，總結出 21 條關於溝通、技術選擇與職涯規劃的寶貴建議，動區編譯整理如下：

---

當我約 14 年前加入 Google 時，我以為這份工作就是寫出完美的代碼。我只對了一部分。待得越久，我越意識到那些表現優異的工程師不一定是程式寫得最好的，而是那些學會如何駕馭程式碼之外的一切的人：包括人際關係、職場政治、共識對齊以及不確定性。

這些經驗是我希望自己能早點明白的。有些能幫我節省數月的挫敗感，有些則花了我數年才真正領悟。這些都與特定技術無關：技術更迭太快，並不重要。它們關乎的是那些在不同專案、不同團隊中反覆出現的規律。

我分享這些，是因為我曾從那些願意提攜後進的工程師身上獲益良多。這是我回饋的一點心意。

1. 頂尖工程師痴迷於解決用戶問題

愛上某種技術並到處尋找應用場景是非常誘人的。我做過，每個人都做過。但創造最大價值的工程師是「逆向工作」的：他們痴迷於深入理解用戶問題，並讓解決方案從這種理解中自然產生。

用戶痴迷意味著花時間研究客服工單、與用戶交談、觀察用戶的操作困境，不斷問「為什麼」直到觸及核心。真正理解問題的工程師通常會發現，優雅的解決方案往往比預想的更簡單。 從解決方案出發的工程師，往往為了合理化自己的方案而增加了不必要的複雜性。

2. 「證明自己是對的」毫無價值，共同達成正確目標才是重點

你可以贏得每一場技術爭論，卻輸掉整個專案。我見過聰明的工程師因為總是想當全場最聰明的人，而積累了無聲的怨恨。這種代價隨後會以「神祕的執行問題」或「莫名的阻力」顯現。

技能不在於「正確」，而在於參與討論以對齊問題、為他人創造空間，並對自己的確定性保持懷疑。 **強烈的主見，開放的心態 **——這不是因為你缺乏信念，而是因為在不確定情況下做出的決定，不應與你的自尊掛鉤。

3. 偏向行動。上線吧！你可以修改爛頁面，但無法修改空白頁

追求完美會導致癱瘓。我見過工程師花好幾週討論他們從未構建過的東西的理想架構。完美的方案很少源於純粹的思考——它源於與現實的碰撞。AI 在許多方面可以提供幫助。

先做到，再做對，最後做得更好。 把醜陋的原型推到用戶面前。寫下混亂的設計文檔初稿。發布那個讓你略感尷尬的 MVP。從一週的真實反饋中學到的東西，比一個月的理論爭辯還要多。 衝勁帶來清晰，分析癱瘓則一事無成。

4. 資深體現在清晰，聰明體現在負擔

寫出「聰明」程式碼的本能幾乎是工程師通用的，這感覺像是能力的證明。 但軟體工程是「時間」加上「其他程式設計師」產生的化學反應。在這種環境下，清晰不是一種風格偏好，而是降低營運風險。

你的程式碼是寫給那些可能在凌晨兩點維修故障的陌生人的戰略備忘錄。優化他們的理解力，而不是你的優雅感。我最敬佩的資深工程師每次都會選擇用「聰明」換取「清晰」。

5. 「新奇」是向維修、招聘和認知負荷借的高利貸

將你的技術選擇視為一家預算有限的「創新代幣」公司。每當你採用實質上的非標準技術時，就花掉一枚。你付不起太多。 重點不是「永遠不要創新」，而是「只在你獲得獨特報酬的地方創新」。

其他一切都應該預設為「無聊」，因為無聊意味著其失效模式是已知的。 「最適合該工作的工具」往往是「在多項工作中表現最不差的工具」——因為經營一個技術動物園會成為真正的負擔。

6. 程式碼不會為你發聲，人會

職業生涯早期，我以為優秀的工作表現自會證明一切。我錯了。程式碼靜靜地待在倉庫裡。你的主管在會議中是否提到你，同事是否推薦你參與專案，這才是關鍵。

在大型組織中，決定是在你未受邀的會議中、由只有五分鐘時間處理十二項優先事項的人，根據你沒寫過的摘要做出的。如果當你不在場時，沒有人能說清你的影響力，那你的影響力就是可有可無的。 這不完全是自我推銷，而是要讓價值鏈對每個人（包括你自己）都清晰可見。

7. 最好的程式碼是你從未寫下的那行

工程文化慶祝創造。沒人會因為刪除程式碼而升職，儘管刪除通常比增加更能優化系統。你沒寫下的每一行程式碼，都是你永遠不需要調試、維護或解釋的。

在構建之前，徹底問自己一個問題：「如果我們乾脆不做，會發生什麼？」有時答案是「沒什麼壞事」，那就是你的解決方案。 問題不在於工程師不會寫代碼或不會用 AI 寫，而在於我們太擅長寫了，以至於忘了問「應不應該寫」。

8. 當規模夠大時，連你的 Bug 都有用戶

當用戶足夠多時，任何可觀察的行為都會變成依賴項——無論你原本承諾了什麼（海勒姆定律）。有人正在抓取你的 API，自動化你的奇特特性，快取你的 Bug。

這產生了一個職業級的洞察：你不能把兼容性工作視為「維護」，把新功能視為「真實的工作」。兼容性就是產品本身。 設計棄用方案時，應將其視為帶有時間、工具和同理心的遷移過程。大多數「API 設計」實際上是「API 退休」。

9. 大多數「緩慢」的團隊實際上是「失焦」的團隊

當專案停滯不前時，本能是歸咎於執行力：人手不夠、技術選型錯誤。通常這些都不是核心問題。 在大公司，團隊是你的並發單元，但協調成本隨團隊增加呈幾何級增長。大多數緩慢實際上是對齊失敗——人們在構建錯誤的東西，或以不兼容的方式構建正確的東西。 資深工程師花更多時間釐清方向、接口和優先級，而不是「更快地寫代碼」，因為那是真正的瓶頸所在。

10. 專注於你能控制的事，忽略你不能控制的

在大型公司，無數變量是你無法控制的——組織架構調整、管理層決策、市場變化、產品轉向。糾結於這些會產生焦慮卻無濟於事。 保持理智且高效的工程師會專注於他們的影響圈。

你無法控制重組，但你可以控制工作的質量、你的反應以及你學到的東西。面對不確定性時，將問題拆解並找出你可採取的具體行動。 這不是消極接受，而是戰略專注。花在無法改變的事情上的精力，是從你能改變的事情上偷走的。

11. 抽象並不消除複雜性，只是將其轉移

每一種抽象都是一場賭博，賭你不需要理解底層原理。有時你贏了，但抽象總會洩漏。當它失效時，你需要知道底層發生了什麼。 資深工程師即使在技術棧越堆越高時，仍會持續學習「底層」知識。這不是出於懷舊，而是出於對抽象失敗時刻的尊重。使用你的工具棧，但要掌握其底層失效模式的心智模型。

12. 寫作強迫清晰，教學是學習最快的方法

寫作強迫你思考。當我向他人解釋一個概念時——無論是在文件、演講、代碼審查評論，甚至只是與 AI 聊天——我都會發現自己理解上的空白。

讓內容對別人清晰的過程，也會讓它對我更清晰。 這不只是慷慨分享知識，這是一個自私的學習技巧。如果你認為自己理解了某件事，試著簡單地解釋它。你卡住的地方，就是你理解淺薄的地方。 教學是在調試（debug）你自己的心智模型。

13. 讓其他工作成為可能的工作是無價的，卻也是隱形的

「膠水工作（Glue work）」——文檔、入職引導、跨團隊協調、流程改進——至關重要。但如果你無意識地去做，它會阻礙你的技術成長並讓你筋疲力盡。陷阱在於把它當作「樂於助人」，而不是將其視為有意識的、有邊界的、可見的貢獻。 限制時間、輪流執行、將其轉化為產出（文件、模板、自動化工具）。

讓它被視為影響力，而非人格特質。

14. 如果你贏了每一場爭論，你可能正在累積無聲的阻力

我學會了懷疑自己的確定性。當我「贏」得太輕鬆時，通常有些不對勁。人們停止爭論不是因為被你說服，而是因為他們放棄了嘗試——他們會在執行中，而非會議中表達這種反對。 真正的對齊需要更長時間。

你必須真正理解他人的觀點，納入反饋，有時甚至公開改變主意。短期贏得爭論的爽感，遠不如長期與心悅誠服的夥伴共事的價值。

15. 當指標變成目標時，它就不再是好指標了

你向管理層展示的每個指標最終都會被「操縱」。這不是因為惡意，而是因為人類會針對被測量的內容進行優化（古德哈特定律）。 如果你追蹤程式碼行數，你會得到更多行數。如果你追蹤速率，你會得到膨脹的估算。

資深的作法：針對每個指標請求，提供一對指標。一個看速度，一個看質量或風險。堅持解讀趨勢，而不是崇拜閾值。目標是洞察力，而非監視。

16. 承認「我不知道」比裝懂更能創造安全感

說「我不知道」的資深工程師並非展現弱點，而是在創造「許可」。當領導者承認不確定性時，這釋放出一個信號：這個房間對其他人也是安全的。 我見過資深人員從不承認困惑的團隊，那種傷害很大：問題沒人問，假設沒人挑戰，初級工程師保持沉默，因為他們以為只有自己不懂。 示範好奇心，你就能得到一個真正會學習的團隊。

17. 你的脈絡比你做過的任何一份工作都長久

職業生涯早期，我專注於工作而忽視了人脈。回頭看這是個錯誤。投資於關係（公司內外）的同事幾十年來都受益匪淺。 他們最先聽到機會，能更快建立橋樑，獲得職位推薦，並與建立多年信任的人共同創業。 工作不是永遠的，但人脈是。 以好奇和慷慨而非交易的心態去建立關係。

18. 大多數性能提升來自「移除工作」，而非「聰明的算法」

當系統變慢時，本能是增加：快取層、並行處理、更聰明的算法。有時這沒錯，但我見過更多性能提升來自問一句：「我們計算了哪些不需要的東西？」 刪除不必要的工作幾乎總比更快地完成必要工作更有影響力。最快的代碼是從不運行的代碼。

19. 流程的存在是為了減少不確定性，而非創造文書記錄

最好的流程讓協調更容易，讓失敗成本更低。最糟的流程是「官僚主義戲劇」——它的存在不是為了幫忙，而是為了出事時推卸責任。 如果你無法解釋一個流程如何降低風險或增加清晰度，那它可能只是負擔。如果人們花在記錄工作的時間比做工作還多，那就出大問題了。

20. 最終，時間會比金錢更值錢，請據此行動

職業生涯早期，你用時間換錢，這沒問題。但在某個點，計算方式會反轉。你會意識到時間是不可再生資源。 我見過資深工程師為了追逐下一個職等、優化那幾個百分點的薪酬而精疲力竭。有人得到了，但大多數人事後都懷疑這是否值得他們所付出的代價。 答案不是「不要努力工作」，而是「知道你在交易什麼，並有意識地進行交易」。

21. 沒有捷徑，但有複利效應

專業知識來自刻意練習——稍稍超出你目前的技能範圍，反思，重複，持續多年。沒有縮減版。 但希望在於：當學習創造新選擇而非僅僅是零散知識時，它會產生複利。 寫作（為了清晰）、構建可重用的原組、將慘痛教訓收集成操作手冊。 將職業生涯視為「複利」而非「彩票」的工程師，往往能走得遠得多。

---

最後的一點想法

這 21 條聽起來很多，但核心想法其實只有幾個：保持好奇、保持謙遜，並記住工作始終關乎於人——包括你為之構建產品的用戶，以及與你共同構建產品的隊友。

工程師的職業生涯很長，長到足以讓你犯下許多錯誤後依然能取得成功。我最欽佩的工程師不是那些從不犯錯的人，而是那些從錯誤中學習、分享發現並堅持不懈的人。

如果你剛開啟這段旅程，請知道它會隨時間變得越發精彩。如果你已深耕多年，希望其中幾條能讓你產生共鳴。