Teaser Image

mindwind

十日画一水,五日画一石




在旧文《程序员的成长阶梯和级别定义》中定义了一个程序员的成长阶梯,大概有下面几个阶段:

  • 初级
  • 中级
  • 高级
  • 资深
  • 专家

很遗憾,当时到了专家这个阶段,我就没法给出很明确的答案了。只说了,职业成长就像爬楼,每一个级别就像一个楼层。但到了一定阶段(每个人的阶段不会一样)会发现上面似乎还有几层但却看不见下一层的楼梯了。

这就是本文想探讨的,关于成长阶梯的断层。

定义

因为之前我已经走到了资深阶段,并停留了一段时间,所以我的断层出现在从资深到专家之间。

旧文中,我用一种模糊怀疑的语气表达过关于专家的定义 —— 专家可能就是这个领域内你绕不过去的人吧。如今看来,这个定义太大。比如,若你处在物理学领域,牛顿就是你绕不过去的人,之后是爱因斯坦。而在计算机领域,图灵定义了计算机的边界,也是这个领域绕不过去的人。但这样的天才人物,百年来才出一个,那么这样的定义也就失去了指导意义。

这个定义中包含两个点,一是领域、另一个是绕不过去。第一点表达了某个范围,第二个则模糊的表达了这个范围的大小,绕不过去其实就是一个很大的范围了。如今反思,其实用这两点来定义专家也是可以的,只是需要更清晰的量化下。

大至国家、社会、行业,小到公司、团队、小组都有自己关于专家的定义。曾经,好些年前,我最早在公司几个同事组成的小组内研究引入 Java NIO 的技术来编写网络程序,读了一些相关的书和开源框架代码(Mina、Netty),周围的几个同事就戏称我为 Java NIO 的专家。这就是用领域(Java NIO 是一个很细分的技术领域)加范围(局限于周围组内几个同事,他们要解决 NIO 的网络编程问题都绕不过我)定义专家的方式。

因而,像前面说的爱因斯坦、牛顿、图灵,他们既是行业(学科维度)范围内的,也是世界(地理维度)范围内的专家。而公司内的专家职级定义,其范围,无非就是与公司经营相关的领域,其大小无非就是公司组织架构的某一层级之内。

这样理解,公司范围的专家领域定义,包含了两块:责任域和能力域。而能力域,又进步一细分为业务和技术两方面。蜘蛛侠里有句台词是这样说的:能力越大,责任越大(With great power comes great responsibility),能力和责任总是相辅相成。

识别

有了专家的定义,不代表就能很容易识别出来,而成为专家就是要建立可识别的领域。

公司大了后,经营业务广泛,涉及的技术领域也很广泛,所以公司不是只需要一个专家,而是需要很多不同领域的专家。都是专家,但大家处在不同的识别领域范围之内。

公司的专家领域内,责任域相对还容易识别。但与能力域有关的业务和技术则过于抽象,很难清晰识别。所以对于专家的可识别领域,其实主要还是通过作品来体现的。作品是以一定形式表现出来的智力成果,而前面爱因斯坦、牛顿、图灵,他们作品的一定形式都是通过理论来体现的。

因此,公司内所有的晋升述职都只是为了一个目的:识别员工的领域和范围,且在多大范围内获得了认可,再贴上一个对应的职级标签。而这个识别过程是非常短暂的,需要把 1 到 2 年的工作成果、能力成长、领域边界,在 10 到 20 分钟的时间范围内表现出来。所以,这个过程是肯定不完美的,而且也没法精确量化出识别的准确率。

之所以在有限的时间范围内需要完成这个过程,对公司是一个成本问题。述职人员在有限的时间内展示了几个点,对评审识别人员来说,就像在管中窥豹。看不到全貌,看完几个特征点,然后就需要判断这是豹子(符合下一级别的晋升标准)还是猫(不符合)。

我在做晋升评审时,就一直被这样的判断所困扰,多数述职同事都在这几个点上表现的很好。这就像是说,如果是豹子,它确实该有这些特征,反过来,拥有这些特征一定就是豹子么?这些特征点,是豹子的唯一或足够有区分度的标志性特征吗?

而站在述职答辩人的角度,他的表达和展现更多的不应该是点,而是先有整体(面),再深入局部(点),这应该是一个画龙点睛的过程。

识别的过程,本质是在解一个概率问题。当参与这个过程的两方都这样努力去考虑时,我想这样的过程会有更高的准确率。

路径

成为专家,就是建立领域的过程,那么如何建立更大范围且更具识别性的领域呢?这就是这个路径中的非连续性断层问题。

每个人在成长过程中,从新人到初级到高级,甚至到资深都可以是一个连续阶段,从生到熟的一个过程。熟到了一定程度,就会发现成长进入了高原期。

最近,读到一篇吴军的文章,也提到了工程师成长过程中的类似问题,他用了一个公式来定义:

成就 = 成功率 x 事情的量级 x 做事的速度

连续的成长阶段,我们的成长主要体现在不断提升做事的熟练度(也就是上述公式中的速度和成功率),但这两个指标到了一定的熟练度阶段后就会碰到物理极限。实际情况是,一个资深的工程师的速度甚至不会比一个初级工程师快两倍,但可能成功率会高几倍,甚至十倍,这就是传说中的一个顶十个的程序员,但离极限也就差不远了。

而更是传说中以一敌百的程序员,只有一个可能,他们做的事情和其他人不在一个了量级。现实案例中,就有如 Linus 这样的人。所以,一直做同样的事,都是写代码,也可以跨越断层。但关键是,你写的代码体现在什么量级的事情上。

这里公式中的成就,也可以通过作品域来体现,就像水泥和砖头不是作品,大教堂才是。代码本身不是作品,它只是作品的原料。

作为程序员,我们会有直观的感受,用户量级越过了一定的门槛后,我们编写、维护和部署程序系统的方式都会发生本质的变化。而提升量级、最难得就在于我们要放下曾经熟悉的方式和习惯,要站在更高的维度去看更大量级的事情,并且找到适合这个量级事情的合适解决方案。

看得见断层不见得就跨得过去,但看得见至少多了一种选择,而看不见则很可能一直在原地转圈。


写点文字,画点画儿,记录成长瞬间。 微信公众号「瞬息之间」,既然遇见,不如同行。