不要成为“专家级新手”

技术类文章放到周一到周五发，周末分享一些个人成长、时间管理的文章。

最近我报了个班，学习打羽毛球。

我一直觉得自己的运动能力还不错，无论是跑步、篮球和羽毛球，虽然我都是自己打着玩，从来没有系统的学过。凭着还不错的身体反应，和大部分人打还能有来有回，有时候还能取胜，以为自己打得还可以。但是时间久了，我就发现我不会再进步了，我开始遇到会打一点的对手，接不好别人网前吊球，高远球也打得不到位。

第一次练球教练看了我打几个球后，就让我改握拍、挥拍的方式，教练说原因很简单，错误的动作导致我再按之前的打法已经无法打得更好了，往后的很多动作都不能做不到位。

在我修改打球动作后，我开始对此感到抵触，因为我发现自己水平倒退了！甚至我会接不了一些很简单的球。教练却表示就是这样，在你变得更好之前，你会变得更糟，你甚至需要一段时间来恢复现在的水平！

果然，继续练了两个月，我才开始打得有模有样。我开始思考学习的曲线，如果以错误的方式学习，我们前期可能会取得一些进展，但无疑会在某个点停滞，此时要么放弃，有的人因为时间或者毅力或者没有去寻找更好的方式等等原因，停留在此；要么更正学习方式——而代价就是，这可能会让我们感到倒退，然后付诸努力，才能变得更好。

专家级新手

1980 年，德雷福斯兄弟提出一个模型，将一个技能的学习程度类比成阶梯式的模型，由上而下分成：专家（Expert）、精通者（Proficient）、胜任者（Competent）、高级新手（Advanced Beginner）、新手（Novice）五个等级。也就是德雷福斯模型（Dreyfus model of skill acquisition）。

基于这个模型德雷福斯兄弟写了一本书，显然它有很多内容，但它的要点是，技能学习者需要从“教条主义地遵循规则和缺乏大局”转向“直觉超越规则和完全理解大局”——也就是说愈往上，愈具有大局观。

德雷福斯模型往往只是一个美好的愿景，也就是每个人都会随着更多的练习，改善自己的技能，从而往上进步。然而技能的提升并不是线性的，现实中，我们常常可以看见一些“经验和能力不相称”的人，用一句话概括：

十年经验，不是一个经验用十年。

资料显示，多数人落在“高级新手”这一阶层，“高级新手”不愿意全盘思考，当管理阶层分配工作给“高级新手”，他们认为每项工作一样重要，不明了优先层度，意味着他们无法认知每件工作的相关性。

停留在“高级新手”的人常常停滞发展，在学习技能的角度上，一个人的技术水平停止发展常常由于以下两个原因：天赋或不再有继续改进的意愿。

在本文，我们放弃考虑第一种可能性（绝大多数程序员在达到胜任标准之前都不会用尽天赋），并且考虑一个“不再有继续改进的意愿”的可能：由于自信已达到专家地位而自愿停止改进，因此不可能进一步改进。

不知道你有没有过这样的经历，看一本书看到一半就放回书架，再也没有拿出来过；一门课程学了三分之一然后半途而废，之后再也想不起这门课到底讲了些什么。

这种停滞在平庸的阶段，称之为“专家级新手（Expert Beginner）”。

软件专家级新手

人类学习一件事物，必须要有现实世界的反馈，例如：学打羽毛球，要习惯挥拍，要学习阅读球的落点，才能逐渐改善自己的技术；学习驾驶，一样要学会阅读与障碍物的距离，转弯时是否有充足的空间。编程呢？

编程的反馈周期很长，它不像日常生活的技能或体育运动，反馈周期是以分钟计算的，在软件中，反馈周期往往是几个月，软件行业很容易诞生“专家级新手”。

你可能会说，编译、运行或单元测试，不就是不到几分钟甚至几秒的时间吗？那只是开发，而这里说的是整个项目的生命周期，开发人员从获得需求、编写代码、源代码控制、修改代码、测试代码以及维护阶段重构以前的设计和架构，这些往往需要好几个月，有一些项目周期甚至一两年。所以，可以遇到有的软件开发工程师工作了两三年，依然没有完整完成一个项目的经验。

超长的反馈周期，导致软件开发工程师难以得到充足的反馈，去判断自己的技能程度。想象一下，一个普通的羽毛球爱好者，和一个羽毛球世界冠军比赛，他肯定不会觉得自己能赢；一个驾驶员，无论他驾驶技术多么的好，也不会自以为自己是舒马赫级别。因为这些反馈都很明显，再自视过高，在真正的高手面前，也会认识到不足。

但编程不同，编程缺乏准确的反馈机制，很容易使一个本身技术不高的人，误以为自己是高手。在现今的开发环境中，甚至不少还打着“专家”、“架构师”和“负责人”到处招摇撞骗，就像“摇滚明星”一样。

这种人类自视过高，无法准确判断自己的能力高下的现象，美国康乃尔大学的社会心理学家大卫·邓宁和贾斯汀·克鲁格将其归咎于元认知上的缺陷，能力欠缺的人无法认识到自身的无能，不能准确评估自身的能力。这就是邓宁-克鲁格效应（Dunning-Kruger effect），或简称达克效应（DK effect）。简言之即：庸人容易因欠缺自知之明而自我膨胀。

他们的研究还表明，反之，非常能干的人会低估自己的能力，错误地假定他们自己能够很容易完成的任务，别人也能够很容易地完成。

避免成为专家级新手

既然“专家级新手”是“新手”，那么与真正的专家多交流，是否就可以使其明白自己的不足呢？这也许是可行的，问题是，“专家级新手”往往成长在一个缺乏专家的环境造就的，例如一家非互联网公司只有两三个懂编程知识的员工，就很容易变成“专家级新手”。

避免成为“专家级新手”，首先需要避免：

• 缺乏自动化测试

• 巨大、冗长的方法或类

• 大量的复制粘贴的代码

• 使用过时或者糟糕的工具/流程

但是，这些都是一个个点，这些问题共同的线索指向，你的团队有一个处于权威地位的人，他放任软件崩坏，不推崇健康的开发流程，不重视测试，不重视软件质量，放任有毒的环境蔓延——这将迫使有才华或有抱负的人要么离开，要么顺应平庸。

这时候需要创造一种进取的文化，而不是停滞不前的文化。

首先，为了防止自己落入“专家级新手”的陷阱，最重要的是不要相信自己的炒作。适当为自己的成就感到自豪，但无论你的头衔、年限、奖项和成就，或者其他任何不是理论证明的东西，都不要认为你的学习已经结束了，也不要认为你的观点高于质疑。保持健康的谦逊度，不断努力提高，重视客观指标高于主观考虑，这将大大防止自己成为“专家初学者”。

在防止这种现象败坏一个软件组方面，以下是一些可以帮助的事情：

1. 给予团队成员尽可能多的创作自由，让他们展示自己的解决方法（记住，你从失败中学习的东西比成功更多）

2. 为学习新的语言、方法、框架、模式、风格等提供激励或奖励

3. 避免以在该领域或在公司工作的年限作为偏爱

4. 制定政策，迫使外部观点进入公司（每月培训等）

5. 在可能的情况下，用客观的措施来解决争议/分歧，而不是资历或民主投票等主观因素

6. 创造一种 "证据文化"--除非有独立的说法、数据统计、事实等支持，否则观点并不重要

7. 定期对员工进行民意调查，无论是初级员工还是高级员工，请他们列出自己的一些优势和同等数量的不了解或想了解的知识

这个清单更多的是针对团队的管理者和领导者，但作为一个简单的团队成员，也可以影响这些变化。唯一不同的是，你可能要向管理层寻求帮助，或者是劝说而不是强制执行。如果可能的话，要以身作则。如果这一切都不可能，而且这份工作看起来像一个失败的事业，可能需要去寻找更健康的发展环境。

一般来说，重要的是创造或拥有一种文化，在这种文化中，“我不知道”是一个可以接受的答案（这点以后可以展开谈谈），即使是对团队中资历最深、任期最长的领导者来说也是如此。

辨认专家级新手

根据布鲁斯·韦伯斯特的“死海效应”，最有才华的开发人员往往最有市场，因此当他们受到一点委屈时，是最容易另谋高就的。我们当然要及早辨认“专家级新手”，以下是一些常见的特征：

1. 相信自己所熟练的语言、框架是“银弹”，能解决所有问题

   比如一个 MySQL DBA 还没有用过 NoSQL 就对它嗤之以鼻，这并不是说不喜欢某项技术或者没有使用过某项技术就成了“专家初学者”，而是说“如果它不在我的工具箱里，或者它不是我有过经验的东西，那就不值得去做”这种隐隐约约的独断心态。

2. 没有兴趣学习新事物，或不理解新趋势发展的背后原因

   对于新技术嗤之以鼻，不去了解新技术诞生的背后原因，前些年 Docker 刚起步的时候，我就听过不少“不就是个虚拟机”这样的声音。对于前后端分离不理解，对于微服务不理解等等。

3. 倾向以“辈份”来判断技术问题。

   “专家级新手”判断技术问题的方法，常常以提出意见者的职位、title、经验甚至年纪去判断，正好就是将十个一年的经验当成十年经验的坏例子。

结语

“专家级新手”是人类认知偏差造成的结果，对公司尤其是科技型公司有着决定性的影响。本文的“专家级新手”等其它概念，来源于一篇外网流传颇广的博客：How Developers Stop Learning: Rise of the Expert Beginner，读者如有兴趣了解更多，可以详加阅读。