我在 Google 工作 14 年後領悟的 21 條金律

寫程式不難，難在處理「人」與「複雜」。資深 Google 工程師分享 14 年心得，從用戶思維到團隊協作，這 21 條金律助你成就更深遠的職涯。 （前情提要：Google 即時翻譯正式開放所有耳機品牌：70+ 語言上線，美墨印 Android 手機先發 ） （背景補充：Google 正式推出「Gemini 3」！登頂全球最聰明 AI 模型，有什麼亮點？）   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. 大多數「緩慢」的團隊實際上是「失焦」的團隊 當專案停滯不前時，本能是歸咎於執行力：人手不夠、技術選型錯誤。通常這些都不是核心問題。 在大公司，團隊是你的並發單元，但協調成本隨團隊增加呈幾何級增長。大多數緩慢實際上是對齊失敗——人們在構建錯誤的東西，或以不兼容的方式構建正確的東西。 ...