避免成为专家级新手

专家级新手

1980 年,德雷福斯兄弟提出一个模型,将一个技能的学习程度类比成阶梯式的模型,由上而下分成:专家(Expert)、精通者(Proficient)、胜任者(Competent)、高级新手(Advanced Beginner)、新手(Novice)五个等级。

这就是德雷福斯模型(Dreyfus model of skill acquisition)。

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

img

德雷福斯模型往往只是一个美好的愿景,也就是每个人都会随着更多的练习,改善自己的技能,从而往上进步。

然而技能的提升并不是线性的,现实中,我们常常可以看见一些“经验和能力不相称”的人,用一句话概括:

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

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

img

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

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

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

这种停滞在平庸的阶段,称之为**“专家级新手(Expert Beginner)”**。

img

软件专家级新手

人类学习一件事物,必须要有现实世界的反馈!

例如:学打羽毛球,要习惯挥拍,要学习阅读球的落点,才能逐渐改善自己的技术;学习驾驶,一样要学会阅读与障碍物的距离,转弯时是否有充足的空间。编程呢?

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

你可能会说,编译、运行或单元测试,不就是不到几分钟甚至几秒的时间吗?

那只是开发,而这里说的是整个项目的生命周期,开发人员从获得需求、编写代码、源代码控制、修改代码、测试代码以及维护阶段重构以前的设计和架构,这些往往需要好几个月,有一些项目周期甚至一两年。

所以,可以遇到有的软件开发工程师工作了两三年,依然没有完整完成一个项目的经验。

img

超长的反馈周期,导致软件开发工程师难以得到充足的反馈,去判断自己的技能程度。

想象一下,一个普通的羽毛球爱好者,和一个羽毛球世界冠军比赛,他肯定不会觉得自己能赢;一个驾驶员,无论他驾驶技术多么的好,也不会自以为自己是舒马赫级别。因为这些反馈都很明显,再自视过高,在真正的高手面前,也会认识到不足。

但编程不同,编程缺乏准确的反馈机制,很容易使一个本身技术不高的人,误以为自己是高手。

在现今的开发环境中,甚至不少还打着“专家”、“架构师”和“负责人”到处招摇撞骗,就像“摇滚明星”一样。

这种人类自视过高,无法准确判断自己的能力高下的现象,美国康乃尔大学的社会心理学家大卫·邓宁和贾斯汀·克鲁格将其归咎于元认知上的缺陷,能力欠缺的人无法认识到自身的无能,不能准确评估自身的能力。

这就是邓宁-克鲁格效应(Dunning-Kruger effect),或简称达克效应(DK effect)。简言之即:庸人容易因欠缺自知之明而自我膨胀。

img

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

避免成为专家级新手

既然“专家级新手”是“新手”,那么与真正的专家多交流,是否就可以使其明白自己的不足呢?

这也许是可行的,问题是,“专家级新手”往往成长在一个缺乏专家的环境造就的,例如一家非互联网公司只有两三个懂编程知识的员工,就很容易变成“专家级新手”。

避免成为“专家级新手”,首先需要避免:

◐ 缺乏自动化测试

◐ 巨大、冗长的方法或类

◐ 大量的复制粘贴的代码

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

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

img

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

首先,为了防止自己落入“专家级新手”的陷阱,最重要的是不要相信自己的炒作。

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

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

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

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

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

制定政策,迫使外部观点进入公司(每月培训等);

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

创造一种 “证据文化”–除非有独立的说法、数据统计、事实等支持,否则观点并不重要;

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

这个清单更多的是针对团队的管理者和领导者,但作为一个简单的团队成员,也可以影响这些变化。

唯一不同的是,你可能要向管理层寻求帮助,或者是劝说而不是强制执行。如果可能的话,要以身作则。如果这一切都不可能,而且这份工作看起来像一个失败的事业,可能需要去寻找更健康的发展环境。

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

辨认专家级新手

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

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

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

✄ 没有兴趣学习新事物,或不理解新趋势发展的背后原因;

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

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

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

结语

“专家级新手”是人类认知偏差造成的结果,对公司尤其是科技型公司有着决定性的影响。

img

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 酷酷鲨 设计师:CSDN官方博客 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值