20 小時真能學會所有事？－－《學得快才會想學！》
有次在 YouTube 上耍廢的時候，偶然點入了一個 TED 影片，是喬許．考夫曼的《只要 20 小時就能學會任何事》。做為一個以自學為信仰（？）的人，對這種事情實在感到好奇，20 小時真的夠嗎？如果夠的話，那應該一堆人會做很多事情吧？實際上，確實多數人都會不只一樣技能，像是鋼琴、繪畫、程式設計、跳舞、歌唱等等的，這些技能我們都能夠輕易地舉出一些朋友，甚至有許多人具有複數技能。或許，學會一件事真的並不難。
說到學習，一萬小時定律大概是最常被提及的，彷彿好像什麼技能不做到一萬小時就沒有用。但這裡卻又冒出 20 小時？其實只要細想，就能察覺其中的差別。我們並不會常常想要在某個領域出人頭地，即便是自己的專業也一樣，反而我們更常有的想法是夠用就好。不求能夠登上大巨蛋，但在 KTV 的時候不要被笑就好；不求成為下個…畢卡索，只要能夠畫出所見的東西就好。既然沒有要頂尖，那一萬小時就不一定是必要的。
取而代之的是二十小時定律，這個定律的背後非常簡單。如果回想過去的學習經驗，你應該可以發現在一個相對短的期間，水準會突然的向上飆升，在之後的某個時間點突然發現自己已經成長到某種地步，這個飆升就是我們所追求的。如果能製造這個飆升，用 20 小時學習一件事就有了機會。那麼，具體的操作方式是如何呢？
一、拆解出子技能
絕大多數的技能都可以再更細分，例如以我最近想學的動畫設計，可能就包含物件設計、軟體操作、動態設計。（這邊的名詞應該是非常不準確的，因為我是突然想到，再加上自己過去的認知。）
在這個階段，可以詢問比較專業的人，或具有該技能的朋友，藉由別人的學習經驗，可以更好的拆解，或者修正不合適的目標。例如有個朋友想學程式設計，可能就可以修正成更明確的手機 2D 遊戲開發。
二、學習子技能的基礎
同時，多數的技能都有其基礎，例如可能牽扯到設計理論，這時就必須先去學習。在這一段也可以運用專業者或朋友，或者透過書籍去得知領域的知識點。或者有些前置技能需要先取得。例如想寫程式總得會用電腦吧？
三、移除障礙
接著，我們必須移除各種障礙，這障礙可能是心理面的，可能是缺少自信、恐懼、懶惰等等。也可能是實質面的，例如你會需要軟體、電腦才有辦法開始設計。解決的方法也有許多，以簡單的關閉通知、網路，到運用尤里西斯合約的技巧都是可行動的選項。
四、練習最重要的子技能 20 小時
最後來到重頭戲的部分，在拆解子技能的時候，應該可以找出最重要的子技能，這邊我猜測是動態設計。決定好最重要的技能後，安排短期密集的學習行程，盡量在短期內達到 20 小時。
限制
以上四個就是二十小時學習法的步驟。到了這裡，應該也有不少人發現了一件事：「並不是用二十小時學習任何事。」在這裡，20 小時必須花費在最重要的子技能上，並不包含其他子技能，因此也有可能發生這種狀況：想要學習網站開發，拆解出前端工程、前端設計、後端工程、系統規劃、伺服器規劃、自動整合、自動測試、PWA 等等不勝枚舉（這邊拆得有點誇張，別太認真）。此時就必須要調整。
以這個例子來講，我或許會排除前端設計（不屬於開發），並分為幾個子技能：前端工程、後端工程、系統架構、專案管理。而對我來說，前端工程是我想真正投入的（因為看的到），我就會盡可能尋找開箱可用的後端系統（如 WordPress 就比 OctoberCMS 好）、系統（Lionfree 比 Linode 好）。
另一項限制就是這個方法只能用於技藝類，知識類的學習就不太容易運用。我在寫這篇的時候，前面其實想舉動態設計為例，但後來發現似乎以理論為主，不適合二十小時學習法，因此改為較為技藝型的動畫設計。
結語
在閱讀這本書的時候，我感覺這本書很大程度的內容是用來衝字數的，雖然據說案例有起到示範的作用，但我還是很乾脆的不看它的案例，也因此寫這篇文章前的閱讀時間只有不到三十分鐘，可能因此有些出入或省略，尚請見諒。
但書中有個原則我覺得也是很重要的，但不太知道該怎麼插在內文：「選擇一項你會喜歡的技能」。以我個人經驗，我曾經想學吉他與烏克麗麗，但後來卻失敗了。現在看來，我想學並不是因為我喜歡，而是受到「必須學一項樂器」的奇妙觀點影響。
如果觀望現在的人，我想也有許多並非出於喜歡，而是出於他人觀點或社會風氣。程式設計是個我會舉到爛掉的例子，我看過太多沒喜歡電腦的人學習程式設計，通常到後面都只能及格，也無法真正運用。
這些都是題外話了，只是我想藉由這樣的機會，傳達我對現在許多人學習模式的不滿。或許多數人需要的是找到怦然心跳的某個技能吧？
現在邀請你做出一些行動，如果你覺得這篇文寫得不錯，歡迎分享此文與購買此書。
- 你想學習什麼？它為什麼吸引你？
- 你有沒有可以參考的對象，無論是書、人、或影片？
- 你覺得在應用這項技能時會遭遇什麼狀況？