原文：Nobody Gets Promoted for Simplicity by Terrible Software（2026 年 3 月）

沒有人因為簡單而升職

---

「簡潔是一種了不起的美德，但要實踐它需要苦功，要欣賞它需要教養。但現實是，複雜的更好賣。」 —— Edsger Dijkstra

我覺得有件事正在悄悄搞壞許多工程團隊。在面試裡、在升遷文件裡、在design review裡：把系統搭得越複雜的工程師，越有故事可講；但那個找出最簡單解法、直接交付成果的人，到頭來什麼都沒有。

這當然不是有意為之。沒有人會坐下來說：「讓我們確保那些把東西過度工程化的人拿到晉升。」但當公司用錯誤的方式評估工作，這種事就會發生，而且已經一再發生。

---

想像同一個團隊裡兩位工程師。工程師 A 拿到一個功能需求，她分析了問題、考慮幾個方案，選了最簡單的那個：直接的實作，大約五十行程式碼，易讀、易測試，下一個人接手也看得懂。它能跑。她幾天內完成交付，繼續往前走。

工程師 B 拿到類似的功能需求。他同樣分析了問題，但看到的是一個讓系統更「健壯」的機會。他引入了一個新的 abstraction layer，在元件之間建了 pub/sub 通訊，還加上一個configuration framework，讓功能「可因應未來需求而擴展」。這花了三週，有好幾個 PR，他分享設計文件時大家都貼了滿滿的讚嘆 emoji。

到了晉升季，工程師 B 的工作成果被寫進了晉升文件：「設計並實作可擴展的event-driven architecture，引入可重用的abstraction layer並獲多個團隊採用，建立configuration framework以支援未來擴展。」這幾乎就是 Staff+ 的語氣。

工程師 A 的工作呢，幾乎無從下筆。「實作了功能 X。」三個字。她的工作更好，但她把它做得太簡單，因此變得為不足道了。你沒辦法為你沒建的東西寫出一段有說服力的敘述。沒有人因為阻止了複雜而升職的。

複雜看起來很聰明。不是因為它真的是，而是因為我們的職場系統就是被這樣設計來獎勵它的。而這個激勵問題不是到晉升時才開始，在你進公司以前，它就已經在了。

想想面試。你在做系統設計題，提了一個簡單方案：單一 database、乾淨的 API，也許加一層 cache。面試官問：「可擴展性呢？如果有一千萬個用戶怎麼辦？」於是你加服務、加 queue、加 sharding，在白板上畫越來越多方塊。面試官終於滿意了。

你剛學到的是：複雜讓人印象深刻。簡單的答案不是錯的，只是不夠有趣。你可能把這個教訓帶進後來的整個職涯。當然，面試官有時確實有理由追問規模，他們想看你在壓力下的思考方式，看你是否理解distributed systems。但當應試者的收穫是「簡單不夠」，就有問題了。

設計審核時也是一樣。工程師提了乾淨、簡單的方案，卻被問到「我們不應該先做好未來擴展嗎？」於是他回去加了現在根本不需要的層次，為還沒發生的問題建了 abstraction，為沒有人要求的需求留了彈性。不是因為問題需要，而是因為整個會議室在期待。

我見過工程師（我自己也是其中一個）為了避免重複幾行程式碼而建立 abstraction，結果產出的東西比原來的複製貼上難懂得多，也難維護得多。每次都覺得這樣做是對的。程式碼看起來更「專業」，更有工程感。但用戶沒有更快收到功能，而下一個來改程式碼的人要花半天搞清楚那個 abstraction，才能動任何東西。

說清楚一點：有時候複雜是對的選擇。如果你在處理幾百萬筆交易，你可能真的需要distributed systems。如果有十個團隊在同一個產品上工作，你大概需要service boundaries。問題夠複雜，解法也應該跟著複雜！

問題不是複雜本身，而是沒有賺到的複雜。「我們遇到 database 瓶頸，需要 sharding」和「我們三年後可能遇到 database 瓶頸，所以現在先做 sharding」是完全不同的兩件事。

有些工程師懂這件事。看他們的程式碼和架構，你的反應是「對啊，當然這樣做」。沒有魔術，沒有炫技，沒有任何讓你覺得看不懂是正常的東西。這就是重點所在。

真正的資深之路，不是學更多工具和模式，而是學會什麼時候不用它們。任何人都能加複雜度。把它省掉，需要經驗和自信。

---

那我們實際上能做什麼？說「keep it simple」很容易，改變激勵結構要難得多。

如果你是工程師，先學會讓簡單的工作變得可見。工作不會自己說話，不是因為它不好，而是因為大多數職場系統根本沒有設計來接納這種聲音。

從你描述自己工作的方式開始。「實作了功能 X」說不了什麼。但「評估了三個方案，包括event-driven architecture和自定義abstraction layer，判斷直接實作能滿足所有當前及預期需求，兩天內上線，六個月零事故」。這是同一個簡單的工作，只是用一種能捕捉背後判斷的方式描述它。決定不建某個東西，本身就是一個決定，而且是重要的決定。把它記錄下來。

在design review中，當有人問「我們不應該先做好擴展性嗎？」，不要就這樣讓步去加那些層次。試試這樣說：「這是我們之後如果需要可以加的成本，這是我們現在加進去的代價。我認為應該等。」你不是在反駁，而是展現你做了功課。你考慮過複雜度，選擇不走那條路。

也可以和主管聊：「我想確保我的工作記錄方式，能反映我做的決策，不只是我寫的程式碼。能不能談談下次評估時要怎麼框架？」大多數主管會感謝你，因為你讓他們的工作更容易。你給了他們為你發言所需要的語言。

你做完這些，如果團隊還是只晉升那個蓋了最精巧系統的人，這本身也是有價值的資訊。它告訴你你在哪種文化裡工作。有些文化真的重視簡潔，有些說重視，但獎勵的是相反的東西。如果你在第二種裡，你可以選擇配合玩，或者找一個真正認可好判斷力的地方。但至少你清楚自己在哪。

如果你是工程主管，這個問題比誰都更是你的責任。你設定了激勵結構，不管你有沒有意識到。問題是，大多數晉升標準基本上是設計來獎勵複雜度的，即使它們並不想如此。「影響力」靠規模和範圍來衡量，很多時候確實合理。但他們避開的東西，也應該算進去。

所以從改變你問的問題開始。在design review裡，與其問「我們有沒有想過擴展性？」，試試：「我們能交付的最簡單版本是什麼？哪些具體的信號會告訴我們需要更複雜的方案？」這一個問題就能改變遊戲規則：讓簡單變成預設值，讓複雜去承擔舉證責任，而不是反過來。

在晉升討論中，當有人的晉升文件基本上是一串聽起來很厲害的系統清單，要反問：「這些真的都必要嗎？我們真的需要 pub/sub，還是它只是看起來不錯？」而且當團隊裡有工程師交付了乾淨、簡單的成果，幫他們寫出那個敘述。「評估了多個方案，選擇了最簡單的解決問題的方式」是一個有說服力的晉升案例，但前提是你真的把它當成這樣對待。

最後一件事：注意你公開讚揚什麼。如果團隊頻道裡的每一個讚美都給了那個大型複雜專案，那就是大家會去優化的方向。開始表揚那個刪了程式碼的工程師，那個說「我們還不需要這個」而且說對了的人。

到最後，如果我們一直獎勵複雜、忽視簡潔，不應該感到驚訝，我們得到的正是如此。解法其實不複雜。這大概就是重點所在。