此读书笔记并不完全作为阐述想法，所以在阐述一些问题的时候可能没有前因后果，更是一种总结性的话语和书上言语的精华，这有点悖论，如果你想了解，请去看《程序员的思维修炼》，这本书可以跨学科，即便你不懂程序，都值得一看，是从思维和大脑层面来开展介绍的。
第2章 从新手到专家的历程
新手到专家需要经历5个阶段（德雷福斯技能获取模型）
真正的专家不怕考验，而轻松面对~
真正的专家很难将自己的行为解释清楚，而熟练到已经无意识了。
新手：很在乎自己是否能成功，不知道自己是对是错，不是特别想要学习，只是实现一个立竿见影的目标，不知道如何应付错误，错误出现不知所措。新手需要指令清单，有规则，有顺序。但规则只能让你启程，不会让你走的更远。
高级新手：高级新手不想要全局思维，当公司在展示全年销售测量表和数据时，你可能不感兴趣，可这预示着明年你在这家公司是否还能继续干下去。但是，你看不到这种联系，因为你层次还不够，只处于较低的技能水平。
胜任者：可以独立解决自己遇到的问题，并开始考虑如何解决新的问题。处于这样水平的人通常具备“主动性”和“足智多谋”，往往在团队中发挥着领导作用，他们是团队里的好人，但缺乏足够的能力——自我反思和纠正。
精通者：精通者需要全局思维，而且需要更大的概念框架，过于简单化的信息，他们会非常沮丧。在精通者中，最明显的特征：自我改进和反思。同时他们善于倾听别人的意见，并从那些失败或者成功的项目中认真观察、学习和总结。
专家（大师）：专家凭直觉工作，并不需要理由。他们有丰富的经验，并能家当运用，他们著书、写文章、做演讲等等。专家往往通过观察一些细节（可能常人根本无法觉察到的一些细节）就能判定特征和问题所在，那些无关紧要的会自动过滤更是专家具备的能力。
实践：
你不知道自己不知道
达尔文：“无知往往来自于自信而不是知识”
上面两句话，刚开始理解的时候没有突然顿悟的感觉，但跟媳妇一番讨论后，更加理解了：
学生问老师自己所掌握的知识到底有多少？
老师给出了下面的回答：
你现在的知识就仿佛是一个点，而老师比你要多一些，是个圈，老师知道你不知道的，你有可能知道自己不知道的而老师知道的，你通过学习将来会知道老师知道的，然后超过老师去知道老师不知道的，老师也在不停地学习，但随着知道的越来越多，也就意识到自己不知道的越来越多，因为越大的圆外面就会有更大的圆。
达尔文的总结，一语道破了无知的“自信”（无知者无畏这句古话更是说明了“假自信”），潜意识层面根本就是不知道自己不知道。有时候自信也很可怕，因为你要确认自己到底是否真的知道。
大师都是凭直觉办事，可公司更希望通过数据或者规则来确定事情是否是“对的”，这种方式试图在“毁灭"专家，公司往往轻视专家的直觉，认为这是“不科学”和“不可重复”。新手使用规则，而专家使用直觉，具备元认知能力（metacognitive)，或者叫具备自我认知能力的人往往出现在较高层次中。
知道你不知道什么。
专家!=老师，教学是一门技能，你在某个领域是专家，但这并不能保证你可以将它教给别人。
有效地使用德雷福斯模型
十年磨一剑，也许需要一辈子或者更长？学漫漫路漫漫，我们需要积极实践自己：
• 需要一个明确定义的任务
• 任务需要有适当的难度——有挑战性但可行
• 任务环境可以提供大量反馈，以便于你采取行动
• 提供重复犯错和纠正错误的机会
• 一旦你成为某个领域的专家，在别的领域成为专家就会变得更容易。你已经有了现成的获取知识的技能和模型构建的能力。
软件开发的职业特征：
• 程序员往往认为自己是一种工具，从而漠视工作，只是执行分析师的指令，而不期望自己对项目的设计和架构有所创见。
• 由于薪酬等级的不平等，专家级的程序员争先恐后的离开一线编码，通过管理、教学或者巡回演讲赚更多的钱。
• 软件工程教育开始受到质疑。很多人认为正规的实践模式是最好的教育方法。这种对正规方法和工具的过度依赖削弱了实践中真正经验的作用。
R&D精神(Rip off and duplicate, 偷学技艺/偷师学艺)，我们可以从他们的工作中借鉴很多经验教训并应用到软件开发中。
勇于承担责任：
• 新手往往只是执行命令，新手过渡到胜任者最大的区别在于能独立解决问题
和承担责任。
• 通过观察和模仿来学习（R&D)。如果你有孩子你会发现，他们很少照你说的做，而是大多时候在模仿你。
• 模仿的同时就是实践的过程，没有实践就没有技能。模仿->吸收->创新
• 保持实践以维持专家水平，全世界最优秀的那些专家没有因为做了20年以上开发而不去编码了，实践是保持技能的唯一手段。
警惕工具陷阱：
曾经，在我刚接触软件领域的时候，曾一度认为UML，MDA以及TDD是未来解决软件的必要良方，甚至也将其滥用，然而合宜的工具需要放到合宜的
环境去运用，模型只是工具，而非镜子。如果你需要创造力、直觉或者独创能力，避免使用形式方法。
再次考虑情境：
高端的顾问最喜欢回答说：“具体情况具体分析”，当然他们是对的，他们的分析依赖于很多事情——所有那些专业人士懂得去寻找至关重要的细节，同
时也忽略无关的细节。
在系统思维中，如面向对象编程，往往是事物之间的联系最让人感兴趣，而不是事物本身。这也是面向对象化编程的特点，你大多数时候在想事物本身的联系，而实际问题的解决却放到了后面，本人的目前的理解是，面向对象编程真的有那么重要么？或许只是在某些方面比较重要罢了，扩展性和低耦合的确是面向对象的实践的目的，可除此之外纯为了面向对象而行动，就存在滥用倾向了。例如java这种语言的面向对象纯属为统一思想而设置的程序员枷锁。
日常中的德雷福斯模型：
• 新手需要快速成功和与情节无关的规则，而专家需要获得全貌。理想情况下，你希望团队里混合各种层次技能水平的人，拥有一个全部是专家的
团队存在它的难处。当所有人在考虑森林的时候，你也需要一些人来关注一棵棵大树。
• 学习如何学习的技能。
总结：
了解自己出于德雷福斯模型中的哪个阶段，并自我评价，了解你的团队成员，他们的技能阶段，以及对你有何帮助。回顾曾经团队经历的问题，并运用德雷福斯模型解释这些问题，对于已知的问题是否能通过德雷福斯模型解决或者避免？