Hacker News
The article explores how engineering cultures inadvertently reward over-engineering and complexity while failing to recognize the value of simple, efficient solutions in promotion cycles. It provides actionable advice for both engineers and leaders to shift incentives toward rewarding good judgment and the avoidance of unnecessary complexity.
AI 生成摘要
我認為許多工程團隊正被某些因素悄悄破壞，因為過度開發的工程師能寫出引人入勝的晉升敘述，而交付最簡單可行方案的人卻一無所獲。我們必須改變這種獎勵複雜性而非簡約的激勵結構，讓避開不必要複雜性的決策也能被看見並獲得認可。
這篇文章探討了軟體工程界一個普遍卻令人沮喪的現象：過度設計與複雜的方案往往比簡潔的解決方案更容易獲得晉升。作者指出，企業的評估機制傾向於獎勵那些創造了大量抽象層、微服務或可擴展框架的工程師，因為這些工作在晉升報告中顯得更有影響力，而選擇簡單路徑、避免不必要複雜性的工程師，其貢獻往往因其「隱形」而遭到忽視。
在 Hacker News 的討論中，許多資深開發者對此觀點深有共鳴，但也提出了更具層次感的辯證。支持者認為，這種現象源於一種「銷售問題」，複雜性往往被誤認為是專業與前瞻性的象徵。有留言分享了在亞馬遜等大廠的經歷，指出即便透過簡化流程節省了百萬美元，主管仍可能認為這只是「停止浪費」而非「創造價值」。這種文化導致工程師在面試或設計審查中，為了迎合對「擴展性」的盲目追求，不得不畫出更多不必要的架構圖。
然而，另一派觀點則挑戰了「簡潔即正義」的簡化論點。有經驗的工程師指出，所謂的簡單方案有時只是因為忽略了邊緣案例或隱藏的業務邏輯。以薪資計算系統為例，看似簡單的加減乘除可能只涵蓋了九成的情況，剩下的複雜性往往是為了處理法律合規或特殊排班等「本質複雜性」。如果為了追求程式碼的簡潔而犧牲了對需求的完整支援，那並非好的工程實踐，而是對現實問題的逃避。
討論中也出現了關於「本質複雜性」與「偶然複雜性」的區別。社群普遍達成共識：真正的資深工程師應該具備將複雜問題提煉為簡單方案的能力，這需要深厚的經驗與對業務的理解。有留言提到，雖然複雜的架構在短期內看起來很壯觀，但其長期的維護成本——即所謂的「認知負荷」——往往由整個團隊承擔。晉升機制若只看產出的規模而不看維護的難易，實際上是在鼓勵工程師向未來借貸技術債。
最後，部分留言者提出了務實的應對之道。他們認為，既然這是一個銷售問題，工程師就必須學會用商業語言來包裝「簡潔」。與其只寫「實現了某功能」，不如描述為「在評估了多種複雜架構後，選擇了最穩健的方案以降低運維風險並提升交付速度」。這種將「不去做某事」轉化為「主動決策」的敘事方式，是讓簡潔價值在現有企業體制中被看見的關鍵。