有些人會覺得：「我那麼菜，哪有什麼可以分享？」。但其實是有的，因為你總是會找到比你更菜的人。你學程式一個月，總是可以找到學程式 15 天的人，我甚至覺得程式入門這種東西，應該由「新手」來教「超級新手」，為什麼？因為那些新手可能一個禮拜前跟你一樣卡在迴圈，不知道迴圈到底可以做什麼，但是這禮拜他就領悟了。我覺得這時候是最適合教學的時機，因為他們還記得「當初卡住的那種心情」，他們是最懂你心情的人。
像我接觸程式這麼久，你問我當初第一次學遞迴的時候是什麼感覺，我真的完全忘了。接觸久了以後，寫程式就像吃飯喝水一樣，你問我怎麼吃飯怎麼喝水，我只能跟你說：「阿不就把嘴張開吃飯嗎？這個要怎麼教？」。
所以儘管你覺得你很菜，你還是可以試著寫下自己學習程式的心得，以及自己卡關的地方跟之後怎麼解開的方法，相信一定會對比你更菜的人有幫助。像我現在寫的很多文章技術深度也很淺，但還是幫助了很多人一樣。
有天我們會無法理解菜鳥朋友們到底都在想些什麼，而能幫助他們的，其實是菜鳥時期的我們。所以即使寫出了很菜的心得、分享、筆記，也許都會在某些時候，幫助到正在經歷同樣時期的朋友吧。
用 Heptabase 思考人生問題與一篇寫了一年還寫不完的文章 - Huli
喜歡這篇把思考過程逐步整理出來的感覺。
尤其在「希望活得快樂」的時候，反過來問「那怎樣會不快樂？」的思路很值得參考。曾經做過類似的嘗試，但做了可能會快樂的事情實在列不完，思路就發散出去了。
或許這也該保持「如果我知道我會死在哪裡，我就永遠不去那個地方。」的心態去規劃吧。
另外，這篇也展現了我覺得 Heptabase 一個很棒的點：可以在白板上思考、整理，讓想法往外生長，並把途徑跟過程保留下來。
讓我想起某段看過的對話：
『哦，所以這張紙就是你思考的紀錄』
「這不是我思考過程的紀錄。它們就是我的思考過程。」
講別的話題，都讓企業人士興趣缺缺，當你提到最新技術或是競爭對手產品，你就可以看到老闆們開始玩手機，也不知道在看些什麼，可能是兩個女人對著貓咪鬼哭神號的梗圖、還是新的限量款跑鞋之類的，但只要提到成長，就立刻讓會議室裡頭瀰漫起一股腎上腺素與睪丸酮的亢奮氣味。老闆們還會自以為謙遜地標榜「我們不自許成功，而是追求成長」 — 好像這個世上真的會有毫無限制、永不停歇的成長，而且相信這一套，就一點都不像神經病。
所以你就發現，這年頭我們沒有品質駭客、沒有價值駭客、沒有幸福或是企業良心的駭客，甚至沒有法遵駭客。我們有什麼？只有成長駭客。我們需要的 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，恐怕會碰到很多麻煩。
「設計出一堆其實根本不會用到的抽象層，只因為擔心未來某種可能（但不見得會出現）的變動。」🥲🥲🥲
我：天哪真不知道這些前輩去哪找這麼多優質技術文章
同樣也是我：這怎麼讀得完= =
checkcheckzz / system-design-interview - Github
上面就是我看到這 Repo 的感想。現在我們有更多讀不完的技術部落格了
