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

大約 14 年前我加入 Google 時，我以為這份工作的核心是寫出優秀的代碼——這個想法部分正確。待得越久，我越清楚地意識到：真正發展得好的工程師，未必是最強的程序員，而是那些學會如何應對代碼之外一切的人——人、組織政治、目標對齊，以及不確定性。

這些經驗都是我希望自己更早知道的。有些本可以讓我少走幾個月彎路，有些則花了好幾年才真正想明白。它們幾乎都不涉及具體技術，因為技術變化太快，不值得執着。真正重要的是那些一再出現的模式，在一個又一個項目、一個又一個團隊中反覆上演。

我把它們分享出來，是因為我自己也從前輩工程師的分享中受益良多。這算是一次“傳遞善意”。

1. 最好的工程師，對解決用户問題近乎執念

迷戀某種技術、再去尋找應用場景，很容易讓人沉溺其中。我也做過，幾乎所有人都做過。但真正創造巨大價值的工程師，會反向思考：先深入理解用户問題，再讓解決方案自然浮現。

這種對用户的執念，意味着花時間看工單、和用户交流、觀察用户受挫的過程，不斷追問“為什麼”，直到觸及根本。真正理解問題的工程師，往往會發現，優雅的解法比任何人預想的都要簡單。

工程師如果一開始就想着如何解決問題，往往會為了尋找理由而人為地增加複雜性。

2. 爭論技術正確與否很廉價，共同達成目標才是真正的工作

你可以在每一次技術爭論中獲勝，卻輸掉整個項目。我曾親眼目睹一些才華橫溢的工程師，因為總是自詡為房間裏最聰明的人，而默默地積攢怨氣。這種怨氣最終會在後期以“莫名其妙的執行問題”和“莫名其妙的阻力”的形式顯現出來。

真正的能力不在於證明自己永遠正確，而在於進入討論時先對齊問題，為他人留出空間，並對自己的確定性保持懷疑。

要有強烈的觀點，同時保持可修正性。原因不在於缺乏信念，而在於不確定條件下做出的決定，不該和個人身份牢牢綁定。

3. 行動優先，先發布再説

完美主義會讓人停滯不前。我見過工程師為一個從未實現過的系統，爭論數週“最理想的架構”。完美方案很少靠純思考誕生，它來自現實的反饋。AI 在這裏也能提供幫助。

先做出來，再做對，最後再優化。把醜陋的原型交到用户手中，寫下雜亂的設計初稿，發佈一個讓自己略感尷尬的 MVP。來自真實反饋的一週學習，勝過一個月的紙上談兵。

動能會帶來清晰感，分析癱瘓只會留下空白。

4. 清晰易懂的代碼是資深體現，表現聰明往往造成額外負擔

編寫巧妙代碼的本能幾乎是所有工程師的通病，，它看起來像能力的證明。

但軟件工程的本質在於投入時間和精力，並與其他程序員協作。在這種環境下，清晰性並非風格偏好，而是降低運營風險的根本所在。

你的代碼，其實是給凌晨兩點處理故障的陌生人看的戰略備忘錄。優先考慮他們是否能看懂，而不是你的技巧是否精妙。我最尊敬的高級工程師們都懂得，每次都要用清晰易懂來代替炫技。

5. 新技術是一筆貸款，償還方式是故障、招聘成本和認知負擔

把技術選型當作一筆有限的“創新額度”。每引入一個顯著非標準的技術，就消耗一枚代幣，而你承擔不起太多。

重點不在於拒絕創新，而在於“只在那些你因創新而獲得獨特報酬的領域進行創新”。其他一切都應該回歸平庸，因為平庸的失敗模式是眾所周知的。

很多時候，“最適合當前任務的工具”，不如“在多種任務中最不差的工具”。維護一個技術動物園，才是真正的税負。   

6. 代碼不會替你説話，人會

職業生涯初期，我曾認為優秀的工作成果會不言自明。但我錯了。代碼安靜地躺在倉庫裏，真正起作用的是：你的經理是否在會議上提到你，是否有同事推薦你參與項目。

在大公司裏，決策往往是在你未被邀請參加的會議上做出的，依據的是你未曾撰寫的總結，而決策者只有五分鐘時間，卻要處理十二項優先事項。如果沒人能清晰地闡述你不在場時的影響，那麼你的影響力實際上就變得可有可無了。

這並非單純的自我營銷，而是讓價值鏈對所有人清晰可見，包括你自己。

7. 最好的代碼，是你從未寫過的代碼

工程文化推崇創造，很少有人因為刪除代碼而獲得晉升，儘管刪除往往比新增更能改進系統。你沒有寫下的每一行代碼，都是未來無需調試、維護和解釋的負擔。

在動手之前，先徹底問一句：“如果我們什麼都不做，會發生什麼？”有時答案是“什麼壞事都不會發生”，那就是解法。

問題不在於工程師不會寫代碼或不會用 AI 寫代碼，而在於我們太擅長寫，以至於忘了問一句：是否真的有必要。

8. 當規模足夠大，連 bug 都會擁有用户

用户足夠多時，每一個可觀察到的行為都會變成依賴，無論你是否承諾過。有人會抓取你的 API、自動化你的怪癖、緩存你的 bug。

這帶來一個職業層面的洞見：兼容性工作不能被當成“維護”，新功能也不等同於“真正的工作”。兼容性本身就是產品。

設計廢棄方案時，要把它當作遷移來做，留出時間、工具和同理心。多數所謂的“API 設計”，其實是在做“API 退役”。

9. 多數“慢團隊”，問題在於未對齊

項目拖延時，人們很容易責怪執行力、技術選型或人手不足。通常這些都不是根因。

在大公司裏，團隊是併發執行的基本單位，但隨着團隊數量的增加，協調成本呈幾何級數增長。大多數效率低下實際上源於目標不一致——人們在做錯誤的事情，或者以不兼容的方式做正確的事情。

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

10. 專注可控之事，忽略不可控之事

在大公司中，組織調整、管理決策、市場變化、產品轉向，大多不在你掌控之內。反覆糾結只會製造焦慮，卻沒有行動空間。

能長期保持理性與效率的工程師，會聚焦在影響範圍內的事情。你無法阻止重組，但可以控制工作的質量、自己的反應，以及能學到什麼。面對不確定性，把問題拆解，找出你能採取的具體行動。

這不是消極接受，而是策略上的專注。花在無法改變之事上的精力，等同於從可改變之事上被偷走。

11. 抽象不會消除複雜性，只會把它推遲到你值班的那天

每一層抽象，都是一次下注，賭你無需理解底層。有時你會贏，但總會有泄漏發生。一旦發生，你必須知道自己站在什麼之上。

資深工程師會持續學習“更底層”的知識，並非懷舊，而是尊重那個凌晨三點抽象失效、只剩你和系統的時刻。可以用現成技術棧，但要保有對其失敗模式的理解。

12. 寫作會迫使思路清晰，教學是最快的學習方式

當我向他人解釋一個概念時——寫文檔、做分享、代碼評審，甚至只是和 AI 聊天——我總能發現自己理解中的漏洞。讓別人看懂的過程，也讓自己看懂。

這不意味着教書就能學會外科手術，但在軟件工程領域，這條規律高度成立。

這既是一種分享，也是一種自利的學習技巧。如果你覺得自己懂了，試着用最簡單的方式解釋它。你卡住的地方，正是理解淺薄之處。

教學，本質上是在調試自己的心智模型。

13. 那些讓其他工作得以開展的工作，其價值無法估量——卻也無跡可尋

文檔、入職支持、跨團隊協調、流程改進，這些“膠水工作”至關重要。但如果不加節制地承擔，很容易拖慢技術發展並耗盡精力。

給它設定邊界、輪換承擔，並把成果固化為文檔、模板或自動化工具。同時讓這些工作以“影響力”的形式被看見，而不是被當成性格特質。

無價又隱形，對職業發展而言是危險組合。

14. 如果你贏下每一次爭論，往往意味着在積累沉默的阻力

當我“贏”得太輕鬆時，通常説明出了問題。人們停止反駁，並非被説服，而是放棄溝通。他們會在執行階段表達分歧，而不是會議上。

真正的對齊需要時間，需要理解不同視角、吸收反饋，有時還要公開改變自己的看法。

短期“我是對的”的快感，遠不如長期與願意合作的人一起構建現實。

15. 當指標成為目標，它就失去了衡量意義

任何暴露給管理層的指標，最終都會被“優化”。這並非惡意，而是人性使然。

統計代碼行數，就會得到更多代碼；統計速度，就會看到被抬高的預估。

更成熟的做法，是每個指標都配對使用：一個衡量速度，一個衡量質量或風險，並堅持看趨勢，而非迷信閾值。目標是洞察，而非監控。

16. 承認“不知道”，比假裝知道更安全

敢於説“不知道”的資深工程師，並非示弱，而是在創造安全感。領導者承認不確定性，會讓團隊覺得提問是被允許的。反之，人人裝懂，問題只會被掩蓋，直到爆炸。

我見過最資深的人從不承認困惑，也見過由此帶來的傷害：問題無人提出，假設無人質疑，初級工程師保持沉默。

示範好奇心，才能帶來真正學習的團隊。

17. 你的人脈，比任何一份工作都長久

職業早期，我專注於工作本身，忽視了人際關係。回頭看，這是個錯誤。那些投入關係建設的人，無論在公司內外，都持續受益數十年。

他們更早聽到機會，更容易搭建橋樑，更常被推薦角色，也能和長期建立信任的人一起創業。

工作會結束，人脈會延續。用好奇與慷慨對待它，而非交易式算計。

真正離開時，往往是關係為你打開了門。

18. 多數性能提升，來自刪除工作而非增加聰明度

系統變慢時，人們本能地去加緩存、並行、複雜算法。有時這確實有效。但我見過更多提升，來自一句話：“哪些計算根本不需要做？”

刪掉不必要的工作，幾乎總比把必要工作做得更快更有效。最快的代碼，是從未運行的代碼。

在優化之前，先問一句：這件事是否應該存在。

19. 流程的意義在於降低不確定性，而不是製造留痕

好的流程讓協作更順暢、失敗成本更低。糟糕的流程只是官僚表演，用來在出問題時分配責任。

如果你説不清流程如何降低風險或提升清晰度，那它多半隻是負擔。

當人們花在記錄工作上的時間超過做工作的時間，説明系統已經嚴重失衡。

20. 終有一天，時間會比金錢更值錢

職業早期，用時間換錢是合理的。但某個階段開始，計算方式會反轉，你會意識到時間不可再生。

我見過資深工程師為下一次晉升耗盡精力，只為多幾個百分點的收入。有人成功了，也有人事後懷疑是否值得。

關鍵不在於不努力，而在於清楚自己在交換什麼，並有意識地做出選擇。

21. 沒有捷徑，但有複利

專業能力來自刻意練習：略微超出當前水平、反思、重複，多年如一日，沒有速成版。

樂觀的一面在於：當學習帶來新選擇，而非零散知識時，它會產生複利效應。寫作追求清晰而非流量，構建可複用的基礎模塊，把踩過的坑整理成手冊。

把職業當作複利而非彩票的人，往往能走得更遠。

最後的想法

二十一條看似很多，實則歸結為幾點：保持好奇、保持謙遜，記住工程工作的核心始終是人——你服務的用户，以及與你並肩的同事。

工程師的職業生涯足夠長，可以犯下許多錯誤，依然取得不錯的結果。我最敬佩的工程師，並非從未犯錯的人，而是那些從錯誤中學習、分享所得、持續投入的人。

如果你正處在早期階段，請相信它會隨時間變得愈發豐厚；如果你已經走了很遠，希望其中一些能與你產生共鳴。