读《程序员的思维修炼》有感：
我今天主要读到的是精通者与专家：
所谓精通者：
处于精通水平的从业人员有一项重大突破：他们能够纠正以往不好的工作表现。他们会反思以前是如何做的，并修改其做法，期望下一次表现得更好。
自我反思、自我察觉、自我进步。
但处于精通阶段的人更像是初级专家，而不是高级胜任者。
敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。但是基于以往表现进行自我纠正，只在较高的技能水平上才能实现。
所以敏捷开发还是对开发者的自身能力有一定的要求的。
敏捷开发是非常有效的工具，但它不适用于一个完全由新手和高级新手组成的团队。
所谓专家：
根据统计，专家的数量很少，大概占总人数的1%~5%。
而如果专家被强制遵从那些规则操作，他们的工作就会变得效率低下。
专家通常很难把他们的行为恰如其分地解释清楚，他们的很多行为是如此地熟练以至于已经变成无意识的了。他们的大量经验都是通过大脑的非语言、无意识区域存储的，这让我们难以观察，而专家则难以表述。
所以专家未必是个好老师或者好作者。
清晰表述专业技能十分困难。 It’ s hard to articulate expertise.
这样就会为一些东西的失传感到可惜。毕竟乔布斯再怎么带徒弟都不会完全教会他。
当团队需要结对或者寻找指导老师时，你可以尝试选用和受训者技能水平相近的老师。
直接让 CTO 带你有时候并不是一件好事。
专家根据直觉工作，而不需要理由。
新手使用规则，专家使用直觉。
认识到新手需要与情境无关的规则，而专家使用与情境相关的直觉。
这不是说新手没有任何直觉或者胜任者根本不能识别模式，但是专家的直觉和识别模式的能力已经超越了他们显性的知识。
内在诀窍书籍的作者们建议你把自己想象成专家。他们注意到，仅仅告诉学生去“模仿”所在领域的名人就足够提高他们的水平了，毕竟我们是天生的模仿者。
那么想象自己成功被证明是一种达到成功的有效方法。你可以提高你的表现——不论是演奏小提琴、调试代码还是设计新的架构——通过想象你已经成功地做到了这些。
如果你的周围全是高技能的人，你就会增长自己的技能水平。一部分原因是来自于对他们实践和方法的观察和运用，还有一部分是来自于对自己大脑的调节，使其在更高水平上工作。你有一个被称为镜像神经元的天然机制来帮助你：观察别人的行为，激励你也做同样的行为。
宁做凤尾不做鸡头。
考虑一下，任何对开发指定严格规则的方法或企业文化，会对团队里的专家产生什么影响呢？这将拖累其业绩表现下降到新手的水平。公司失去了他们所擅长的所有竞争优势。
虽然差异这么大，但是一个团队还是得搭配的错落有致。
理想情况下，你希望团队里混合各种层次技能水平：拥有一个全部是专家的团队也存在它的难处。当所有人在考虑森林的时候，你也需要一些人来关注一棵棵大树。
但是，有一些好消息。一旦你成了某个领域的专家，在别的领域成为专家就会变得更容易。至少你已经有了现成的获取知识的技能和模型构建的能力。
专家的负面
新手的大脑有很多可能性，但是专家心里只有很少。——铃木
对于专家来说最致命的弱点是像专家一样行动。一旦你相信自己的专业水平，你就会对其他的可能性视而不见。你停止了好奇心。
这些年来我看到很多这样的例子。人们在某些语言上投入很大，比如Java或者C++①。他们取得了认证，并且背诵了摞起来四五米厚的有关API和工具的书籍。然后，一些新的编程语言出现，让他们写更简洁、更直观的代码，更彻底的测试，更容易实现的并发，等等。但是他们完全拒绝这些新语言。他们会花费更多精力来讽刺新语言而不是严肃地评估对它们的需求。
达芬奇在600年前抱怨说：“人们看却没有看见，听却没有听见，吃却没有味觉，接触却没有触觉，说话却没有思考。”
自由的代价是永远提高警惕。——约翰•菲尔波特•柯伦的名言, 1790年永远提高警惕不仅是自由的代价，也是意识的代价。
一旦你启动自动驾驶，你就不会转向了。
人群分布：
由此可见，专家真的少之又少，但是我们现在能做的就是学好自己的专业知识，提升自己的专业素养，努力完善自己，朝着专家迈进。
积极的实践需要四个条件。需要一个明确定义的任务。任务需要有适当难度——有挑战性但可行。
任务环境可以提供大量反馈，以便于你采取行动。提供重复犯错和纠正错误的机会。
以上这些就是我所认识到的。
