🔧 阿川の電商水電行
引言
在 Google 工作多年負責 Chrome，目前擔任 Google Cloud AI 董事的 Addy Osmani（阿迪·奧斯馬尼）所撰寫的 《在 Google 工作 14 年的 21 個教訓》 深具趣味，因此我根據個人理解整理了該文。
奧斯馬尼還以在 O'Reilly 等地方撰寫多部技術書籍而聞名，並長期為 Web 開發社群貢獻的工程師。
分享這些內容，是因為我自己自從其他工程師分享經驗中獲得了無法估量的好處。這是我將這份恩情傳遞下去的嘗試。
這篇部落格所表達的，不是技術性提示，而是作為工程師如何無壓地持續努力的實用智慧。
本文並非翻譯，而是我在閱讀原文後的解釋與整理。
因為有些部分以日趨感的方式表達我的感受，所以想要體會原文精髓的讀者，還是建議去閱讀原文。這個話題在日文文章 中也引起了轟動。為了避免誤解，在有效的關鍵點上，我使用了 ChatGPT 確認原文的語氣等。
1. 從「用戶的困惑」而非技術開始
最高的工程師對解決用戶的問題有著強烈的執著。
（最高的工程師是執著於解決用戶問題的）
學會了新技術後便會想要使用它，但真正產生價值的應是「用戶有什麼問題？」而非「這項技術該如何使用？」。不妨多觀察用戶的行動與意見。
真正理解問題的工程師，會發現簡潔的解決方案往往比人們預想的還要簡單。
2. 贏得辯論不意味著成功
你可以在技術討論中贏得每一場辯論，但卻可能失去專案。
（技術性辯論中贏得全勝，卻可能輸掉專案）
雖然贏得辯論，但若無法獲得團隊合作，專案仍無法進行。與其證明「自己是正確的」，不如優先讓大家一起找到更好的答案。
「擁有強烈的意見，但要放得輕」—這並非因為缺乏信心，而是在不確定的情況下做出的決策不應該成為個人的身份。
3. 先行動再思考
你可以編輯壞的頁面，但無法編輯空白頁。
（壞的頁面可以編輯，但空白的卻不能）
持續思考完美設計而不作任何實體，不如先行動即便有些草率。反饋所帶來的學習遠比心中的討論重要。「先行動→修正→提升」是關鍵。
行動能帶出清晰度，而無所作為則無法產生任何。
4. 寧可選擇「可讀性」而非「聰明的代碼」
你的代碼是給在故障時凌晨兩點維護的素未謀面的人的策略備忘錄。
（你的代碼是寫給凌晨兩點維護它的陌生人的策略備忘錄）
聰明的代碼或許看起來很高明，但未來深夜負責故障時的應是別人。能一瞬間理解的代碼才是真正的專業。
軟體工程即是當「時間」與「其他程序員」相互作用的過程。明確性並非風格的偏好，而是降低運行風險。
5. 引入新技術如同「負債」
「最適合工作的工具」往往是「多個工作中最不壞的工具」。
（「最佳工具」往往是「多任務中最不糟糕的工具」）
最新技術令人興奮，但每當引入都會承擔「學習成本」「招聘困難」「故障時缺乏信息」等負債。僅集中於真需要的地方。其他的用穩定技術就足夠。
這並非是說「不要創新」。而是「在你能獲得報酬的地方去創新」，其他地方則可保持平凡。平凡的事情往往有已知的失敗模式。
6. 如果無法被傳遞的好工作就如同不存在
如果在你不在的地方沒有人能表達你的影響力，那麼你的影響就僅僅是選擇性的。
（如果沒有人能在你不在的時候清楚描述你的成就，那麼你的成就是選擇性的）
「寫好代碼就會受到認可」是個幻想。若在會議中沒有人能說明你的價值，那麼你就無法被評價。這不是自誇，而是讓價值可視化。
這不是自我宣傳，而是創造一個讓所有人，包括自己，都能「閱讀」到的價值鏈。
7. 最佳代碼是「未寫成的代碼」
在建造之前，徹底考慮「如果我們不這麼做，會發生什麼？」
（在你動手之前，深思「如果我們不這麼做，會怎樣？」）
你寫下的每一行代碼都是未來錯誤、維護及解釋的對象。動手之前，要培養「這真的必要嗎？」的習慣。
問題不在於工程師不能寫代碼，而是他們寫得太好了，以至於忘記問是否真的有寫的必要。
8. 大規模時，錯誤也會找上用戶
當擴大規模時，即使是錯誤也會有用戶。
（擴大規模時，就算是錯誤也會有用戶）
用戶數量增加時，總會出現不符合預期的使用情況。也會有人基於錯誤或偏見進行操作。維護兼容性即是良好的產品開發。
不能將兼容性作為「維護」，新功能視為「真正的工作」。兼容性是產品。幾乎所有的「API 設計」實際上都是「API 退役」。
9. 行動緩慢的團隊，其實是存在「不合拍」的問題
大部分的慢行實際上是認知失調。
（大多數的緩慢實際上是對齊失敗）
專案進度緩慢時，通常會認為「人手不足」「能力欠缺」，但真正的問題在於團隊內方向與優先級不一致。資深工程師需將更多時間花在「對齊認識」而非「速度」。
資深工程師多花時間以明確方向、接口及優先級，而非單純加快代碼撰寫，因為實際的瓶頸在這裡。
10. 對於無法改變的事物不需操心
在無法改變的事情上耗費的精力，正是從可以改變的事情上竊取的。
（對於無法改變的事情花費的精力，是從你可以改變的事情中奪走的）
組織變革、決策、市场变化……有太多的事情是無法控制的。專注於自己能控制的事物才是保持理智的秘訣。
這不是被動接受，而是戰略性的專注。組織重組是否發生無法控制，但工作的質量、回應方式以及學習的內容卻是可控的。
11. 抽象化只是將複雜性「延後」
抽象化不會消除複雜性。它只是將複雜性移動到你執行呼叫時。
（抽象化無法消除複雜性。它只是將複雜性推遲到你當值的一天。）
便利的庫或框架是「不必了解內部實現」的賭注，但總有一些內容難免漏掉。為了萬一好時，了解底層的幫助至關重要。
資深工程師即使堆疊層級越高，仍需持續學習「低層」的知識。這不是出於懷舊，而是對抽象化失敗，以及在凌晨三點獨自面對系統的敬意。
12. 教導他人有助於升華自身理解
教學是對你思維模型進行偵錯。
（教導是對自己心智模型的偵錯）
當你試著向別人解釋時，常能發現自己理解的模糊部分。輸出是最好的輸入。無論是部落格、文檔，都可以試著解釋一下。
如果你認為自己理解了某個東西，那就試著將其簡單地解釋出來。你會發現的困難點即是你理解的薄弱環節。
13. 「幕後的工作」雖重要，但若不被看見則難以被評價
寶貴而看不見的組合對你的職業生涯來說非常危險。
（珍貴但不被看見，對於職業生涯來說是種危險的組合。）
文件整理、新人訓練、團隊協調……這些不可或缺，但容易被視為「好心好意」。必須以實質成果呈現，讓影響可視化來避免對職業生涯的負面影響。
進行時間規劃，實施輪換，將文件、模板或自動化成果轉化為可見的成果，而非性格特質，應以影響力形式呈現。
14. 如果常常在辯論中贏，那麼在背後可能會引起反感
人們停止反對不是因為你說服了他們，而是因為他們放棄了。
（人們停止與你爭辯不是因為他們說服了你，而是因為他們放棄了艱難的奮鬥。）
如果你經常在辯論中勝出，那麼你也要小心。對方很可能並非信服，而是放棄了。不滿並不會在會議中表現出來，而是會表現在「工作方式」上。
短期內「自己是正確的」感覺，遠不及長期與熱心合作的夥伴創造作品來得重要。
15. 一旦將指標變為「目標」，其意義便會消失
如果你追蹤代碼行數，行數就會增加。如果你追蹤速度，估算就會膨脹。
（如果你追踪代码行数，行数会增多。如果你关注速度，估算也会飙升。）
人會去優化被測量的事物。追蹤單一指標必會出現失真。同時查看速度與品質的兩個指標是非常重要的。
所有的度量要求都需要匹配。提供一個速度指標以及另一個品質或風險指標。不要崇拜閾值，而是解讀趨勢。目標不在於監測，而在於獲得洞見。
16. 能說出「不知道」的事能使團隊更安全
當一位領導承認不確定性時，這表示其他人也可以做同樣的事。
（當一位領導承認不確定性時，這表明其他人可以做同樣的告解。）
若資深感到虛張聲勢，年輕的就無法提出問題。創造一種可以說出「不知道」的氛圍是領導者的工作。
我曾經見過不承認混亂的資深團隊。問題不會被提出，假設不會受到挑戰，這使得年輕成員以為所有人都能理解並保持沉默。
17. 網絡關係會持久於任何工作
你的工作無法永恆，但你的人脈可以。
（工作不是永遠的，但人際網絡是。）
若專注於工作而忽略建立聯繫，將來會後悔。建立的關係往往能在多年後帶來機會。善待人以真誠和好奇心來建立連結。
那些在關係上投入的同事會首先聽取機會，更快地搭橋，並推薦職位，與他們多年來建立信任的夥伴共同創業。
18. 加速的方式是增加「不做的事情」
最快的代碼是從不執行的代碼。
（執行的最快代碼是從不運行的代碼。）
當希望加速緩慢的系統時，我們常會想增加「緩存」或「並行化」。但最有效的仍然是「這個處理真的需要嗎？」從根本上削減。
刪除不必要的工作，幾乎總是對提高工作效率影響更大，並且其影響超過加速有用的工作。在進行優化前，務必要問這個任務是否真的應該存在。
19. 流程存在不是為了「安心」，而是為了減少「不確定性」
如果你無法解釋某個流程如何降低風險或增加清晰度，那麼它的存在就只是一種額外的負擔。
（如果你无法说明某一过程如何减少风险或提高清晰度，那么它可能只是额外的开销。）
隨著「以防萬一」增加的規則和流程，最終會無法察覺地拖慢團隊的發展。需要重新評估那些無法解釋目的的流程。
最佳的流程應該便利調整並降低錯誤成本，而最糟的則屬於官僚式的表演—這些流程存在並不是為了幫助，而是在失敗時尋找責任的出路。
20. 有一天「時間＞金錢」會到來
了解你所交易的，並有意識地進行這一交換。
（知道你正在交换什么，并有意识地进行这种交易。）
在職業生涯早期，我們經常將時間換取金錢。但在某些時刻，價值觀將發生反轉。為了升遷而疲憊不堪的前輩後悔：「這真的值嗎？」認識到自己所付出的，清楚而慎重地做出選擇。
答案不是「別努力」。而是「了解所交換的內容，並有意識地進行這一交易」。時間是一種不可再生的資源。
21. 路徑沒有捷徑，但存在「複利」
將職業視為複利而非彩票的工程師，最終會走得更遠。
（將自己的职业视为复利而不是彩票的工程师，最终往往走得更远。）
與其追求一蹴而就的轉機，不如每日學習逐步積累。編寫內容、搭建可重用的機制、從失敗中學習。這些雖平凡，但卻會隨著時間產生複利的效應。
學習並不僅僅是新的知識，而是在產生新選擇的過程中形成的複利。寫作—不是為了吸引注意，而是為了清晰度，並將自己的經驗累積到一個資料庫中。
總結
我從這篇部落格中感受到特別重要的幾點如下。
保持好奇心，保持謙虛，同時記得工作始終是服務於人。
（保持好奇心，保持谦虚，记住工作总是与人为本。）
這 21 條教訓最終歸結為以下三點
- 保持好奇心 — 持續求知
- 保持謙虛 — 能夠說「不知道」，並共同尋找答案
- 記住人性 — 為用戶而作，與團隊共同作業
我最佩服的工程師不是總是能找到正確答案的人，而是那些從錯誤中學習、分享所發現的內容，並持續參與的人。
（我真正敬佩的工程师不是那些总能找到正确答案的人，而是那些从错误中学习、分享发现并坚持出现在工作现场的工程师们。）
這 21 條教訓讓我意識到「這樣的思維方式也許值得一試！」「確實這很重要」，也促使我思考如何調整自己的工作方式。
特別是第二點「擁有強烈的意見，但要放得輕」也是一個全新的觀點。
最終，我感覺到這些教誨都在告訴我們「如何能夠不把自己耗盡，並能長期地從事這項工作」。
當然，並不需要一味接受全部，只需要挑選那些對自己有影響的部分，並與自己的方式相結合即可。
引用
原文: 21 Lessons From 14 Years at Google - Addy Osmani
※ 本文章旨在介紹和解釋原文。詳細內容請參考原文。
參考文章
這裡的日文文章相當易懂。
原文出處：https://qiita.com/Sakai_path/items/8ae1e34e012a53aa8d1b
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
