本篇文章更新時間：2026/03/05
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
簡單的價值，需要被看見
讀後筆記：從《Nobody Gets Promoted for Simplicity》談工程文化中的隱性歧視
編輯前言：這篇文章一針見血地指出工程團隊的普遍現象：複雜的方案比較容易被看見、被讚賞、被升遷；而真正解決問題、保持簡單的人反而默默無名。
核心觀點 (Key Takeaways)
- 工程文化中往往錯誤獎勵「複雜度」，忽略了「簡單」背後的判斷力。
- 升遷制度、面試流程、設計審查等機制，都在不知不覺中強化「越複雜越厲害」的偏誤。
- 簡單不是天真，而是一種深思熟慮的決策；工程師需要學會讓這種「不被看見的價值」變得可見。
深入解析
文章最打動我的是作者抓住了一種工程日常裡非常真實、卻鮮少被討論的矛盾：寫最少的程式碼、做最精準的事情的人，往往拿不到功勞。
作者用兩位工程師的對比作為切入：
- Engineer A：50 行乾淨的程式碼、兩天上線、六個月零事故。
- Engineer B：三週的抽象層、pub/sub、設定框架、多支 PR 與熱鬧的討論文件。
升遷時，B 的敘事彷彿天生自帶光環，而 A 的貢獻只剩下一句話：「Implemented feature X」。
「你無法為沒有做的事寫出引人注目的敘事。」
但偏偏，那些「沒有做的事」，常常才是最重要的決策。
為何複雜看起來更聰明？
- 面試逼你加更多 box 和 shard
- 設計審查逼你「未雨綢繆」
- 團隊文化偏好大專案、大重構、大架構
我很喜歡原文的一段提醒：
「簡單被低估，是因為我們的系統沒有被設計來聽見它。」
這句話完全道破核心問題：不是大家不想要簡單，而是制度沒有能力看見簡單的價值。
什麼是「未經驗證的複雜度」？
作者不反對複雜。他反對的是：
不是因為問題需要，而是因為文化獎勵，所以被迫加入的複雜度。
這種複雜帶來的成本，往往遠大於工程師當下意識到的。
- 一個抽象層可能比重複的 3 行 code 更難維護。
- 一個 pub/sub 可能比單純的 function call 更難除錯。
- 一個預先設計的設定框架，可能永遠不會有人用。
作者說得非常直白：
「真正的資深不是會更多工具，而是知道什麼時候不需要用。」
如何讓「簡單」變得可見？
這篇文章最實用的部分，就是作者給了清楚的行動指南。
-
描述工作時，把你的判斷寫進去：
將「沒做的事」具體呈現，例如：
「評估三種方案後，確認簡單實作已滿足目前與預期需求，因此省下額外兩週。」 -
設計審查時，不盲從未來需求：
把「現在 vs. 未來」的成本說清楚。 -
工程主管要重寫升遷與設計討論的問題框架：
從「我們是否考慮了 scale？」換成「什麼是我們能出貨的最簡版本？」
這些調整看似微小，但它們重新調整了文化的預設值：
複雜不是默認的好，簡單也需要證據，但應該是起點。
筆者心得與啟發
這篇文章讓我重新思考了一件事：工程文化其實也需要「節制」與「清晰的敘事能力」。
我自己在實務上就看過太多「工程師為了看起來專業而加料」的例子。最後 debug 時痛苦的不是當初寫那些抽象的人，而是接手的人。
另一個啟發是：
簡單不是偶然，而是一種選擇；也是一種責任。
而工程師必須學會的不只是寫好程式碼，還包括：
- 把思考過程明確記錄
- 為少做的事給出充分理由
- 學會為簡單辯護
如果團隊文化聽不見這些價值，那可能不只是升遷問題，而是你需要思考——這是不是適合你的地方？
文章最後提到的呼籲我非常認同：
「如果我們持續獎勵複雜，卻忽視簡單，就別驚訝組織只會愈來愈複雜。」
工程文化的健康程度，從來不是看用了多少框架，而是看團隊敢不敢說：「不用這個也可以」。
這篇文章正是提醒我們：
真正的工程成熟，是把複雜留到真正需要的時候。