1. Google&Wiki（遇到問題做的第一件事情，也是學習某個東西做功課（homework）最先用到的東西。————每天在WiKi上話10分鐘左右看些感興趣學科的發展分支，也是擴展自己領域的有用方法。
2. 看書挑剔，只看經典。如何選擇經典，可以到網上做做功課，看看評價，綜合分析一下。————經典的書看着吸收更多，也是更高效的方法。
3. 做讀書筆記。一是將自己閱讀的時候的思考（包括閃念）總結下來，二是將書中的好例子摘抄下來。我覺得，人與人學習的差距不在資質上，而在花在思考的時間和思考的深度上（後兩者常常也是相關的）。————我有有筆記，爲什麼不檢查養成這個習慣呢？看任何一篇好文章時，都下意思的摘抄下！
4. 利用走路和喫飯的時候思考，還有睡覺前必然要弄一個問題放在腦子裏面，在思考中迷糊入睡。發現這樣一來往往在不知不覺中多出來大量的思考時間。 將思考成爲習慣還有一個很大的好處：避免焦慮。————我倒是經常焦慮，這個比較適合我吧 喫飯時 走路時 睡覺前空閒時都可以想問題的，當然前提是要有問題在腦子中。
5. 重要的事情優先。儘量避免瑣事騷擾，不重要的事情能不做就不做。有很多事情都是可以先放一放甚至完全let go的，否則的話就整天被所謂"緊急"的事情牽着鼻子走了。——重要的事，當前我最重要的事紮實自己的專業基礎！紮實數學！
6. 重要的事情營造比較大的時間塊來完成。比如一本好書，或者一個重要的知識點，最好不要切得太瑣碎了看，否則看了後面忘了前面。不利於知識的組織&聯繫。————目前時間比較零散，這個不好解決啊，只是適應了。
7. 多看心理學與思維的書，因爲它們是跨學科的。知識分兩種，一是我們通常所謂的知識，即領域知識。二是關於我們的大腦吸收知識的機制的知識，後者不妨稱爲元知識。雖說這也是領域知識，但跟其它的領域知識不同的是，它指導着我們學習其它所有的領域知識。————我最思維的比較感興趣，能不能也堅持看下去啊？剛纔還在浪費時間休息呢。。。思維的書！
8. 學習一項知識，必須問自己三個重要問題：1. 它的本質是什麼。2. 它的第一原則是什麼。3. 它的知識結構是怎樣的。————學習一樣知識，也要系統的高效的學習下，不能太拖暫時間！
9. 獲得的多少並不取決於讀了多少，而取決於思考了多少、多深。————思考了，纔是自己的。對於我這樣思考後很快就忘了的人，應該把學到的知識輸出纔行！寫博客是好辦法！
10. 善於利用小塊時間，也就是《奇特的一生》中所說的“時間下腳料”，如何利用前面有幾個方法。同時，也善於創造整塊時間（如通過要事優先）。————善於利用小塊時間， 創造大塊時間！
11. 關於習慣的養成，必須要說明的：爲什麼說起來容易做起來難，是因爲“說”只是理性上承認正確，並沒有考慮到我們每個人大腦中居住的那個非理性自我。這個自我以強大的情緒力量爲動機，以習慣爲己任，每時每刻都驅使着我們的行爲。因爲它掌握了“情緒”這個武器，所以我們只能時時拿它當大爺。不記得是哪位哲學家說的了，理性是感性的奴隸。那麼，是不是就是說無法克服既有習慣了？以我的經驗（以及觀察到的別人的經驗），還是可以的。第一條就是認識到習慣的改變絕不是一天兩天的事情，承認它的難度。第二條就是如果你真想改掉習慣，就需要在過程中常常注意觀察自己的行爲，否則習慣會以一種你根本覺察不到的方式左右你的行爲讓你功虧一簣。有一個認知技巧也許可以緩解更改習慣過程中的不適：即把居住在內心的那個非理性自我當成你自己的孩子（你要去培養他），或者你的對手（你要去打敗他）也行。總之不能當成自己，因爲每個人都不想改變自己。————大腦中居住着一個非理性的自我，在說，還是睡一會吧，白天有精神什麼什麼的，，，，應該意識到，這是我的對手，是在阻礙我成長！
1. 學習和思考的過程中常問自己的幾個問題：
- 你的問題到底是什麼？（提醒自己思考不要偏離問題。）————就像網上查資料樣，不時刻明確目的，會越走越偏的！
- OK，到現在爲止，我到底有了什麼收穫呢？（提醒自己時不時去總結，整理學習的東西）。——邊看着邊摘抄着筆記
- 設想自己正在將東西講給別人聽（有聲思考；能否講出來是判斷是否真正理解的最佳辦法。迫使自己去挖掘知識背後最本質、往往也是最簡單的解釋）。————假象這是面試官在考問我，我需要給他講解。
- 時常反省和注意自己的思維過程。尤其是當遇到無法理解或解決的問題之後，最需要將原先的思維過程回顧一遍，看看到底哪個環節被阻塞住了妨礙了理解。問題到底出在哪裏。並分析以後需要加強哪方面的思維習慣，才能夠不在同樣或類似的時候被絆住。對此，將思維的大致脈絡寫下來是一個很好的習慣。
- 養成反駁自己的想法的習慣：在有一個想法的時候，習慣性地去反駁它，問自己“這個難道就一定成立嗎？”、“有沒有反例或例外？”、“果真如此嗎？”之類的問題。————想想反面，保證更周全的想法。
- 人的思維天生就是極易流於表面來理解事物的（參見《Psychology of Problem Solving》第11章）。覺得自己理解了一個問題了麼？條件反射性地問自己：你真的理解了嗎？你真的理解了問題的本質了？問題的本質到底是什麼？目前我的理解是什麼？我對這個理解感到滿意嗎？這樣的理解到底有什麼建設性呢？等等。————多思考，學習完一個知識後，閉上眼思考，或者走路上跑步時睡覺前思考，這都是很好的思考問題！
2. 重視知識的本質：對於程序員來說這一點尤其重要，程序員行業的知識蕪雜海量，而且總是在增長變化。很多人感嘆跟不上新技術。應對這個問題的辦法只能是：抓住不變量。大量的新技術其實只是一層皮，背後的支撐技術其實都是十來年不變的東西。底層知識永遠都不過時。算法數據結構永遠都不過時。基本的程序設計理論永遠都不過時。良好的編碼習慣永遠都不過時。分析問題和解決問題的能力永遠都不過時。強大的學習能力和旺盛的求知慾永遠都不過時。你大腦的思維方式永遠都不過時。————專業基礎要紮實，數學要紮實！
3. 重視積累的強大力量，萬事提前準備：計劃訂長一點，自然就可以多獲得準備的時間。設想你若干年後會在做什麼事情，需要哪些技能，現在就開始準備。一個5年計劃便可以讓你獲得從現在開始的5年準備時間。5年中每天騰出半個到一個小時專心於某一件事情，認準一個方向，每次走一點，其實不要說5年，兩年就會發現會起到宏大的效應。反之，如果不知道目的是什麼，就不知道往哪個方向上使勁，就容易產生無用功。————目標，我也有自己的目標的，不要忘記啊！
4. 擡起頭來：人的思維是非常容易只見樹木不見森林的。時不時擡起頭來審視一下自己正在做的事情，問一問它（對現在或未來）有什麼價值，是不是你真正希望做的。你學到的東西到底是什麼？它們重要嗎？你需要在這個時候學習這些嗎？（見第2條）。你的時間就是你的資源，你投入這些資源來掌握知識，所以到底用來掌握哪些知識是一個很重要的問題。僅僅遵循興趣是不夠的，人會對很多次要的東西產生興趣，並一頭鑽進去浪費好多時間。所以判斷一個東西值不值得學習是很重要的。————也要想想這個和我以後的目標偏離多遠，不能人云亦云。不要見到什麼好都想要！
1. 退訂RSS：RSS Reader是個時間黑洞。就算mark all as read，在有大量feed的情況下，也會無形中消耗掉大量的時間。不要捨不得，那些一個星期都沒出現讓你眼睛一亮的內容的feed，很大的可能是永遠也不會出現。就算可能，也別擔心你會漏掉什麼寶貴信息，真正寶貴的信息，在其他來源你也會接觸到的。————刪減下我的鮮果訂閱，不能因物亂心。
2. 有時間嗎？總結總結最近得到的新知識吧。一般來說，我在一段時間內學習的一些東西總是會在這段時間內一直在腦子裏打轉，一有時間空隙（譬如走路，喫飯）它們就會自己蹦出來，促使我去進一步思考和總結。永遠不要認爲對一個知識的把握足夠深刻，“理解”的感覺很多時候只是假象。學會反問自己對知識到底把握了多少，是很有價值的。（如何反問，前面的總結中有提到）。————每週系統總結下學到新知識吧，每天看書時也儘量做筆記摘抄！
3. 有時間嗎？看本書吧。（傳統的）閱讀和思考永遠優於所謂的在互聯網上汲取新知識，後者往往淺表、不繫統、乃至根本沒價值。————我買的書還在那躺着呢，這個週末有時間讀嗎？
4. 制定簡要的閱讀計劃：選出最近認爲對你最有價值的書，先總覽一下，決定閱讀的順序（哪些章節可以優先閱讀）。然後每天看一點。並利用走路、喫飯、乘車或其他不適合帶着書和筆的時間來總結看過的內容，建立知識結構，抽取知識本質，與以往的大腦中的知識建立聯繫。————利用零碎時間總結下，這個試試啊！
1. 趁着對一件事情有熱情的時候，一股腦兒把萬事開頭那個最難的階段熬過去。萬事開頭難，因爲從不瞭解到了解基本的一些事實，是一個新知識暴漲的階段，這個時候的困難是最大的。有人熬不過去，覺得困難太大就放棄了。不過，狂熱的興趣可以抵消對困難的感覺，所以趁着對一件事情有熱情的時候，開一個好頭是很重要的。————72小時定律。做的任何一項決定，72小時內一定要執行，要不然肯定又是做不到！
2. 根據主題來查閱資料，而不是根據資料來查閱主題。以前讀書的時候是一本一本的讀，眼裏看到的是一本一本的書，現在則是一章、甚至一節一節的讀，眼中看到的不是一本一本的書，而是一堆一堆的章節，一個一個的知識主題，按照主題來閱讀，你會發現讀的時候不再是老老實實地一本書看完看另一本，而是非常頻繁地從一本書跳到另一本書，從一處資料跳到另一處資料，從而來獲得多個不同的人對同一個主題是如何講解的。————不能把侷限在一本書，想着這本書一定要看完在看其他的。其實可以像在網上學習樣，搜索關鍵詞
，各個網頁都打開看下，只看自己關注的。
3. 好資料，壞資料。好資料的特點：從問題出發；重點介紹方法背後的理念（ rationale ），注重直觀解釋，而不是方法的技術細節；按照方法被髮明的時間流程來介紹（先是遇到了什麼什麼問題，然後怎樣分析，推理，最後發現目前所使用的方法）。壞資料的特點是好資料的反面：上來就講方法細節，彷彿某方法是從天上掉下來的，他們往往這樣寫“我們定義... 我們稱...
我們進行以下幾個步驟... ”。根本不講爲什麼要用這個方法，人們最初是因爲面對什麼問題纔想到這個方法的，其間又是怎樣纔想出了這麼個方法的，方法背後的直觀思想又是什麼。實際上一個方法如果將其最終最簡潔的形式直接表達出來往往丟失掉了絕大多數信息，這個丟掉的信息就是問題解決背後的思維過程。至於爲什麼大多數書做不到這一點，我在這裏試着分析過。————想起計算機網絡這本書，確實這種有引導性的書纔是好資料，自己也要注意點，不能盲目選資料了。
4. 學習一個東西之前，首先在大腦中積累充分的“疑惑感”。即弄清面臨的問題到底是什麼，在瀏覽方法本身之前，最好先使勁問問自己能想到什麼方法。一個公認的事實是，你對問題的疑惑越大，在之前做的自己的思考越多，當看到解答之後印象就越深刻。記得大學裏面的課本總是瀑布式地把整個知識結構一覽無餘地放在面前，讀的過程倒是挺爽，連連點頭，讀完了很快又忘掉了，爲什麼？因爲沒有帶着疑問去學習。————看書之前先對書中知識進行一個猜想和疑問，帶着疑問去讀驗證。
5. 有選擇地閱讀。很多人覺得我讀書速度很快，其實我只是有選擇地閱讀。這裏的選擇體現在兩個地方，一是選擇一本書中感興趣的章節優先閱讀。二是對一本書中技術性較弱或信息密度較低的部分快速地略讀。一般來說，除了技術性非常強的書之外，大多數書的信息密度很低，有很多廢話。一般來說在閱讀的時候應該這樣來切分內容：1. 問題是什麼？2. 方案是什麼？3. 例子是什麼？如果是需要解釋一個現象的（譬如《黑天鵝》），那麼1.
現象是什麼？2. 解釋是什麼？3. 支撐這個解釋的理由是什麼？4. 例子是什麼？一般來說，這一二三四用不了多少字就可以寫完了（如果假設只舉一到兩個精到的例子的話），這樣的無廢話著作的典型是《合作的進化》————有選擇的閱讀，閱讀重點，不能想着看書中廢話來放鬆休息。
6. 爲什麼看不懂？如果看不懂一個知識，一般有如下幾個可能的原因：1. 你看得不夠使勁。對此古人總結過——書讀百遍其義自現。對於這類情況，仔仔細細地再多讀兩遍，多試着去理解兩遍，往往會“哦！原來這樣。”地恍然大悟。2. 其中涉及到了你不懂的概念。這是技術性的不理解。這種情況就需要 Cross Reference 。正如解決問題一樣，問題卡住解決不了，第一時間要做的就是分析到底爲什麼解決不了，而不是直接求救。3.
作者講述的順序不對，你接着往下看，也許看到後面就明白了前面的了。————看不懂，就搜些淺顯易懂的例子看看，再回頭看好資料。好資料通常說的不是那麼好理解。。。。
7. 如何在閱讀之前就能獲得對一本書質量的大致評估。在深入閱讀之前能夠迅速評估一本書的質量可以節省很多時間。基本上有幾個線索：1. 看作者。牛作者寫的書一般都不錯。2. 看目錄和簡介。一份好的目錄和簡介能夠透露這本書質量的相當一部分信息。目錄結構是否清晰，是否直白（而不是裝神弄鬼），都是衡量的線索。3. 看 Amazon 上的評價，這裏要注意的是，除了看整體打分之外，更要看打分最低的人是怎麼說的，因爲小衆意見往往有可能來自那些真正懂行的人（除了來踢館的），如果在打分最低的意見裏面看不到真正有價值的反駁意見的話就相當肯定書是不錯的了。4.
看樣章。Amazon 上一般都可以隨機瀏覽一些章節的，表達是否清晰，論證是否嚴謹，內容是否深刻，基本是幾頁紙就能看出來的。————看豆瓣、、。。
8. 如何搜尋到好書。幾個線索：1. 同作者的著作。2. Amazon 相關推薦和主題相關的書列（類似豆瓣的豆列）。3. 一本好的著作（或一份好的資料——不管是書還是網頁）在參考資料裏面重點提到的其他著作。4. 有時對於一個主題，可以搜索到好心人總結的參考資源導引，那是最好不過的。————看豆瓣，看銷量榜。。。
抓住不變量
我喜歡把知識分爲essential的和non-essential的。對於前者採取提前深入掌握牢靠的辦法，對於後者採取待用到的時刻RTM (Read the manual)方法（用本）。
如何區分essential和non-essential的知識想必絕大多數時候大家心裏都有數，我舉幾個例子：對程序員來說，硬件體系結構是essential的，操作系統的一些重要的實現機制是essential的，主流編程範式（OO、FP）是爲了滿足什麼需求出現的（出現是爲了解決什麼問題），是怎麼解決的，自身又引入了哪些新的問題，從而適用哪些場景）。 這些我認爲都是essential的。我想補充一點的是，並不是說硬件體系結構就要了解到邏輯門、晶體管層面纔行（其實要了解到這個層面代價也很小，一兩本好書就行了），也並不是說就要通讀《Computer
Architecture: Quantitative Approach》纔行。而是關鍵要了解那些重要的思想（很長時間不變的東西），而不是很細的技術細節（易變的東西）。《Computer Systems: A Programmer’s Perspective》就是爲此目的，針對程序員的需求總結出那些essential knowledge的好書。
再來說一下爲什麼需要預先牢靠掌握這些essential的知識：
- 根據Joel Spolsky同學的說法（原文），編程語言技術是對底層設備的封裝，然而封裝總是會出現漏洞的，於是程序員被迫下到“下水道”當中去解決問題，一旦往下走，漂亮的OO、N層抽象就不復存在了，這時候不具備堅硬的底層知識就會無法解決問題。簡而言之就是這些底層知識會無可避免的需要用到，既然肯定會被用到那還是預先掌握的好，否則一來用到的時候再查是來不及的，因爲essential的知識也往往正是那些需要較長時間消化掌握的東西，不像Ruby的mixin或closure這種翻一下manual就能掌握的東西。（英語也是這樣的essential knowledge——上次在PyCN上看到一個招Python開發人員的帖子將英語列爲必備技能，卻並不將自然語言處理列爲必備技能，正是因爲英語不是可以臨陣磨槍的東西，而且作爲知識的主要載體，任何時候都少不了它，如果不具備英語能力，這個就會成爲個人知識結構的短板或瓶頸，而且由於需要長時間才能獲得這項能力，所以這個瓶頸將持續很長時間存在。我們曾經在 TopLanguage 上討論過如何花最少的時間掌握英語）另一方面，在問題解決當中，如果不具備必要的知識，是根本無從思考的，再好的分析能力也並不是每個問題都能分析出該用哪些知識然後再去查手冊的，很多時候是在工具和問題之間比較，聯想，試探性的拼湊來解決問題；這就使得一個好的既有知識基變得至關重要。（實際上以上這個是一個較大的話題，希望有一天我能夠把它詳細展開說清:)）————英文很重要！！
- 如果你不知道某個工具的存在，遇到問題的時候是很難想到需要使用這麼樣一個工具的，essential knowldge就是使用最爲廣泛的工具，編程當中遇到某些問題之後，如果缺乏底層知識，你甚至都不知道需要去補充哪些底層知識才能解決這個問題。————數學很重要！
- 你必須首先熟悉你的工具，纔能有效地使用它（須知工具的強是無敵的，但這一切得以“瞭解你的工具”爲前提，甚至得以“瞭解目前可能有哪些工具適合你的問題”爲前提）。一門語言，你必須瞭解它的適用場景，不適用場景（比如繼承能解決你的問題不代表繼承就是解決你的問題的最適合的方案，須知問題是一個複雜系統，解決方案總是常常引入新的問題）。你必須瞭解它支持的主要編程範式，此外你還必須瞭解它的traps和pitfalls（缺陷和陷阱，如果不知道陷阱的存在，掉進去也不知道怎麼掉的。）這些都是essential knowledge，如果不事先掌握，指望用的時候查manual，是很浪費時間的，而且正如第2點所說，正因爲你不知道這些知識（如適用場景），從而用sub-optimal的方式使用了一門語言自己可能還不知道，因爲人的評價標準常常是：只要解決了最醒目的問題並且引入的新問題尚能忍受，就行。注意，熟悉並非指熟悉所有細節，而是那些重要的，或者無法在需要用到的時候按需查找的知識。比如上面提到的：適用場景不適用場景，編程範式，主要語言特性，缺陷和陷阱。————熟悉xx語言，這樣來看真的熟悉了嗎？？？
當然，以上作爲程序員的essential knowledge列表並不完備，關鍵是自己在學習新知識的時候帶着第三隻眼來敏銳地判斷這個知識是否是不變量，或不易變的量，是否完全可以在用的時候查手冊即可，還是需要提前掌握（一些判斷方法在上文也有所提及）。並且學會在紛繁的知識中抽象出那些重要的，本質的，不變的東西。我在之前的part裏面也提到我在學習新知識的時候常常問自己三個問題：該知識的（體系或層次）結構是什麼、本質是什麼、第一原則是什麼。
另外還有一些我認爲是essential knowledge的例子：分析問題解決問題的思維方法（這個東西很難讀一兩本書就掌握，需要很長時間的鍛鍊和反思）、判斷與決策的方法（生活中需要進行判斷與決策的地方遠遠多於我們的想象）
最後分享一個學習小Tip：
學習一個小領域的時候，時時把“最終能夠寫出一篇漂亮的Survey”放在大腦中提醒自己，就能有助於在閱讀和實踐的時候有意無意地整理知識的結構、本質和重點，經過整理之後的知識理解更深刻，更不容易忘記，更容易被提取。
楊軍在 TopLanguage 上也曾分享了三篇非常棒的學習心得的文章，字字珠璣：
[1] 有些事情做起來比想象中容易
[2] 有關讀書方法的一點想法
參考：http://blog.csdn.net/pongba/article/category/43902