当我们说"有经验"时，我们在说什么

[TOC]

本文整理了对”有经验”这一概念的理解。

生活工作中有一些厉害的人，能够很快地解决别人不能解决或者无法优雅地解决的问题，这个时候我们会赞叹他们好有经验。另一方面很多人在自己面试的简历中描述自己对某项技术很有经验，吸引 HR 的眼睛。那究竟什么才叫做”有经验”呢？

这个问题没法定量地去定义，我们无法说一个人解决了一个问题的次数大于 N 次就算有经验，因为不同问题的性质以及重要性都不一样。也没有办法说一个人修了多少门课，拿到了多少资格证就是有经验的，实际成果是检验的唯一标准，丢书包不是。更不能说一个人写了一手好 PPT，前说历史，再说当下，最后描绘远景，说的绘声绘色，但是拿一个基本的细节来问他，他答不出来的情况下，说他是”有经验”的。

缺乏直接量化标准下，很多人用工作/使用年限来区分一个人是否有经验。诚然这是个比较综合的指标，一般而言能保证有经验的”下限”。但是也无法精确的确定到底是不是满足需求的 experienced。所以还是要靠面试的问询来判断，这个时候很多情况下取决于个人的判断甚至是直觉。

我觉得有必要探讨一下这个概念。原因有 2 个:

1. 应该有很多人跟我一样希望成为一个”富有经验”的开发人员(experienced developer)。既然想要实现得有具体的目标吧，探讨这个概念也是给自己明确目标的过程（卷起来吧，少年）。
2. 我们周围有一些厉害的人，我想应该也有很多人跟我一样希望向他们学习，甚至是超越他们。问题是 how? 很多时候大牛们解决问题的过程对我们都像是黑盒一样（毕竟大家都很忙不会心善地跟我们一步步地解释），学习起来毫无头绪。但是一旦我们有了自己对于”有经验”这一概念的理解，我们相当于搭建了一个框架，在这个框架内把大牛的行为进行拆解分析，肯定要比毫无头绪要强很多。

对于这个概念，我思考了一段时间有了如下定性的描述，很浅薄，也许后面在新的认知构建循环中，这些理解会重构。

1. 有经验的人一定是问题解决导向的。空想的没有解决过问题或者是压根不想去解决问题，天天打嘴炮的人不能称作有经验的人。也可以换一种说法，有经验中的经验是指”有效的”的经验，也就是这段经验是通过解决现实中问题从而产生具体价值的经验。当然这里不是排斥纯搞理论的人。以问题抽象化理论化为主要方向的人，我觉得应该被称作专家(expert)。有经验与专家不是对立的，一个专家可以是丰富经验的实际问题解决者，一个有经验的人也必定欢迎抽象化的过程，这会带来解决更复杂问题的可能性。

2. 有经验是领域限定的。因为任何领域挖到深处都是无底洞，甚至需要一个人投入全部的精力也不一定能理解很深。即便有些天才型的选手能做到多个领域颇有建树，也不能武断地说自己精通所有领域。我觉得比较准确的说法应该是某人在 A, B, C 领域上很有经验。

3. 有经验的人有一些代表性的表征(过人的)。例如，能快速地找到问题的症结/突破口给出解决的方案，当然速度是相对的。再例如，有经验的人对问题有一定的预测能力，他们能结合之前的经历以及理论分析，套入当下的问题情景中，预测下一步甚至是好几步后的结果，然后根据不同的结果分别进行应对调整。再例如，有经验的人能够将复杂的东西用比较简单的形式表述出来，让别人一下子就理解了，因为对现象以及问题知根知底的他们能理解到最关键的点，以及点与点之间的联系从而能够比较简洁地展示出来。还有一些其他特征，这里不一一列举出来。

4. 有经验的人有自己的框架/链条。比如 debug 时，有经验的人脑海里会有一条链，这条链不仅包含了自己操作的每一步，也包含了与其他领域的结合点。他们会从一步步地 log/打印信息等逐渐锁定问题所在，而不是仅仅在网上搜索别人是不是有分享出来跟自己遇到的类似的问题。至于框架则是对错综复杂想化交叉链条的归并整理的结果。

前 3 条基本上描述表现的，是有经验的人展现出来的结果，只能说富有指导意义。只有最后一条，貌似具有一定的实施性，下面是我自己的一些粗浅尝试。

如下图所示这个框架有 3 个模块，分别是知识(Knowledge)，技能(Skill)，认知(Cognition). 分别介绍它们的含义。

知识的特点如下

• 知识是无限的。因此我们无法全部记住，如何管理我们的知识，在需要的时候能够快速地查找到，出现新的知识能够很方便地融入到知识管理体系中等问题，是非常重要的挑战。
• 知识是点状分布的。虽然学科内，领域内的知识很多是有明显的脉络可循的，但是放到全局的视角来看知识基本上都是零散分布的。很多时候学了这些知识，我们并不知道它们的具体应用场景，即便它们对我们解决问题很有帮助。换句话说，我们需要通过一条富有逻辑性/实际意义的链将这些知识串起来，我们才知道这些知识点的用处。
• 知识是用进废退的。学习了知识如果不通过某种形式的应用，我们很快会忘记它。如果我们实际使用它们，我们会对它有更深的理解，记得更加牢固。这也就是上一条中的链，也就是使用的问题场景将知识点相互联系组成了链。

技能的特点如下:

• 技能是复杂而又简单的。这种矛盾性的意思是面对复杂的实际场景，我们为了解决问题可能不需要知道它背后的原理，只需要知道执行什么样的操作能解决就行。因此是简单的。例如，使用 Git 解决版本管理问题，我们不需要知道它后面的诸多原理(例如基于文件链表的文件管理系统，通信机制，文件比对，文件压缩，与其他版本管理系统的区分等)，只需要知道想要推版本时，出现冲突时，回退时等场景下的操作即可。因此很多情况下，skilled 这个概念会被误认为是 experienced 的。因为从结果的角度来看，有技能的人的确解决了很多问题(黑猫白猫抓到老鼠就是好猫)。但是 skilled 绝不是 experienced，因为仅仅有技能很有可能没有推广问题的解决能力。例如仅仅沉迷于 Git 的使用，当公司突然切换到了 SVN 时就不会了，需要再重新磨合一番才掌握使用。但是 experienced 的人会明白操作的指令后面对应的原理是什么，即便切换了指令系统，也能较快地理解另一套指令系统，完成切换解决新的问题。这里并不是在贬低 skilled，下面第三条有进一步地解释。
• 技能的终点是应激式反应。当一个人技能的熟练度达到最高时，应用一项技术仿佛成了本能性地应激式反应。就像卖油翁所说”无他，但手熟尔”. 这也就是说有些技能/操作学习的成本稍高，但需要我们反复的练习，才能实现效果(例如提升效率)。哪怕是我们知道原理的情况下。我们不能轻视技能，技能是问题解决步骤最直接关联的，反映的是一个人快速准确解决现实问题的能力。
• 技能是有一定模式可循的。这个模式可以用大白话的”套路”来解释。如果放到编程技术中，有一个概念可以很好地契合，那就是设计模式。即便对原理所知甚少，但问题解决多了，总会发现问题的相似处以及解决问题的一些思路。例如，if-else 式的分类，分层次，随机采样试错，隔离与对比，PID 式参数 tuning等等。熟练掌握这些模式也是很难的。因此第一条中貌似在贬低 skilled 抬高 experienced，其实并不然，skilled 与 experienced 是从两个角度刻画实际问题的复杂度。

认知的特点如下:

• 认知具有方向性的指导意义。方向性最典型的例子便是 0-1 区别，例如知道与不知道的区别。举个极端的例子，一个人不知道 Git 或者其他版本软件管理系统。投入了很多时间手动比对版本，保存版本，甚至开发一些脚本执行很多操作。如果他知道存在现成的轮子，他很有可能直接拿来用，或者研究其代码。当然这个例子很极端，再举一个我最近的实际感触做例子(不是 0-1 方向性而是更复杂的方向性)。在自学《编译原理》的正则表达式算法 NFA 时，我发现有限状态自动机的求解一般采样图搜索算法。这是我万万没想到的，在我以往的印象中像图搜索算法貌似只用在网格状的模型中，然而只要是有独立状态并能够联通并且组织成 open_set 与 close_set 的模型，其实都可以运用图搜索算法来解决。这种意识仿佛打通了次元壁，提升了 认知，这不仅仅在于联通了图搜索算法与状态机之间的链条，更刺激我思考我对于其他的算法是不是也都形成了固化的印象，这种固化影响了我对算法的进一步理解？对接下来接触的算法是否能够在理解步骤的基础上跳出步骤思考这个算法更加抽象也更加具有普适的意义？
• 认知决定了准入性。其实如果泛化一点的说的话，这一点的意思是认知带来的是对我们对万事万物之间界限的判断。只不过从开发(问题解决)的角度来看，界限变成了我们对事物的接收度量。例如，商品企划/系统需求提出的产品需求，我们能够做出综合的判断，在有限的时间与资源内，哪些需求能通过什么样的技术架构最终实现什么样的结果。当甲方也无法准确描述自己需求时，通过对他们表述的识别，我们做出更具实现性的提案让甲方满意。老板说新问题什么时间能解决时，我们心里快速计算各种决定项目的因素给出一个时间。几个算法/技术即将引入系统中解决问题，没有时间用实际的效果进行比对选定时，我们能够做出判断哪个是最适合的。
• 认知有时候是直觉性的。有时候我们并没有经历一个明显的思考过程就可以做出令自己信服的判断，这就是直觉。这种直觉不是本能，而是需要千百次的反复思考与锤炼，思考的实际过程变成了”后台隐藏”式的。换句话说，看起来是没经过思考作出的判断，其实只要给出一点时间就可以把整个推演过程复现出来。

这个框架如何使用呢？

1. 用法1: 模块间组合成经验链。

上午提及到，我们如果想要真正理解记住知识，熟练应用技能，最终提升认知水平的话，我们需要通过实际的问题解决过程将各个要素串成链。下面是几个典型的链的过程。

• $K \rightarrow S \rightarrow C$: 这种模式是本科生时期最常见的模式，例如学习微机原理讲义，然后通过面包板上安装 8086 处理器，开关，灯泡，电源等器件掌握实际的操作，最后理解这门课程的应用，方法论等。
• $S \rightarrow K \rightarrow S \rightarrow C$: 这种模式在工作中最为常见。工作中接触到了问题使用以往的知识技能无法解决，补习相关知识，然后验证其有效性最后形成认知提升。
• $C \rightarrow K \rightarrow S \rightarrow C$: 这种模式在很多创新工作中比较常见。有一个想法想要实现，学习知识后去实际验证，解决预想的需求问题，根据解决的结果调整之前的猜想并进入下一轮循环。

2. 用法2: 单个模块的深入理解。

• 知识模块: 例如，挑选合适的知识学习/参考/查找资源，知识管理体系的搭建，知识的可视化等。
• 技能模块: 例如，技能的记录与沉淀，从技能中推测原理，总结技能中的模式，驱动知识记忆与运用的强化等。
• 认知模块: 例如，思考的习惯，批判性思维能力的锻炼，对于反直觉的敏感度的提升等。

总结:

本文粗略地整理了我最近对于”有经验”这个概念的思考，没有经过认知学等学科基础知识的洗礼，因此都是自己在实际解决问题的过程中琢磨出来的粗浅的感触。望轻喷。