追求簡約沒人會讓你升職

背景

這篇文章探討了軟體工程界一個普遍卻令人沮喪的現象：過度設計與複雜的方案往往比簡潔的解決方案更容易獲得晉升。作者指出，企業的評估機制傾向於獎勵那些創造了大量抽象層、微服務或可擴展框架的工程師，因為這些工作在晉升報告中顯得更有影響力，而選擇簡單路徑、避免不必要複雜性的工程師，其貢獻往往因其「隱形」而遭到忽視。

社群觀點

在 Hacker News 的討論中，許多資深開發者對此觀點深有共鳴，但也提出了更具層次感的辯證。支持者認為，這種現象源於一種「銷售問題」，複雜性往往被誤認為是專業與前瞻性的象徵。有留言分享了在亞馬遜等大廠的經歷，指出即便透過簡化流程節省了百萬美元，主管仍可能認為這只是「停止浪費」而非「創造價值」。這種文化導致工程師在面試或設計審查中，為了迎合對「擴展性」的盲目追求，不得不畫出更多不必要的架構圖。

然而，另一派觀點則挑戰了「簡潔即正義」的簡化論點。有經驗的工程師指出，所謂的簡單方案有時只是因為忽略了邊緣案例或隱藏的業務邏輯。以薪資計算系統為例，看似簡單的加減乘除可能只涵蓋了九成的情況，剩下的複雜性往往是為了處理法律合規或特殊排班等「本質複雜性」。如果為了追求程式碼的簡潔而犧牲了對需求的完整支援，那並非好的工程實踐，而是對現實問題的逃避。

討論中也出現了關於「本質複雜性」與「偶然複雜性」的區別。社群普遍達成共識：真正的資深工程師應該具備將複雜問題提煉為簡單方案的能力，這需要深厚的經驗與對業務的理解。有留言提到，雖然複雜的架構在短期內看起來很壯觀，但其長期的維護成本——即所謂的「認知負荷」——往往由整個團隊承擔。晉升機制若只看產出的規模而不看維護的難易，實際上是在鼓勵工程師向未來借貸技術債。

最後，部分留言者提出了務實的應對之道。他們認為，既然這是一個銷售問題，工程師就必須學會用商業語言來包裝「簡潔」。與其只寫「實現了某功能」，不如描述為「在評估了多種複雜架構後，選擇了最穩健的方案以降低運維風險並提升交付速度」。這種將「不去做某事」轉化為「主動決策」的敘事方式，是讓簡潔價值在現有企業體制中被看見的關鍵。

延伸閱讀

• Negative 2000 Lines of Code: 講述 Bill Atkinson 在開發 Lisa 系統時，如何透過重構減少了兩千行程式碼，卻在公司進度報告中引發趣聞的經典故事。
• No Silver Bullet (Fred Brooks): 探討軟體工程中本質複雜性與偶然複雜性的經典論文。
• UNIX Pipe Philosophy: 關於如何透過組合簡單工具來處理複雜任務的設計哲學。