工程师技能表

上周帮朋友看了一份嵌入式工程师的工程简历。技能栏写得满满当当：C/C++、师技Python、工程RTOS、师技Linux驱动、工程ARM架构、师技I2C/SPI/UART、工程Git、师技Docker……我数了一下，工程列了二十三项。师技我问他，工程这二十三项里，师技有哪几项是工程你最近半年真正碰过的？他想了半天，说大概五六项吧。师技剩下那些，工程是“学过”或者“了解”。

这就是大多数工程师技能表的真实状态——写的是曾经接触过的东西，不是现在能用的东西。

技能表不是收藏夹

我见过太多人把技能表当成收藏夹用。学了一点点就往上加，加完就再也不碰了。这跟办了健身卡就觉得自己已经健身了是一个道理。

真正有效的技能表应该像工具箱，不是仓库。工具箱里放的是你随手能拿起来用的家伙，仓库里堆的是“以后可能用得上”的东西。区别在于：工具箱里的每一件，你都知道放在哪、怎么用、什么时候该用。

我自己维护技能表的方式很简单。每年年初列一遍，然后问自己三个问题：这项技能我去年用过吗？遇到相关问题时我第一时间能想起来用它吗？如果明天有个项目需要它，我敢接吗？三个问题有两个答不上来，就从表里划掉。划掉不丢人，留着不会用才丢人。

硬技能和软技能的分界线没那么清楚

传统上我们把技能分成硬技能和软技能。硬技能是写代码、画电路图、调参数；软技能是沟通、协作、写文档。这个分法有个问题：它暗示硬技能更重要，软技能是锦上添花。

实际情况恰恰相反。我做过一个粗略统计——过去三年我参与的项目里，延期或出问题的原因，技术难点攻克不了的不到两成，剩下八成全是沟通问题。需求没对齐、接口没定义清楚、文档写得别人看不懂、开会没人做记录导致同一个问题讨论三遍。

有个具体的例子。前年做一个数据采集系统，硬件和软件两边各自都按时完成了自己的模块。联调的时候发现，硬件传上来的数据帧格式和软件解析的格式对不上。硬件工程师说“我按协议文档写的”，软件工程师说“我也是按协议文档写的”。把文档翻出来一看，文档里关于字节序的描述只有一句话：“采用标准字节序”。什么叫标准？大端还是小端？没人知道。这个问题花了两天排查，改代码只用十分钟。

所以我现在看技能表，会特别关注一项：能不能把一件技术上的事，跟非技术的人讲明白。这项能力比多会一门语言值钱得多。

深度比广度值钱，但深度需要广度来喂

经常有人争论：工程师应该深耕一个领域，还是广泛涉猎？我的观察是，这两件事不是对立的，是有先后顺序的。

没有广度的深度容易钻牛角尖。你只懂C语言，遇到性能问题就只会从代码层面找原因，不知道可能是缓存命中率的问题、可能是内存对齐的问题、可能是编译器优化选项的问题。你只懂数字电路，遇到信号完整性问题就只会换更贵的芯片，不知道可能是PCB布局的问题。

反过来，没有深度的广度就是刚才说的收藏夹——什么都知道一点，什么都不精。遇到真正棘手的问题，还是得找那个“只懂一件事但懂到骨子里”的人。

我的建议是：先在一个方向上扎到能独立解决这个领域80%问题的程度，然后再往外扩。扩的时候不是随便学，是带着当前领域的问题去找答案。做嵌入式的去学一点编译原理，做后端的去学一点网络底层，做前端的去学一点图形学。这种带着问题的学习，效率比漫无目的地刷课程高得多。

技能表需要定期做减法

最后说一个反直觉的观点：技能表的价值不在于上面有多少项，而在于划掉了多少项。

划掉意味着你承认自己没精力维护那么多技能，意味着你把时间集中在了更少的事情上。一个写了十项但每项都扎实的工程师，比写了三十项但大部分是“了解”的工程师，靠谱程度不在一个量级。

我现在的技能表上只有七项。每一项后面都标着最近一次使用的日期。超过一年没用的，下次更新时就删掉。删掉不代表不会，只是代表它不再是我工具箱里的常用工具了。工具箱就那么大，得留给真正趁手的东西。

本文地址：http://www.79wt.cn/news/759d9199149.html