不是寫代碼最牛的人才是頂級工程師？Google老工程師的14年21條經驗總結

在技術世界里，編寫優秀代碼固然重要，但真正讓工程師脫穎而出的，往往是那些看似“代碼之外”的能力：理解用戶、協調團隊、應對不確定性、做出明智選擇。

Addy Osmani，在 Google 工作近 25 年、曾在 Chrome 團隊主導 DevTools、Lighthouse 和 Core Web Vitals 的資深工程師，如今是 Google Cloud AI 總監。近日，他將自己多年的深度實踐總結為《21 Lessons From 14 Years at Google》（在 Google 工作 14 年的 21 條經驗教訓）。

在這篇經驗分享中，他不僅談技術，更分享了職業成長、團隊協作和工程文化中那些鮮為人知卻至關重要的洞察，為開發者提供了一份既實際又耐人尋味的指南。

原文鏈接：https://addyosmani.com/blog/21-lessons/

作者 | Addy Osmani 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

大約 14 年前我加入谷歌時，以為這份工作的核心就是寫出優秀的代碼。

這個判斷并不算錯，但也只對了一半。待得越久，我越意識到，那些真正發展得好的工程師，未必是編程能力最強的人，而是更早學會如何應對“代碼之外的一切”：人、組織政治、目標對齊，以及無處不在的不確定性。

這些都是我希望自己能更早明白的經驗。有些經驗教訓本可以讓我少走好幾個月的彎路；有些則花了我好幾年才真正想通。它們幾乎都和具體技術無關——技術變化太快，不值得執著。反而是關于一些反復出現的模式：一個項目接一個項目，一個團隊換一個團隊，總是會重演。

我之所以把這些寫出來，是因為自己曾經從前輩工程師那里獲益良多。就當這是一次“傳遞善意”的嘗試吧。

最好的工程師，對解決用戶問題近乎偏執

人很容易迷上某種技術，然后再去尋找適合它的應用場景。我也這么做過，幾乎所有人都做過。但真正創造最大價值的工程師，思路恰恰相反：他們從問題出發，先把用戶的問題理解到位，解決方案自然會從中浮現。

所謂“以用戶為中心”，意味著要花時間去看工單、和用戶交流、觀察用戶是如何卡住的，不斷追問“為什么”，直到觸及問題的根本。真正理解問題的工程師，往往會發現，那個優雅的解法比所有人想象的都要簡單。

而從一開始就帶著“解法”的工程師，常常會為了證明自己是對的，不斷往系統里堆復雜度。

對不對不值錢，一起走到“對”才是真本事

你可以在每一次技術爭論中都獲勝，但項目依然可能會失敗。我見過不少非常聰明的工程師，總是房間里最“對”的那個人，卻一點點積累起看不見的怨氣。結果往往在后期爆發，表現為各種“莫名其妙的執行問題”和“說不清楚的阻力”。

真正重要的能力不是“我是不是對的”，而是能不能在討論中先對齊問題本身，給別人留出空間，同時也對自己的判斷保持一點懷疑。

要有強觀點，但別死抱不放。不是因為你沒有立場，而是因為在不確定性下做出的決策，本來就不該和個人身份綁死在一起。

行動優先，先交付再說。空白頁是沒法修改的

對完美的執念，往往是行動的最大阻力。我見過工程師為了一個從沒真正做過的東西，花上好幾周反復爭論“最理想的架構”。但現實是，完美方案幾乎不會只靠想出來，它一定是在和現實碰撞之后才慢慢成形的——AI 在這件事上，其實能幫不少忙。

先做出來，再把它做對，然后再做得更好。把那個丑陋的原型丟到用戶面前，寫下那份略顯凌亂的設計初稿，發布一個讓你自己都有點不好意思的 MVP。你從一周真實反饋里學到的東西，往往比一個月的紙上談兵還多。

節奏感會帶來清晰度，過度分析只會什么都做不出來。

清晰的表達能力是資歷，耍巧就是負擔

工程師幾乎都有一個本能：想寫點“聰明”的代碼。那感覺很像是在證明自己有多厲害。

但軟件工程從來不是“一個人寫完就結束”的事，而是代碼要經得起時間，也要經得起一波又一波后來者的接手。在這種現實環境里，清晰不是風格選擇，而是在降低系統運行風險。

你的代碼，其實是一份寫給陌生人的“策略備忘錄”——那些人可能會在凌晨兩點、系統出故障時，頂著壓力來維護它。請為他們能不能看懂而優化，而不是為你自己的優雅感受服務。我最敬重的那些資深工程師，幾乎每一次都會用清晰換掉“巧妙”。

創新就像是“貸款”，遲早要用故障、招聘成本和認知負擔來償還

對技術選型，不妨把自己當成一家只有少量“創新代幣”的組織。每引入一種明顯非主流的技術，就消耗一枚。你其實用不起太多。

重點不是“永遠別創新”，而是“只在你確實被付錢要求創新的地方創新”。其他地方，默認選擇無聊一點的方案更安全，因為“無聊”意味著失敗模式是已知的。

很多時候，“最適合當前問題的工具”，并不如“在很多問題上都不算最差的工具”。畢竟，真正昂貴的，是把一個動物園長期運轉下去。

代碼不會替你說話，只有人會

職業早期，我一度相信：只要把事情做好，價值自然會被看到。后來發現這是個誤解。代碼安靜地躺在倉庫里，但你的經理會不會在會上提到你，同事會不會把你推薦進一個關鍵項目，完全是另一回事。

在大型組織里，很多決定是在你不在場的會議上做出的，用的是你沒寫過的總結，由那些只有五分鐘時間、同時背著十二個優先級的人拍板。如果當你不在房間里時，沒人能清楚說出你的價值，那你的影響力本質上就是“可有可無”。

這不完全是自我推銷，而是讓價值鏈對所有人都足夠清晰——包括你自己。

最好的代碼，是你根本沒寫過的代碼

工程文化里總是贊美“創造”。幾乎沒人會因為刪代碼而升職，盡管刪代碼往往比加代碼更能改善系統。你每少寫一行代碼，就少了一行需要調試、維護和解釋的負擔。

在動手之前，先把這個問題問到盡頭：“如果我們干脆什么都不做，會怎樣？”有時候答案是“其實也不會出什么事”，那就是你的解決方案。

問題從來不是工程師不會寫代碼，或者不能用 AI 來寫。恰恰相反，我們太擅長寫代碼了，以至于常常忘了先問一句：這東西真的有必要寫嗎？

規模一上來，連你的 Bug 都會有用戶

一旦用戶足夠多，任何“看得見的行為”都會變成依賴——不管你當初是怎么承諾的。總會有人在爬你的 API、自動化你的小毛病，甚至把你的 Bug 當成特性緩存下來。

這會帶來一個影響整個職業判斷的認知：你不能把兼容性工作當成“維護”，把新功能當成“正事”。兼容性本身就是產品的一部分。

所以，棄用設計要當成一次遷移來做：給時間、給工具，也要給同理心。很多所謂的“API 設計”，其實真正考驗的是“API 如何體面退休”。

大多數“慢團隊”，本質上是沒對齊的團隊

項目一拖再拖時，第一反應往往是怪執行力：人不夠拼、技術選錯了、工程師不夠多。但多數情況下，這些都不是根因。

在大公司里，團隊是并發執行的基本單元，而隨著團隊數量增加，協作成本會呈幾何級數上漲。所謂“慢”，往往是對齊失敗：要么大家在做錯的事情，要么在用彼此不兼容的方式做對的事情。

資深工程師花更多時間在澄清方向、接口和優先級上，而不是“把代碼寫得更快”，因為真正的瓶頸就卡在這里。

專注你能控制的，放下你控制不了的

在大公司里，有太多變量不在你掌控之中：組織調整、管理決策、市場變化、產品轉向。反復糾結這些，只會制造焦慮，卻帶不來行動空間。

那些能長期保持清醒和高效的工程師，都會把注意力收縮到自己的影響圈內。你無法決定會不會重組，但你可以決定工作的質量、自己的回應方式，以及從中學到什么。面對不確定性，把問題拆小，找出你此刻“確實能做的動作”。

這不是消極接受，而是策略性的聚焦。把精力花在無法改變的事情上，本質上是在偷走你改變得了的那部分。

抽象不會消除復雜度，只是把它推遲到你值班的那天

每一層抽象，都是一次賭博：賭你永遠不需要理解底層發生了什么。有時候你會贏，但總會有東西“漏出來”。而當它真的漏出來時，你必須知道自己踩在什么之上。

資深工程師會在技術棧不斷變高的同時，持續學習“更底層”的東西。這不是情懷，而是對那個凌晨三點、抽象失效、你獨自面對系統的時刻保持敬畏。放心使用你的技術棧，

但一定要對它底層的失敗模式有一個可用的心智模型。

寫作會逼迫你變清楚，最快的學習方式之一是試著教別人

寫下來，本身就會迫使思路變清晰。每當我試圖向別人解釋一個概念——不管是文檔、分享、代碼評審評論，還是跟 AI 聊天——我都會發現自己理解里的空洞。把事情講清楚給別人，本身就會讓它在我腦子里更清楚。

當然，這不意味著你靠教別人就能學會當外科醫生，但在軟件工程這個領域，這個前提大體是成立的。

這不僅僅是“樂于分享”，更是一種利己的學習技巧。如果你覺得自己已經懂了某個東西，試著用最簡單的話講一遍。你卡住的地方，往往就是理解最淺的地方。

教學，其實是在給自己的認知模型做調試。

讓其他工作得以進行的工作，最珍貴，卻常常看不見

“膠水工作”——文檔、入職培訓、跨團隊協調、流程改進——都很重要。但如果你下意識地去做，可能會拖慢技術發展軌跡，甚至把自己累垮。陷阱在于把它當成“樂于助人”，而不是當成有邊界、可衡量、可見的影響力來管理。

給它定時間框架。輪換著做。把它轉化為產物：文檔、模板、自動化工具。并讓別人能看到這是價值貢獻，而不是性格特質。

珍貴又隱形，對職業生涯來說是一種危險組合。

如果你贏得每一次爭論，可能在積累無聲的抵抗

我學會了懷疑自己的“確定性”。當我輕而易舉地“贏”得太多時，通常就有問題。別人不再反對你，并不是因為被說服，而是放棄嘗試——而這種不同意見會體現在執行上，而不是會議上。

真正的對齊需要時間。你必須理解別人的視角，吸納反饋，有時候還得當眾改變主意。

短期的“我對”感覺，比不上長期和心甘情愿的協作者一起做事的價值。

當一個指標變成目標，它就停止衡量了

你呈現給管理層的每個指標，遲早都會被“優化”。不是出于惡意，而是因為人類會去優化被測量的東西。

你跟蹤代碼行數，就會出現更多行。你跟蹤開發速度，就會出現夸大的估算。

資深做法是：對每個指標請求，用一對指標回應——一個衡量速度，一個衡量質量或風險。然后強調趨勢分析，而不是盲目追求閾值。目標是洞察，而不是監控。

承認自己不知道的，比假裝知道更安全

那些說“我不知道”的資深工程師，并不是在示弱——他們在創造安全空間。當領導者承認不確定性時，信號是：其他人也可以安全地承認。否則，團隊就會形成“假裝懂”的文化，問題被隱藏，直到爆炸。

我見過最資深的人從不承認困惑的團隊，結果是：沒人敢提問，假設不被質疑，初級工程師保持沉默，因為他們以為大家都懂。

以好奇心為榜樣，你就會得到一個真正會學習的團隊。

你的關系網，比你做的每份工作都要持久

職業早期，我專注于工作而忽略了建立人脈。事后看，這是個錯誤。那些花時間經營關系的同事——無論公司內外——幾十年都能受益。

他們最先聽到機會，能更快搭建橋梁，獲得推薦，甚至與長期信任的人共同創業。

你的工作不是永遠的，但關系網是。用好奇心和慷慨心去經營，而不是只為了交易式的功利。

需要跳槽時，往往是關系幫你打開門。

大多數性能提升，來自減少工作量，而不是耍聰明

系統變慢時，本能反應是加東西：緩存層、并行處理、更聰明的算法。有時候這是對的，但我見過更多性能提升，來自問一句：“哪些計算其實沒必要做？”

刪除不必要的工作，幾乎總比把必要工作做快更有效。最快的代碼，是永遠不運行的代碼。

在優化之前，先問問自己：這份工作真的有存在的必要嗎？

流程是為降低不確定性，而不是為了留下紙面記錄

最好的流程讓協調更容易，讓失敗成本更低。最糟的流程是官僚秀——不是為了幫忙，而是為了出錯時有人背鍋。

如果你無法解釋一個流程如何降低風險或增加清晰度，它很可能只是負擔。

如果團隊花在寫文檔上的時間比實際做事還多，那問題就嚴重了。

到頭來，時間比錢更值錢。按此行事

職業早期，你用時間換錢——沒問題。但到某個階段，這個邏輯會反過來。你會意識到，時間才是不可再生的資源。

我看過資深工程師為追求下一次升職、優化幾個百分點的薪酬而燒盡自己。有的人得到了目標，大多數人事后都會想：值不值？

答案不是“不用努力”，而是“知道你在交易什么，并且有意識地做出選擇”。

沒有捷徑，但有復利效應

專業能力來自刻意練習——稍微超出當前能力、反思、重復。幾年如一日。沒有速成版。

但好消息是：當學習產生新選擇，而不僅僅是新知識碎片時，它會復利。寫作——不是為了吸引眼球，而是為了清晰。構建可復用的原語。把經驗累積成操作手冊。

把職業當成復利，而不是買彩票的人，通常最終會走得更遠。

最后一點感想

二十一條經驗看起來很多，但歸根結底只有幾個核心：保持好奇，保持謙遜，記住工作始終關乎人——你為誰構建（用戶），你和誰一起構建（團隊）。

工程師的職業足夠長，允許你犯不少錯誤，還能最終走得更遠。我最佩服的工程師，不是事事正確的人，而是那些從錯誤中學習、分享發現、持續堅持的人。如果你剛起步，請相信時間會讓經驗更豐富；如果你已深入其中，希望這些經驗對你有所共鳴。