技術債只有工程師會痛, 老闆是不會痛的, 因為他根本不知道(或是不在意), 所以refactoring真的要謹慎.
在科技公司的真實職場中，工程師的確並非受聘只是為了寫程式碼而已。作者透過自身以及前同事的經歷指出，公司對於特定技術或個別員工產生的相依性，通常沒有一般認知中的那麼關鍵。作者提到一名同事原本是公司唯一的 .Net 開發人員，掌管許多營利網站的運作；然而當他因新政策不滿憤而離職後，儘管他的缺席短期內帶來問題，但公司很快便以其他技術取代他的貢獻，並順勢廢棄舊有的 .Net 架構。作者自身經驗相似，他開發的客製化 JavaScript 工具、跨瀏覽器測試方法，以及獨家 A/B 測試套件，也都輕易被第三方套件或市場上更為普遍的工具所取代。
作者觀察認為，之所以技術人員與其成果如此易被替換，核心原因在於公司管理者關心的不是特定技術或程式碼本身，而是產品與功能的推出、最佳化與成果展現。他曾經花費大量心力修復系統錯誤和效能問題，卻未得到應有的肯定；但當他製作視覺效果好、易於向高階主管報告的 PowerPoint 提案（如訂閱模式或架構設計概念），往往更容易獲得讚揚，即使它們從未實際進入程式階段。從這觀點來看，實務上撰寫程式碼經常只是達成商業成果的手段之一，而非最終目標。
Hacker News 上的討論，普遍認同作者所言許多組織管理階層的行為確實如作者所述，但也補充了一些不同觀點。不少評論指出，這種現象其實並不限於程式設計行業，各種專業領域也都有類似的問題，專業人員容易認為自己的技能是企業無可取代的核心價值，其實大多數員工的價值都會隨著環境和技術變遷而快速淡化。一名評論者強調，開發者真正的價值不在於特定技術的深度知識，而在於能否有效解決組織當前商業上的需求與問題，這通常不侷限於單一語言或系統。
也有討論者主張，開發人員本身也應該自我定位，避免陷入「技術過於專精」的陷阱，而應著重討論如何最佳化對企業的貢獻。有人指出，企業若對特定技術或人員產生過度的依靠，那表示整個管理者與組織的風險控管與知識轉移有嚴重缺陷。穩健經營的公司會避免單人才依賴 (Single Point of Failure)，並讓整個系統與團隊更具彈性及永續經營的能力。
https://news.ycombinator.com/item?id=43563533