Addy Osmani 從 Google 軟體工程師職涯中學到的 21 堂課

發表時間: | 分類: 閱讀筆記 | 字數:683 | 閱讀時間:1分鐘

創作者:Addy Osmani

文章:21 lessons I wish I'd known earlier in my software engineering career

很喜歡這篇!字字珠璣,特別推薦給工程師們閱讀!

以下節錄我特別喜歡的句子和我的小心得:

Strong opinions, weakly held.

複雜的討論都牽扯多面向的事實與不確定性。常常討論只是為了對齊想法,在現況下找到可接受的方向,而不是爭論某單一事項的正確與否。

Strong opinions, weakly held」精準描述在不確定性高的情境下,根據目前已知作下的結論並不能保證正確,應該根據後續的變化與新資訊作調整,不要把過往做出的決策當作像是自己的身分認同一樣去過度保護它。

Momentum creates clarity. Analysis Paralysis created nothing.

如果不是重大、無法反悔的決策,應該趨向於先行動。行動後得到的反饋使未來更清晰,重複的分析癱瘓並不會帶來任何好處。

Innovate only where you're uniquely paid to innovate. Everything else should default to boring, because boring has known failure modes.

在創造價值的地方創新,在其他地方選擇無聊的解法,因為無聊的解法已經累積很多已知的經驗。

Abstractions don't remove complexity. They move it to the day you're on call.

很喜歡這句😆。

認同適度的抽象化可以減輕在開發時的認知負擔,但當包裝的太多時,在解決問題時就難以輕易看到真相。需要在腦中不斷建立底層運作的模型。

Teaching is debugging your own mental models.

教導他人是學習的秘笈,如果沒辦法教別人就是自己了解的還不夠透徹。

When a measure becomes a target, it stops measuring.

一直謹記「Goodhart's Law: When a measure becomes a target, it ceases to be a good measure」只要一件事變成測量的指標,人們就會不自覺的去優化它,使這個指標失去意義。

這篇文章提供了一個出口,成熟的工作者對於每個指標會添加另一方面的指標避免盲區,通常是速度和品質(或風險)的相對。

重點要從指標的趨勢產生洞察,而不只是用單純的數值來監控。

Most performance wins come from removing work, not adding cleverness.

有點像是在《2025 年度回顧》提到的「厭倦最佳化」。在最佳化之前,應該先想想這件事有沒有必要做或是被最佳化。

Know what you're trading, and make the trade deliberately.

在人生的不同階段中,錢和時間的相對價值會改變,確定你目前對於工作的交易依然還合理。

#software-engineering

相關文章推薦