论“有经验”的工程师

上个星期跟同事一起讨论什么是有经验的工程师的问题,使我我觉得很多人对“有经验”的定义有很大的偏差。因此我想分享我对这个问题的看法。首先看一下经验的定义。

第一种定义,工作时间越长越有经验。经常有人会问我这样的问题,“我们需要找一个有五年左右工作经验的.Net工程师,我们应该考什么样的题目”,猎头经常会问我:“你们需要的大约有多少年经验的工程师”。一般人会把经验值与工作年限画一个等号。其实这两者之间有一定的联系,但两者之间没有一个公式,更谈不上一种线性关系(工作时间越长,越有经验)。Bob大叔有一篇文章叫”Multi-Dimension Seniority“,分析了其中的道理。参见下图:

就像一般人一样,在Sam刚刚开始工作时期,由于基本上是一张白纸,需要学习基本的技能,因此这一个阶段是一个不断学习的阶段,在这期间他的经验值是在不断增长的。但是随着他能够承担一部分任务,他用在学习的上的时间开始变少,因此从这个阶段尽管经验还在增长,但是增长速度要比前一阶段慢很多,因此他一直都只能在“学徒”(Apprentice) 层次。很明显他的经验值,资深程度跟他的工作年限没有很大的关系。
Jasmine就不同了,她没有停止学习,不停地实践,因此她的经验随着时间不断增长,最终达到“大师”(Master)层次。Jasmine的经验是随着工作年限增长而不断丰富的。但是这种人在现实中是极少数,而且是需要环境的。

第二种定义,知识或技能越多越有经验。很多人热衷于研究很多新的技术,技巧,新的工具,热衷于考各种证书(曾经见过一个简历,这个Candidate在一年之内拿到了PMP, OCP, MCTS, IBM Certified Solution Designer, Microsoft Certified Business Management Solutions Specialist )。可是这只能证明这些人了解过这方面的东西,并不代表这些人能够熟练的使用这些技术技巧解决问题。一个看过了《七天学会Pascal》的人,掌握了Pascal的基本知识,但是这并不意味着他能够写出好的Pascal程序。有很多的知识和技能(Knowledge & Skill)当然不是坏事,但是这不等同于有能力。一个工程师即使了解很多新的技术,也不代表他能写出好的代码。如果一个工程师能优雅地设计出软件系统。写出整洁的代码(Clean Code),能够设计出巧妙的架构,这代表的就是能力(Competence)。知识和技能只能算是能力的一个必要条件。历史上有一个著名的例子,“纸上谈兵”。赵括熟读了很多兵书,应该说很有知识,而能力却很差,结果葬送了四十万大军和整个赵国。

因此应该转换观念,不仅仅以工作时间长短或者了解多少技术、技能来衡量水平高低。我们真正应该关注的是能力(Competence),也就是在实际工作中,通过灵活运用掌握的技术、技巧来解决实际问题的能力。显然,能力高低比知识的多少要难衡量得多。能力绝对不是可以通过考试衡量出来的。现在市场上充斥着各种各样的证书,其实绝大多数都是衡量知识,跟能力没有太大的关系。衡量能力需要通过一种客观的社会评价体系。其实就是需要类似于学术界的“科学引文索引SCI”的系统,一篇论文质量的高低,取决于该论文被引用的次数,引用次数越多说明论文越有价值,当然也就客观地反映了作者的能力。对于软件领域,也有一些类似的客观标准,比如:所贡献的开源软件的下载次数,被使用的次数;出版的有影响力的书籍、论文、博客文章;在社区中的口碑等等。Google也是利用这种类似的系统来对关键词的相似度进行排名,还有一个简单的例子就是博客园的“我推荐”。其实还有一些是衡量能力的证书,比如Certified Scrum Master其实是一个衡量知识的证书,但是Certified Scrum Practitioner就是一个衡量能力的证书。

 

那什么样的能力对工程师来说最重要呢?我认为有两种

  • 首先是抽象(Abstraction)能力,对于任何的问题都能通过分析系统的表现,抽象出它的本质,然后使用相应的模式去解决。设计软件架构,说白了就是一个关于抽象的问题,设计架构其实就是要决定哪些地方需要预留扩展,因此需要抽象;哪些地方比较雷同,需要抽象出共同的模式。
  • 其次是做权衡(Tradeoff)的能力,设计没有好坏,也没有绝对,并不使用最新的、最酷的技术就是最好的设计。大系统的设计都是受各种因素制约的(用英语说就是It depends),真正有经验的工程师能够根据各种项目因素做出合适的选择。
培养这两种能力的方法很简单,就是多学多练。通过不断的学习,扩充自己的知识面,掌握更多的模式,从而能够在实际工作中用合适的工具、方法、模式去解决问题;其次就要通过不断实践学到的东西。这其实就是一个理论->实践->理论不断反复的过程。

 

Share