不少的研究指出，人類在學習的一開始，遺忘馬上就緊接在後了，這可能是大腦的一種自我保護機制，清除掉那些不重要、不相關的資訊，為的是避免神經系統的異常而導致的疾病。
這對某些人可能感覺很糟糕，現在技術那麼多，孜孜不倦於學習的程式人，你會擔心學過的細節不斷遺忘嗎？或者把細節遺忘掉，對程式人才是件好事呢？
掌握最小可用集合
我學過不少的程式語言，也接觸過不少的框架與技術，遺忘的細節當然也不少，如果學習了一個新的語言或技術而不去用它，久了自然就會遺忘，即使是我接觸最久而也最熟悉的Java也不例外（其實人類母語久而不用，也會生疏）。
如果現在突然問我，某個泛型語法是怎麼回事，喔！泛型的細節有點多，我不一定馬上答的出來，因為我忘了！然而，如果拿個問題馬上要我用Java寫，基本上應該是沒問題，我可以從還記得的那些可用集合開始，慢慢地把東西實作出來。
好的技術都應該有個最小可用集合，而這應該是讓人容易記憶或能迅速複習，是的，人們避免遺忘的方式之一就是複習，如果技術有這樣的最小集合，就能讓你解決問題時，立即複習而開始使用。也許一開始的做法看來並不聰明，然而東西做得出來，學習每個技術，都應該找出這樣的最小集合，若需要改進實作後的成果，再循著某些管道逐步加入細節來改進。
以程式語言來說，Python在這方面做得不錯，每當我想做些東西時，基本語法加函式，通常就足以解決大半的問題，不太需要修飾器（Decorator）、Meta類別等那些高級玩意兒。
如果想嚴謹一些，我會使用Java，雖然從JDK5之後，Java多了不少的語法細節，不過，那都是後來為了更方便或聰明地解決某些問題，才加上去的，也就是之前不用那些細節，程式也是照寫，如果我真的忘了某些細節，又不得不寫Java的話，那些就足夠了。
從另一個角度來說，如果一個語言或技術，無法讓你找出最小的可用集合，也許是因為它定義的不甚嚴謹，或許是功能性分散而彼此相關性低，甚至是細節上的更新、汏舊週期非常頻繁，基本上不用急著去學習，沒有學習就沒有遺忘這件事。
而且，這類語言或技術，只要清楚問題及解題思路，剩下的通常是那些需要時，再搜尋網路就能解決的技術細節，而且，不同時期搜尋到的細節做法多半不同，這種細節本來就該忘掉。
辨識問題與思路
我剛剛談到了Java的泛型，現在這玩意兒語法上已經很複雜了，因為泛型基本上不是寫給人，而是寫給編譯器看的，它面對的型態檢查問題本質上就非常的多樣化。
然而，我不擔心語法細節遺忘的問題，因為，泛型面對的型態檢查問題也有簡單的，複雜的型態問題是基於前者，而更複雜的問題才又堆疊上去，以前我在學習與使用泛型的過程，曾經辨識過這逐層複雜化的思考方式，因而語法上的細節，就只是單純符號的運用問題罷了。
這也可以用數學公式來比喻，我不知道真正聰明的數學家，是否可記得他們曾看過的所有公式，不過大多數人應該是記不住的，然而，大概會知道每個公式可以用來解決哪些問題，必要的時候搜尋一下網路，就能找到公式。
然而，更重要的，是知道從更基本的公式進行推導的思考方式，如果你能辨識出問題與思路，基本上，也不會在乎目標數學公式是否遺忘了。
反過來說，如果無法辨識問題與思路，通常就只能記憶或複製那些瑣碎的細節，因為你不知道這樣為什麼行得通，也就只能依樣畫葫蘆，在遇上另一個問題時，也就無法察覺它們其實是相似的，只要思路稍加變化就能解決，因而，只能再度尋找另一個瑣碎的細節，久而久之，細節越來越多，腦袋就越來越混亂了，有一陣子很多人抱怨的複製貼上程式設計師話題，就是這樣，而最大的細節來源就是stackoverflow.com了。
談到辨識問題與思路，來看看Monad吧！Monad本身是個極高抽象化的東西，在它之前是Applicative，而更之前最好是能清楚Maybe這類簡單的抽象，如果想基於Monad實作某個功能給別人用，你才要瞭解Monad，如果只是使用程式庫，基本上不用瞭解Monad的細節（好的實作應該要完全隱藏好這些細節），實作Monad很複雜，我現在一定沒辦法馬上想起細節，不過我知道Maybe、Applicative、Monad想解決的問題是什麼，又是怎麼逐層演化出來的。
建立好的知識庫
談到Monad，這是Haskell為了解決純綷與非純綷間溝通而發展出來的抽象，想瞭解它，最好的方式就是從Haskell中學習，我曾經很認真地學習過Haskell，也因此弄清楚過Maybe、Applicative、Monad，還為此寫了《Haskell Toturial》，然後又過了好一陣子，Haskell的語法細節就又忘光光了。
就這方面來說，Haskell並不符合我先前談到有最小可用集合，因為就算是想寫個簡單的文字互動程式，也非容易之事，不過別誤會了，Haskell是非常值得學習的，只不過它的嚴謹性，會讓它因此伴隨著許多不得不有的細節，面對這種值得學習的技術，又想要降低遺忘細節的成本，最好的方式，就是在學習的過程中，為它們建立相關的知識庫。
所幸，如果技術本身非常值得學習，然而有許多不得不的細節，通常，這類技術相對之下會是比較穩定的，其中的許多細節，在假以時日之後仍會適用，因而為它們建立相關的知識庫，會是比較值回票價的投資，必要的時候可以迅速回憶而取用，因為建立知識庫的過程，就是你取用細節的過程。
若再度使用數學公式來比喻的話，能以推導的方式得到某個數學公式是件好事，不過，若能記錄推導過程與結果，日後要使用的時候就可以直接取用數學公式，省去推導的時間，而且用得安心，必要時回顧被記錄下來的推導過程，就能確認是否可變化應用到其他場合。
胡適曾說「發表是最好的記憶」，行有餘力，親手整理並寫下你的知識庫，會是最好的方式，為了要能解釋某個概念、細節，通常你必須非常清楚地辨識出問題與思路，而這些會使得概念、細節、問題與思路之間產生相關性，同時，有不少的研究指出，事物是否會被遺忘，與其聯繫之其他事物有關，聯繫的數量越多，記憶就越容易持續。
當然，我也不是學過的每個東西都留下文件，若能系統性地整理細節來源，像是網路上文件的書籤，或者是遇到問題時可查詢的書本章節，簡短地在某個頁面上附記心得，也是不錯的做法。
獲取知識也要善於遺忘
其實就程式人來說，甚至應該把遺忘視為一件好事，這樣還能持續保有學習的動力，因為在遺忘之後，你的心就能時時對新的事物感到飢渴，甚至因而覺得空虛，因為，程式人本就不該細數曾經擁有的東西，而在遺忘的同時，能獲得更多的東西。
在技術的世界中，知識是以指數以上的方式在成長，將時間花在記憶是種浪費，若善於遺忘細節，才能專注於如何探索知識來源、培養研究能力，若只專注於記憶，往往就只會獲得知識的表象，細節記得多少並不代表什麼，若干時日後留下來的才是真正的獲得，而這些收穫，能讓你在遺忘某些細節之後，快速找回它們，甚至從中產生新的創作。