[摘抄] 一直以来伴随我的一些学习习惯 2/2 [反省课]
原文
目录
- 趁着对一件事情有热情的时候 一股脑儿把万事开头那个最难的阶段熬过去
- 根据主题来查阅资料 而不是根据资料来查阅主题
- 好资料 坏资料
- 学习一个东西之前 首先在大脑中积累充分的疑惑感
- 有选择地阅读
- 为什么看不懂
- 如何在阅读之前就能获得对一本书质量的大致评估
- 如何搜寻到好书
- 程序员的知识结构
- 相关文章
趁着对一件事情有热情的时候 一股脑儿把万事开头那个最难的阶段熬过去
万事开头难，因为从不了解到了解基本的一些事实，是一个新知识暴涨的阶段，这个时候的困难是最大的。 有人熬不过去，觉得困难太大就放弃了。
如果每件想做的事情都记录下来的话, 可以看到的放弃的事情太多了
- 四轴
- django
- celery
- cython
- sklearn
不过，狂热的兴趣可以抵消对困难的感觉，所以趁着对一件事情有热情的时候，开一个好头是很重要的。 （当然，这并不是说持之以恒就不重要了）。
开个好头
- 先花 1-2h 看些资料, 大概了解要学的东西是什么
- 定一个学习目标(学习深度), 学习这么多有什么意义
- 怎么学 放到 GTD 里面 是否可行 时间够不够用
- 总结一下 --> blog
怎么处理中途遇到的坑及比预期多花的时间/不及预期收获大? --> 反思学习方法和思路
当然，也许这个是因人而异的，对我来说我会在对一件事情有浓厚兴趣的时候非常专注地学习，把很多 groundworks 做掉。后面就会顺利一些了
至少能够对这个领域的生态系统有大概了解, 使用场景/别人的观点/什么时候要用/是否需要花时间啃
根据主题来查阅资料 而不是根据资料来查阅主题
以前读书的时候是一本一本的读，眼里看到的是一本一本的书， 现在则是一章、甚至一节一节的读， 眼中看到的不是一本一本的书，而是一堆一堆的章节，一个一个的知识主题， 按照主题来阅读，你会发现读的时候不再是老老实实地一本书看完看另一本， 而是非常频繁地从一本书跳到另一本书，从一处资料跳到另一处资料，
网上的技术文档对应这里的书的一节, 大部分文章只讲了一小部分的知识点, 官方的 docoument + 实践 相当于指南, 然后针对每个知识点去 Google 高手对这个点的解读/经验
从而来获得多个不同的人对同一个主题是如何讲解的。
没有理解到这个程度
比如最近我发现在看蒙特卡罗算法时就查了十来处资料，其中有三四篇 paper 和六七本书； 这是因为即便是经典的书，你也不能指望它对其中每一个主题的介绍都是尽善尽美的， 有些书对某个主题（知识点）的介绍比较到位，有些书则对另一些知识点介绍得比较到位。
这个在通识类(相当于科普)的纸质书体现的比较明显
而有时候一篇紧凑的 paper 比一本书上讲得还要好。
看 paper !!!
我硬盘里面的书按主题分类，每个主题下面都有一堆书， 当我需要学习某个主题的知识时（譬如贝叶斯学习或者神经网络）， 我会把里面涉及这个主题的书都翻开来，索引到相关章节，然后挑讲得好的看。
临时 Google 找到那一篇资料也是很费劲, 所以还是有索引的存档较好, 现在在 devops.notes 中做
那么，如何判断一个资料是好资料还是坏资料呢？
好资料 坏资料
好资料的特点：从问题出发； 重点介绍方法背后的理念（ rationale ），注重直观解释，而不是方法的技术细节；
为什么以前偷懒都忽略这些看起来枯燥但是深入有大有用处的细节 ???
按照方法被发明的时间流程来介绍（先是遇到了什么什么问题，然后怎样分析，推理，最后发现目前所使用的方法）。
也就是讲历史, 之前讲到历史上的创新是商人为了解决当下实际问题的, 在 IT 技术界体现的更明显
坏资料的特点是好资料的反面：上来就讲方法细节，仿佛某方法是从天上掉下来的， 他们往往这样写“我们定义... 我们称... 我们进行以下几个步骤... ”。 根本不讲为什么要用这个方法，人们最初是因为面对什么问题才想到这个方法的，其间又是怎样才想出了这么个方法的，方法背后的直观思想又是什么。 实际上一个方法如果将其最终最简洁的形式直接表达出来往往丢失掉了绝大多数信息，这个丢掉的信息就是问题解决背后的思维过程。
对啊, 只学会钓鱼, 不会其他野外生存的方式
我曾经在大学图书馆(华工北校)里面翻找一些资料, 但几乎都是上面提到的坏资料...
至于为什么大多数书做不到这一点，我在 这里 试着分析过
太注重短期实用性
学习一个东西之前 首先在大脑中积累充分的疑惑感
即弄清面临的问题到底是什么，在浏览方法本身之前，最好先使劲问问自己能想到什么方法。
这个方法用在看一篇 pandas 分析职位信息的文章上, 先自己对着数据分析了一遍, 然后再看一遍原文看看作者提供了哪些新知识
一个公认的事实是，你对问题的疑惑越大，在之前做的自己的思考越多，当看到解答之后印象就越深刻。
为什么好久没有恍然大悟的感觉... 工作 3 年的精力基本都集中在钓鱼上, 现在遇到各方面的瓶颈了
自己先思考, 然后理解要学习的新东西是怎么解决的
记得大学里面的课本总是瀑布式地把整个知识结构一览无余地放在面前， 读的过程倒是挺爽，连连点头，读完了很快又忘掉了， 为什么？因为没有带着疑问去学习。
怎样教会小孩怎么看书
- 注重看目录 带他联想
- 自己先看一遍书
- 有哪些好玩的知识
- 带他去看/实践
有选择地阅读
很多人觉得我读书速度很快，其实我只是有选择地阅读。 这里的选择体现在两个地方，一是选择一本书中感兴趣的章节优先阅读。 二是对一本书中技术性较弱或信息密度较低的部分快速地略读。 一般来说，除了技术性非常强的书之外，大多数书的信息密度很低，有很多废话。 一般来说在阅读的时候应该这样来切分内容： 1. 问题是什么？2. 方案是什么？3. 例子是什么？
听话
如果是需要解释一个现象的（譬如《黑天鹅》），那么 1. 现象是什么？2. 解释是什么？3. 支撑这个解释的理由是什么？4. 例子是什么？ 一般来说，这一二三四用不了多少字就可以写完了（如果假设只举一到两个精到的例子的话），
《黑天鹅》 的废话也够多了, 后面到了后面基本看不下去了
这样的无废话著作的典型是《合作的进化》； 那为什么有些书，明明核心观点就那点东西（顶多加上几个精要的例子罢了）却写得长得要命呢？ 因为人的思维都有一个“联想”的特点，写着写着就容易旁逸斜出，而且作者自己也往往觉得引申出去挺牛逼， 有时候很多与主题无关的废话就掺和进来了； 那么，阅读的时候就应该有选择性地滤掉这些不相干的废话；
旁征博引这种写法放在历史里面好玩(看了《战天京》后), 其他地方就未必了
此外还有一种可能性就是大量冗余的例子。 一般来说组织得比较好的书会有详细且一目了然的目录和索引，
看 知乎 出的豆瓣/多看书养成的看目录的习惯
根据目录首先就可以滤掉一部分（比如某个子章节的内容你以前是看过的）， 然后有时候作者还会举很多冗余的例子， 如果你已经觉得印象够深刻了这些例子完全可以不看 （一些书就非常厚道地对每个观点只辅以一两个最最经典的例子，譬如《与众不同的心理学——如何正视心理学》，这样的书我最是喜欢）
为什么看不懂
如果看不懂一个知识，一般有如下几个可能的原因：
- 你看得不够使劲。对此古人总结过——书读百遍其义自现。 虽然这个规律不是任何时候都成立的，但是从认知科学的角度看是完全可以解释的， 我们在阅读的时候，注意力往往会有选择性地关注其中的某一些“点”，而忽略了另一些“点”， 于是一遍看下来可能因为某一些忽略导致无法理解整体。 或者干脆看的时候就没注意其中一些细节但重要的东西。 此外，大脑理解一个东西需要一定的处理时间，人脑的处理速度很慢，神经冲动每秒传输速度不过百米， 所以不能指望看到哪懂到哪。
最后，我们可能因为思维定势的原因会从某个特定的角度去看一句话而忽略了从不同角度去理解的可能性。 对于这类情况，仔仔细细地再多读两遍，多试着去理解两遍，往往会“哦！原来这样。”地恍然大悟。
对的, 看 MongoDB 官方文档有感, 里面隐藏了很多第一次看不会注意到的地方
- 其中涉及到了你不懂的概念。这是技术性的不理解。这种情况就需要 Cross Reference 。 如果一句话中用到了你不懂的概念，那就去查，现在很多书都是电子书，直接搜索一下，或者，对于纸书，看一下书后面的索引就行了。 奇怪的是很多人看不懂也不分析一下为什么不懂，就直接放弃了。 正如解决问题一样，问题卡住解决不了，第一时间要做的就是分析到底为什么解决不了，而不是直接求救。
还是不要急, 但是怎样在预期时间内搞懂全部不清楚的地方就是个问题, 不过这不应该是个问题, 多花时间吧。。。
- 作者讲述的顺序不对，你接着往下看，也许看到后面就明白了前面的了。
真的是, 任何人都会出错
如何在阅读之前就能获得对一本书质量的大致评估
在深入阅读之前能够迅速评估一本书的质量可以节省很多时间。基本上有几个线索：
看作者。牛作者写的书一般都不错。
看目录和简介。一份好的目录和简介能够透露这本书质量的相当一部分信息。目录结构是否清晰，是否直白（而不是装神弄鬼），都是衡量的线索。
看 Amazon 上的评价，这里要注意的是，除了看整体打分之外，更要看打分最低的人是怎么说的， 因为小众意见往往有可能来自那些真正懂行的人（除了来踢馆的）， 如果在打分最低的意见里面看不到真正有价值的反驳意见的话就相当肯定书是不错的了。
看样章。Amazon 上一般都可以随机浏览一些章节的，表达是否清晰，论证是否严谨，内容是否深刻，基本是几页纸就能看出来的。
如何搜寻到好书
几个线索： 1. 同作者的著作。
赚钱买书 !!!
- Amazon 相关推荐和主题相关的书列（类似豆瓣的豆列）。
之前忽略豆列这个东西了, 看来就合之前讲的学习方法一样, 豆瓣这个产品表面上有几个独立的书/电影/阅读器产品, 但是背后还有一些可能好用的小产品, 忽略这些小产品, 就不算会用豆瓣
- 一本好的著作（或一份好的资料——不管是书还是网页）在参考资料里面重点提到的其他著作。
就和本文作者文章尾部/中间的一样, 参考资料有许多非常有意义的东西...
- 有时对于一个主题，可以搜索到好心人总结的参考资源导引，那是最好不过的。
技术主题的资源索引见 github 的 awesome 系列, 非技术类主题试着在 豆列 上找找
程序员的知识结构
抓住不变量
我喜欢把知识分为 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 的方式使用了一门语言自己可能还不知道 （最小白的例子是，如果你不知道语言支持foreach，那么可能每次都要写一个冗长的循环， 较常见的例子是不知道有很方便的库设施可以解决手头的问题所以傻乎乎的自己写了一堆代码），
因为人的评价标准常常是：只要解决了最醒目的问题并且引入的新问题尚能忍受，就行。
注意，熟悉并非指熟悉所有细节，而是那些重要的，或者无法在需要用到的时候按需查找的知识。 比如上面提到的：适用场景不适用场景，编程范式，主要语言特性，缺陷和陷阱。
技术的适用/不适用场景, 编程范式, 语言特性, 缺陷/陷阱
当然，以上作为程序员的 essential knowledge 列表并不完备， 关键是自己在学习新知识的时候带着第三只眼来敏锐地判断这个知识是否是不变量，或不易变的量， 是否完全可以在用的时候查手册即可，还是需要提前掌握（一些判断方法在上文也有所提及）。 并且学会在纷繁的知识中抽象出那些重要的，本质的，不变的东西。 我在之前的 part 里面也提到我在学习新知识的时候常常问自己三个问题：该知识的（体系或层次）结构是什么、本质是什么、第一原则是什么。
不懂 先记下
另外还有一些我认为是 essential knowledge 的例子： 分析问题解决问题的思维方法（这个东西很难读一两本书就掌握，需要很长时间的锻炼和反思）、判断与决策的方法（生活中需要进行判断与决策的地方远远多于我们的想象）， 波普尔曾经说过：All Life is Problem-Solving。 而判断与决策又是其中最常见的一类Problem Solving。
尽管生活中面临重大决策的时候并不多，但另一方面我们时时刻刻都在进行最重大的决策： 如：决定自己的日常时间到底投入到什么地方去。 如：你能想象有人宁可天天花时间剪报纸上的优惠券，却对于房价的1%的优惠无动于衷吗？ （《别做正常的傻瓜》、《Predictably Irrational》） 如：你知道为什么当手头股票的股价不可抑止地滑向深渊时我们却一边揪着头发一边愣是不肯撤出吗？ （是的，我们适应远古时代的心理机制根本不适应金融市场。）
糟糕的判断与决策令我们的生活变得糟糕， 这还不是最关键的，最关键的是我们从来不会去质疑自己的判断，而是总是能“找到”其他为自己辩护的理由 （《错不在我（Mistakes were made, but not by me）》） 又，现在是一个信息泛滥的时代， 于是另一个问题也出现：如何在海洋中有效筛选好的信息， 以及避免被不好的信息左右我们的大脑（Critical Thinking） 关于以上提到的几点我在豆瓣上有一个专门的豆列（“学会思考”）， 希望有一天我能够积累出足够多的认识对这个主题展开一些详细介绍。
打开脑洞
最后分享一个学习小Tip： 学习一个小领域的时候，时时把“最终能够写出一篇漂亮的 Survey ”放在大脑中提醒自己， 就能有助于在阅读和实践的时候有意无意地整理知识的结构、本质和重点， 经过整理之后的知识理解更深刻，更不容易忘记，更容易被提取。