在旧文《程序员的成长阶梯和级别定义》中定义了一个程序员的成长阶梯，大概有下面几个阶段：
- 初级
- 中级
- 高级
- 资深
- 专家
很遗憾，当时到了专家这个阶段，我就没法给出很明确的答案了。只说了，职业成长就像爬楼，每一个级别就像一个楼层。但到了一定阶段（每个人的阶段不会一样）会发现上面似乎还有几层但却看不见下一层的楼梯了。
这就是本文想探讨的，关于成长阶梯的断层。
定义
因为之前我已经走到了资深阶段，并停留了一段时间，所以我的断层出现在从资深到专家之间。
旧文中，我用一种模糊怀疑的语气表达过关于专家的定义 —— 专家可能就是这个领域内你绕不过去的人吧。如今看来，这个定义太大。比如，若你处在物理学领域，牛顿就是你绕不过去的人，之后是爱因斯坦。而在计算机领域，图灵定义了计算机的边界，也是这个领域绕不过去的人。但这样的天才人物，百年来才出一个，那么这样的定义也就失去了指导意义。
这个定义中包含两个点，一是领域、另一个是绕不过去。第一点表达了某个范围，第二个则模糊的表达了这个范围的大小，绕不过去其实就是一个很大的范围了。如今反思，其实用这两点来定义专家也是可以的，只是需要更清晰的量化下。
大至国家、社会、行业，小到公司、团队、小组都有自己关于专家的定义。曾经，好些年前，我最早在公司几个同事组成的小组内研究引入 Java NIO 的技术来编写网络程序，读了一些相关的书和开源框架代码（Mina、Netty），周围的几个同事就戏称我为 Java NIO 的专家。这就是用领域（Java NIO 是一个很细分的技术领域）加范围（局限于周围组内几个同事，他们要解决 NIO 的网络编程问题都绕不过我）定义专家的方式。
因而，像前面说的爱因斯坦、牛顿、图灵，他们既是行业（学科维度）范围内的，也是世界（地理维度）范围内的专家。而公司内的专家职级定义，其范围，无非就是与公司经营相关的领域，其大小无非就是公司组织架构的某一层级之内。
这样理解，公司范围的专家领域定义，包含了两块：责任域和能力域。而能力域，又进步一细分为业务和技术两方面。蜘蛛侠里有句台词是这样说的：能力越大，责任越大（With great power comes great responsibility），能力和责任总是相辅相成。
识别
有了专家的定义，不代表就能很容易识别出来，而成为专家就是要建立可识别的领域。
公司大了后，经营业务广泛，涉及的技术领域也很广泛，所以公司不是只需要一个专家，而是需要很多不同领域的专家。都是专家，但大家处在不同的识别领域范围之内。
公司的专家领域内，责任域相对还容易识别。但与能力域有关的业务和技术则过于抽象，很难清晰识别。所以对于专家的可识别领域，其实主要还是通过作品来体现的。作品是以一定形式表现出来的智力成果，而前面爱因斯坦、牛顿、图灵，他们作品的一定形式都是通过理论来体现的。
因此，公司内所有的晋升述职都只是为了一个目的：识别员工的领域和范围，且在多大范围内获得了认可，再贴上一个对应的职级标签。而这个识别过程是非常短暂的，需要把 1 到 2 年的工作成果、能力成长、领域边界，在 10 到 20 分钟的时间范围内表现出来。所以，这个过程是肯定不完美的，而且也没法精确量化出识别的准确率。
之所以在有限的时间范围内需要完成这个过程，对公司是一个成本问题。述职人员在有限的时间内展示了几个点，对评审识别人员来说，就像在管中窥豹。看不到全貌，看完几个特征点，然后就需要判断这是豹子（符合下一级别的晋升标准）还是猫（不符合）。
我在做晋升评审时，就一直被这样的判断所困扰，多数述职同事都在这几个点上表现的很好。这就像是说，如果是豹子，它确实该有这些特征，反过来，拥有这些特征一定就是豹子么？这些特征点，是豹子的唯一或足够有区分度的标志性特征吗？
而站在述职答辩人的角度，他的表达和展现更多的不应该是点，而是先有整体（面），再深入局部（点），这应该是一个画龙点睛的过程。
识别的过程，本质是在解一个概率问题。当参与这个过程的两方都这样努力去考虑时，我想这样的过程会有更高的准确率。
路径
成为专家，就是建立领域的过程，那么如何建立更大范围且更具识别性的领域呢？这就是这个路径中的非连续性断层问题。
每个人在成长过程中，从新人到初级到高级，甚至到资深都可以是一个连续阶段，从生到熟的一个过程。熟到了一定程度，就会发现成长进入了高原期。
最近，读到一篇吴军的文章，也提到了工程师成长过程中的类似问题，他用了一个公式来定义：
成就 ＝ 成功率 x 事情的量级 x 做事的速度
连续的成长阶段，我们的成长主要体现在不断提升做事的熟练度（也就是上述公式中的速度和成功率），但这两个指标到了一定的熟练度阶段后就会碰到物理极限。实际情况是，一个资深的工程师的速度甚至不会比一个初级工程师快两倍，但可能成功率会高几倍，甚至十倍，这就是传说中的一个顶十个的程序员，但离极限也就差不远了。
而更是传说中以一敌百的程序员，只有一个可能，他们做的事情和其他人不在一个了量级。现实案例中，就有如 Linus 这样的人。所以，一直做同样的事，都是写代码，也可以跨越断层。但关键是，你写的代码体现在什么量级的事情上。
这里公式中的成就，也可以通过作品域来体现，就像水泥和砖头不是作品，大教堂才是。代码本身不是作品，它只是作品的原料。
作为程序员，我们会有直观的感受，用户量级越过了一定的门槛后，我们编写、维护和部署程序系统的方式都会发生本质的变化。而提升量级、最难得就在于我们要放下曾经熟悉的方式和习惯，要站在更高的维度去看更大量级的事情，并且找到适合这个量级事情的合适解决方案。
...
看得见断层不见得就跨得过去，但看得见至少多了一种选择，而看不见则很可能一直在原地转圈。
写点文字，画点画儿，记录成长瞬间。
微信公众号「瞬息之间」，既然遇见，不如同行。
