快速學習的方法
出社會以來，我一直有個疑問：要當通才還是專才？這個探索過程有很多值得分享的細節，有時間再整理成文章。直到在 CloudMosa 工作的某天，聽老闆說：「通才不是什麼都會一點，而是能在各領域快速成為專才」、「最重要的兩個能力是學得快和完成目標 (Get Sh*t Down)」 (上述非原文，是中文大意)。我才豁然開朗。
最近剛好看到劉謙用「三週零基礎學給愛麗絲」為例，說明如何快速學一個新領域的東西。這是我看過最簡短清楚的說明，推薦一看。
摘要他的說明如下：
- 定非常明確的目標 (會彈給愛麗絲 vs. 會彈鋼琴)：學得快才會有興趣，照基礎慢慢作容易磨掉熱情。
- 拆解：找出完成目標必要學習的部份，將完成目標的步驟拆成多個短時間內可完成的步驟 (認琴鍵位置、練某個段落)
- 刻意練習：每天固定時間針對弱點練習。刻意練習本身有不少書可參考，比方說…《刻意練習》。不想花太長時間看書，可以參考啾啾鞋的摘要。
等完成這目標後，之後察覺有必要補基礎時，一樣用目標導導向的方式回頭補需要的部份。
實戰就是最好的練習
看了劉謙的影片後，讓我理解實戰有效的原因，因為實戰通常會有明確待解的問題，時間也比較緊迫，自然會目標導向思考。
大家都在實戰，為什麼長久下來學習速度會有差異？我猜可能和以下幾點有關：
- 是否常逼自己在學習圈？
- 是否有系統地思考如何解決問題，降低試誤和運氣成份？
舉例來說，我看過很強的高手在 debug 時，思考的時間遠大於碰鍵盤的時間。他會在腦中排演出最合理的解釋，在很複雜的系統裡，很少透過加 debug logs 反復收斂問題範圍，因此減少「編譯、部署、執行、看 log」的時間。長期下來，這種腦內排演的能力也會更強。
我的學習例子
學用 React Native 寫 App
React Native 很紅的時候，我想了解它的特性。剛好有和朋友出遊拆帳的需求 (當時沒順手的拆帳軟體)，所以用 React Native 寫一個，藉這過程大概了解是怎麼回事。
後來工作上需要改 Reactive Native 開發的專案時，比較快上手。
將 Redis 舊資料轉移到 DynamoDB
工作上被指派這個任務，將問題拆解成
- 學會舊資料在 Redis 存取的方法
- 學會開 DynamoDB 新 table 和針對需要格式的寫入方法
- 用簡化的環境模擬轉移的過程 (integration test)，方便開發和除錯
- 在 stage 環境執行
- 在 production 從較不重要的 cluster 開始逐步執行
有了 Redis 和 DynamoDB 部份基礎後，之後透過其它工作補充其它塊知識，然後抽空閱讀一些基礎補完對整體的了解。寫成文章供日後備查 (Redis, DynamoDB)。
中文語意分類
這是十年前在工研院時期的一個長期專案，第一年研究、第二年作產品，後來團隊 spin off 成一家公司。
當時每天固定流程是
- 早上頭腦最清楚的第一小時看 Stanford 線上 machine learning 課程。
- 做專案內容的開發和實驗，記下不懂但短期無法看懂的內容。
當時的資訊比現在少很多，有些不懂的東西會在掃線上課程的過程中學到。
後來要作網站 demo 餐廳食記文章內的重點，有效能上的需求，每天的流程改成
- 白天開發 data pipeline、設計資料庫、開發網站
- 晚上讀 High Performance MySQL。學到有用東西時，回頭改設計。
實作 Block Chain 的 Consensus Algorithm
前公司已有一套 Consensus Algorithm，當時雖然有了第二代的作法，但不確定需花多久才能完成。
我將這個目標拆成多個小步驟，有了明確成果後，比較好估工時，讓上層能判斷是否可執行。
- 自己讀論文，寫成 pseudo code
- 和原作者討論，修改 pseudo code
- 寫成 prototype
- 和既有架構接起來
- 切分工作給團隊成員
針對第一個目標，再拆解成多個子問題。讀論文時針對不懂的部份查網路上的說明，後來發覺 Ethereum 有詳細的文件，大多參考他們的文件。完成主要功能後，再找時間將短期吸收的知識整理成三篇筆記備查。有了這樣的基礎，後來 Facebook 出了 LibraBFT，讀起來就比較順了。
學習的來源
現在資料來源很多，挑適合自己的就好。同樣的主題，看 A 的說明兩遍還是不懂，可以改找 B 的說明，總會找到最適合你的說明。有時不需要太詳細的說明，只要有個概念。
書本、他人筆記 (blogs)、podcast、影片都是不錯的來源，通勤時加減聽 podcast 可能會接收到一些關鍵字。這些媒介的知識密度和資訊量不同，像影片是資訊量最多的 (不只是畫面，講者的語氣、斷句都有助於抓重點)，但知識密度不如書本。有時比較難理解的抽象觀念，用影片比較好理解。有時想快速掌握大致架構，他人的筆記就很有用。不用擔心別人搞錯或自己讀錯，拿多個來源交叉比對，可降低誤解。
若有機會認識該領域的人，和對方問些有用的 keywords，用這些 keywords 容易找到有用的文章。例如最近和 data team 的同事合作，聽他介紹 data pipleline 後，得知 Glue、Athena、Redshift，三個字合在一起加些關鍵字，找到這篇《AWS 資料處理的相關服務》，相當適合現階段我想知道的事。
