講別的話題，都讓企業人士興趣缺缺，當你提到最新技術或是競爭對手產品，你就可以看到老闆們開始玩手機，也不知道在看些什麼，可能是兩個女人對著貓咪鬼哭神號的梗圖、還是新的限量款跑鞋之類的，但只要提到成長，就立刻讓會議室裡頭瀰漫起一股腎上腺素與睪丸酮的亢奮氣味。老闆們還會自以為謙遜地標榜「我們不自許成功，而是追求成長」 — 好像這個世上真的會有毫無限制、永不停歇的成長，而且相信這一套，就一點都不像神經病。
所以你就發現，這年頭我們沒有品質駭客、沒有價值駭客、沒有幸福或是企業良心的駭客，甚至沒有法遵駭客。我們有什麼？只有成長駭客。我們需要的 Mindset，就是 Growth Mindset。
尾牙時聽高層在台上喊著「成長！」，馬上就想到了這一篇。
當年看還覺得都是段子，想不到我們才是戲班子
漸漸發現幫忙解答問題的最佳途徑是先確認脈絡，尤其是同事們直接拋出某個技術問題的時候。
對於 X-Y Problem 的意思如下：
- 有人想解決問題 X
- 他覺得 Y 可能是解決 X 問題的方法
- 但是他不知道 Y 應該怎麼做
- 於是他去問別人 Y 應該怎麼做？
簡而言之，沒有去問怎麼解決問題 X，而是去問解決方案 Y 應該怎麼去實現和操作。
於是乎：
- 熱心的人們幫助並告訴這個人 Y 應該怎麼搞，但是大家都覺得 Y 這個方案有點怪異。
- 在經過大量地討論和浪費了大量的時間后，熱心的人終於明白了原始的問題 X 是怎麼一回事。
- 於是大家都發現，Y 根本就不是用來解決 X 的合適的方案。
X-Y Problem 最大的嚴重的問題就是：在一個根本錯誤的方向上浪費他人大量的時間和精力！
我覺得如果已經「確知」需要某種抽象層來避免很可能發生的需求變動，預先加入這個抽象層是合理的。
然而，若將這類預想進一步擴大實施，每一次剛開始設計就加入一些預先推想的抽象層，這恐怕有個問題：忘了自己並沒有「預測未來的能力」，因而設計出一堆其實根本不會用到的抽象層，只因為擔心未來某種可能（但不見得會出現）的變動。
每一個抽象層都是有成本的，而疊床架屋所衍生的維護成本通常不低，故強調「只有確知需要的時候才加入」。我認為有豐富開發經驗的人應該會比新手更能判斷加入哪些抽象層是必要的，但如果對任何人宣稱運用 OCP 或 SOLID 就能夠「即使增加了三四五六七個功能，還是不會影響到原有程式。」卻沒有提醒加入無謂的抽象層反而會增加日後的維護成本，也不知道這個領域還有 YAGNI 和 KISS 原則，那麼當程式從 green field 進入 brown field，恐怕會碰到很多麻煩。
「設計出一堆其實根本不會用到的抽象層，只因為擔心未來某種可能（但不見得會出現）的變動。」🥲🥲🥲
