专家级新手
1980 年，德雷福斯兄弟提出一个模型，将一个技能的学习程度类比成阶梯式的模型，由上而下分成：专家（Expert）、精通者（Proficient）、胜任者（Competent）、高级新手（Advanced Beginner）、新手（Novice）五个等级。
这就是德雷福斯模型（Dreyfus model of skill acquisition）。
基于这个模型德雷福斯兄弟写了一本书， 显然它有很多内容，但它的要点是，技能学习者需要从“教条主义地遵循规则和缺乏大局”转向“直觉超越规则和完全理解大局”——也就是说愈往上，愈具有大局观。
德雷福斯模型往往只是一个美好的愿景，也就是每个人都会随着更多的练习，改善自己的技能，从而往上进步。
然而技能的提升并不是线性的，现实中，我们常常可以看见一些“经验和能力不相称”的人，用一句话概括：
十年经验，不是一个经验用十年。
资料显示，多数人落在“高级新手”这一阶层，“高级新手”不愿意全盘思考，当管理阶层分配工作给“高级新手”，他们认为每项工作一样重要，不明了优先层度，意味着他们无法认知每件工作的相关性。
停留在“高级新手”的人常常停滞发展，在学习技能的角度上，一个人的技术水平停止发展常常由于以下两个原因：天赋 or 不再有继续改进的意愿。
在本文，我们放弃考虑第一种可能性（绝大多数程序员在达到胜任标准之前都不会用尽天赋），并且考虑一个“不再有继续改进的意愿”的可能：由于自信已达到专家地位而自愿停止改进，因此不可能进一步改进。
不知道你有没有过这样的经历，看一本书看到一半就放回书架，再也没有拿出来过；一门课程学了三分之一然后半途而废，之后再也想不起这门课到底讲了些什么。
这种停滞在平庸的阶段，称之为“专家级新手（Expert Beginner）”。
软件专家级新手
人类学习一件事物，必须要有现实世界的反馈！
例如：学打羽毛球，要习惯挥拍，要学习阅读球的落点，才能逐渐改善自己的技术；学习驾驶，一样要学会阅读与障碍物的距离，转弯时是否有充足的空间。编程呢？
编程的反馈周期很长，它不像日常生活的技能或体育运动，反馈周期是以分钟计算的，在软件中，反馈周期往往是几个月，软件行业很容易诞生“专家级新手”。
你可能会说，编译、运行或单元测试，不就是不到几分钟甚至几秒的时间吗？
那只是开发，而这里说的是整个项目的生命周期，开发人员从获得需求、编写代码、源代码控制、修改代码、测试代码以及维护阶段重构以前的设计和架构，这些往往需要好几个月，有一些项目周期甚至一两年。
所以，可以遇到有的软件开发工程师工作了两三年，依然没有完整完成一个项目的经验。
超长的反馈周期，导致软件开发工程师难以得到充足的反馈，去判断自己的技能程度。
想象一下，一个普通的羽毛球爱好者，和一个羽毛球世界冠军比赛，他肯定不会觉得自己能赢；一个驾驶员，无论他驾驶技术多么的好，也不会自以为自己是舒马赫级别。因为这些反馈都很明显，再自视过高，在真正的高手面前，也会认识到不足。
但编程不同，编程缺乏准确的反馈机制，很容易使一个本身技术不高的人，误以为自己是高手。
在现今的开发环境中，甚至不少还打着“专家”、“架构师”和“负责人”到处招摇撞骗，就像“摇滚明星”一样。
这种人类自视过高，无法准确判断自己的能力高下的现象，美国康乃尔大学的社会心理学家大卫·邓宁和贾斯汀·克鲁格将其归咎于元认知上的缺陷，能力欠缺的人无法认识到自身的无能，不能准确评估自身的能力。
这就是邓宁-克鲁格效应（Dunning-Kruger effect），或简称达克效应（DK effect）。简言之即：庸人容易因欠缺自知之明而自我膨胀。
他们的研究还表明，反之，非常能干的人会低估自己的能力，错误地假定他们自己能够很容易完成的任务，别人也能够很容易地完成。
避免成为专家级新手
既然“专家级新手”是“新手”，那么与真正的专家多交流，是否就可以使其明白自己的不足呢？
这也许是可行的，问题是，“专家级新手”往往成长在一个缺乏专家的环境造就的，例如一家非互联网公司只有两三个懂编程知识的员工，就很容易变成“专家级新手”。
避免成为“专家级新手”，首先需要避免：
◐ 缺乏自动化测试
◐ 巨大、冗长的方法或类
◐ 大量的复制粘贴的代码
◐ 使用过时或者糟糕的工具/流程
但是，这些都是一个个点，这些问题共同的线索指向，你的团队有一个处于权威地位的人，他放任软件崩坏，不推崇健康的开发流程，不重视测试，不重视软件质量，放任有毒的环境蔓延——这将迫使有才华或有抱负的人要么离开，要么顺应平庸。
这时候需要创造一种进取的文化，而不是停滞不前的文化。
首先，为了防止自己落入“专家级新手”的陷阱，最重要的是不要相信自己的炒作。
适当为自己的成就感到自豪，但无论你的头衔、年限、奖项和成就，或者其他任何不是理论证明的东西，都不要认为你的学习已经结束了，也不要认为你的观点高于质疑。保持健康的谦逊度，不断努力提高，重视客观指标高于主观考虑，这将大大防止自己成为“专家初学者”。
在防止这种现象败坏一个软件组方面，以下是一些可以帮助的事情：
㉿ 给予团队成员尽可能多的创作自由，让他们展示自己的解决方法（记住，你从失败中学习的东西比成功更多）；
㉿ 为学习新的语言、方法、框架、模式、风格等提供激励或奖励；
㉿ 避免以在该领域或在公司工作的年限作为偏爱；
㉿ 制定政策，迫使外部观点进入公司（每月培训等）；
㉿ 在可能的情况下，用客观的措施来解决争议/分歧，而不是资历或民主投票等主观因素；
㉿ 创造一种 "证据文化"--除非有独立的说法、数据统计、事实等支持，否则观点并不重要；
㉿ 定期对员工进行民意调查，无论是初级员工还是高级员工，请他们列出自己的一些优势和同等数量的不了解或想了解的知识。
这个清单更多的是针对团队的管理者和领导者，但作为一个简单的团队成员，也可以影响这些变化。
唯一不同的是，你可能要向管理层寻求帮助，或者是劝说而不是强制执行。如果可能的话，要以身作则。如果这一切都不可能，而且这份工作看起来像一个失败的事业，可能需要去寻找更健康的发展环境。
一般来说，重要的是创造或拥有一种文化，在这种文化中，“我不知道”是一个可以接受的答案（这点以后可以展开谈谈），即使是对团队中资历最深、任期最长的领导者来说也是如此。
辨认专家级新手
根据布鲁斯·韦伯斯特的“死海效应”，最有才华的开发人员往往最有市场，因此当他们受到一点委屈时，是最容易另谋高就的。我们当然要及早辨认“专家级新手”，以下是一些常见的特征：
✄ 相信自己所熟练的语言、框架是“银弹”，能解决所有问题；
比如一个 MySQL DBA 还没有用过 NoSQL 就对它嗤之以鼻，这并不是说不喜欢某项技术或者没有使用过某项技术就成了“专家初学者”，而是说“如果它不在我的工具箱里，或者它不是我有过经验的东西，那就不值得去做”这种隐隐约约的独断心态。
✄ 没有兴趣学习新事物，或不理解新趋势发展的背后原因；
对于新技术嗤之以鼻，不去了解新技术诞生的背后原因，前些年 Docker 刚起步的时候，我就听过不少“不就是个虚拟机”这样的声音。对于前后端分离不理解，对于微服务不理解等等。
✄ 倾向以“辈份”来判断技术问题。
“专家级新手”判断技术问题的方法，常常以提出意见者的职位、title、经验甚至年纪去判断，正好就是将十个一年的经验当成十年经验的坏例子。
结语
“专家级新手”是人类认知偏差造成的结果，对公司尤其是科技型公司有着决定性的影响。
最后，不管你是转行也好，初学也罢，进阶也可，如果你想学编程，进阶程序员~
【值得关注】我的 C/C++编程学习交流俱乐部【点击进入】
问题答疑，学习交流，技术探讨，还有超多编程资源大全，零基础的视频也超棒~