之前我说过程序员的职场阶梯,而阶梯不过就是很多人已经走过的路,我们只需要沿着这条路去持续成长就能爬上还算不低的楼层。只是到了一定楼层后我们会发现上面似乎还有几层,但却看不见下一层的楼梯了。因为再往上走的人就不多了,也就没能成了路,自然也就看不见,这可能就是所谓成长阶梯的断层。
在程序员的成长阶梯上,到了一定阶段,我们可能会面临方向的选择,不同的方向选择意味着不同的路径,会碰到不同的断层,而跨越断层也需要不同的方法。
那我们会面临怎样的方向选择呢?
方向
在我的技术成长路上,我看到了三个方向,正好可以用三个字来表达:
“高”“高” 指的是 “高级(High-grade)”,“精” 代表 “精确(Precision)”,而 “尖” 则是 “尖端(Advanced)”。这是我所看到的技术人前进的三个主要方向,而这三个方向的走向往往还是互斥的。
“精”
“尖”。
高级,说的不是更高级的技术,因为技术之间的横向比较没有高低级之分,比如操作系统、数据库、网络编程、机器学习等技术,没法比出个高下。这里的“高级”,如其英文是更高等级的意思,是职位和人的级别。而往高等级走的技术人,离 “精” 自然只能越来越远,毕竟站的高就只能看得广,但很难看得精确了。
精确,就是把一门技术做到真正的精通。现在技术的分工越来越细,通常能精通一两个细分领域已实属不易。而要做到精,其实越往后付出越多,但感觉提升却变得越来越慢。都到 95 分了,再往后每提升 1 分都需要付出艰辛的努力。走到细微深处,也很难再看得远、看得广了。
尖端,似乎听起来像 “精” 的极致,其实不然,这完全是另一条路。“高” 与 “精”,是工业界的实践之路,而 “尖” 是理论界的突破之路。只有能推进人类科技进步的技术才称得上尖端,就如 IT 界历史上著名的贝尔实验室里的科学家们做的工作。
“高”“精”“尖”三个字,三个方向,三条路,各有各的机遇与风险。在三条路的岔路口,工作多年的你若止步不做选择,也许就止于一名普通的程序员或资深的技术人。若继续选择一个方向走下去,越往高处走,高处不胜寒,一旦落下,你知道再也回不去了;而走向精深之处,沿着技术的河流,溯根回源,密林幽幽,林声鸟不惊,一旦技术的潮流改了道,你知道你可能会迷失;而尖端之路,或者有朝一日一鸣惊人,青史留名,或者一生碌碌。人工智能的发展史上,曾有一段时间找错了路,让学界止步不前,而这一段时间就是走尖端之路的学者们二十年的岁月。
“高” 是往宏观走,“精” 是往微观走,“尖” 是去突破边界。这三条路,“高” 和 “精” 的方向在业界更常见,而 “尖” 不是工业界常规的路,毕竟业界拥有类似贝尔实验室这样机构的公司太罕见,所以 “尖” 的路线更多在学术界。因而后面我们主要探讨 “高” 和 “精” 两个方向的路径断层与跨越方法。
高
高的两条典型路线如下:
程序员—架构师—技术领导者往高处走,每一次角色的转变,都是断层。有时候,公司里到了一定级别的程序员就会被冠以架构师的称呼,但工作的实质内容依然是资深程序员平时做的事,如:一些关键系统的设计和实现,解决一些困难的技术问题。
程序员—技术主管—管理者
这些工作中的确有一部分也算是架构师的内容,但如果不能认识到架构师工作内容的实质,再往高处走也就很难实现断层的跨越了。而架构工作的实质是创造一个模型,来连接、匹配关于业务、技术和团队之间的关系。
其中的 “业务” 属于架构师工作内容中的领域建模;“技术” 是匹配领域模型的技术实现模型;“团队” 是关于个体之间如何组合的结构,需要满足个体技术能力与技术实现模型的匹配。由这三个元素连接和匹配构成的模型中,“业务” 是变化最频繁的,其次是 “团队”,而变化频次最低的反倒是 “技术”。
每一项元素发生变化,都意味着架构模型需要去适应这种变化,适应不了变化的模型就需要升级。而常见的组织架构调整,也就意味着 “团队” 的沟通路径变化了,因为康威定律(系统设计的通信结构和设计系统的团队组织的沟通结构是一致的)的缘故,必然带来架构模型的适应性变化调整。
透过具体的实质再往高处抽象到本质,你会发现架构工作的本质是在通过模型调优生产关系,从而提高生产效率和生产力。这是一条杠杆之路,通过找到其中的关键支点去放大输出,扩大价值。
【生活感想|跨越断层,突破边界】在架构模型三元素中,技术本身就是一种杠杆,而团队和业务是价值支点。
曾经,技术的草莽时期,是一个英雄辈出的年代。两个人可以创造 Unix、C 语言,一个人也可以发明 Linux,也可以写出 Foxmail。掌握了技术,就可能创造历史,那时技术的杠杆很高。
如今,是技术的成熟时期,个体英雄少了,更多是一种团队和集团军作战的方式。如果你是技术的绝世高手(精的极致),那你也需要找到一支契合你技能的场景与队伍,加入进去。此时个人的技术杠杆也许不像曾经那么高,但也许你们这个队伍还是有机会能创造历史的。
前几年,Facebook 曾收购了一家叫 WhatsApp 的公司,花了 190 亿美元。这家公司当时仅 50 人,而其中一半是技术人员,这应该是近年用技术杠杆撬动价值之最了吧。
在 WhatsApp 这个例子中的价值支点是什么?是产品(业务),连接用户、形成网络。技术本身的价值通过这个产品业务形态支点,在每个活跃用户身上得到了放大。
而另一个价值支点,是借助团队,但这只适合高级别的技术人员,比如:技术管理者或架构师。但团队也需要能创造真正的价值,才能实现利用杠杆放大价值的效果。在商业环境下,任何一种产品业务形态,其最终能实现价值,都会存在一个价值网络。这个网络中覆盖了各种角色,技术只是其一,若要找到最好的价值支点,那么通常会在离价值来源比较近的地方。
技术像是一根棍子,能发挥多大价值,取决于棍子本身的品质和运用的方式。而往高处走的技术人,要跨越这条路径的断层,就是要认识清楚这个价值网络,并找到最适合技术发挥的价值点。
精
精的路线是一条 “专家” 之路。
曾经定义过 “专家”,我说:专家可能就是某个领域中你绕不过去的人吧。这个定义中包含两个点,一个是领域,另一个是绕不过去。第一点表达了某个范围,第二个则模糊地表达了这个范围的大小,绕不过去其实是一个很大的范围了。
比如,若你处在物理学领域,牛顿就是你绕不过去的人,之后是爱因斯坦。而在计算机领域,图灵定义了计算机的边界,也是这个领域绕不过去的人。但这样的天才人物,百年来才出一个,如果都要达到这个水平才算是专家,可能就太难了,从而失去了指导意义。
如今反思,其实用这两点来定义专家也是可以的,只是需要更清晰地明确领域和量化范围。大至国家、社会、行业,小到公司、团队、小组,都有自己关于专家的定义。
曾经,好些年前,我最早在公司的几个同事组成的小组内研究引入 Java NIO 的技术来编写网络程序,读了一些相关的书和开源框架代码(Mina、Netty),周围的几个同事就戏称我为 Java NIO 的专家。这就是用领域(Java NIO 是一个很细分的技术领域)加范围(局限于周围组内几个同事,他们要解决 NIO 的网络编程问题都绕不过我)定义专家的方式。
因而,像前面说的爱因斯坦、牛顿、图灵,他们既是行业(学科维度)范围内的,也是世界(地理维度)范围内的专家。而公司内的专家职级定义,其范围无非就是与公司经营相关的某个领域,其大小无非就是公司组织架构的某一层级之内。
走向专家之路,就是精确地找到、建立你的领域,并不断推高壁垒和扩大边界的过程。
那么如何建立属于自己的、更大范围内且具备足够识别性的领域?这就是 “精” 的路径中的非连续性断层问题。曾经读过一篇吴军的文章,谈到了工程师成长中的类似问题,他用了一个公式来描述解法:
成就 = 成功率 x 事情的量级 x 做事的速度在连续的成长阶段,我们的成长主要体现在不断提升做事的熟练度,也就是上述公式中的速度和成功率,但这两个指标到了一定的熟练度阶段后就会碰到物理极限。实际情况是,一个资深的工程师的速度甚至不会比一个初级工程师快两倍,但可能成功率会高几倍,甚至十倍,这就是传说中的一个顶十个的程序员,但离极限也就差不远了。
而要成为传说中以一敌百的程序员,只有一个可能,他们做的事情和其他人不在一个量级上。现实案例中,就有如 Linus 这样的人。所以,一直做同样的事,都是写代码,也可以跨越断层,但关键是,你写的代码体现在什么量级的事情上。
问题的量级变了,逻辑就不一样了。作为程序员,我们会有直观的感受,用户量级越过了一定的门槛后,我们编写、维护和部署程序系统的方式都会发生本质的变化。而提升量级最难的就在于我们要放下曾经熟悉的方式和习惯,站在更高的维度去看更大量级的事情,并且找到适合这个量级事情的合适解决方案。
面临成长路上的非连续断层,以及角色之间的无形壁障,该如何跨越断层,突破边界?我们着重从成长路线的两个方向:“高” 和 “精”, 提供了分析和解法。
高的路线,需要借助技术的杠杆,认清所处的价值网络,找到合适的价值点,撬动更大的价值;明晰了不同路线的价值方向,但每个人脚下的路都是具体的、不同的,我们跨越的方式也不会一样。在成长的路上,你碰到了断层没,又是如何跨越断层的?
精的路线,在做事情的成功率和速度接近自己的极限后,只能去提升事情的量级,才能发挥出专家的价值。
推荐阅读
- java|MySQL数据库无法备份解决——mysqlidump
- 阿里云教程|企业如何选择阿里云服务器? 阿里云服务器配置购买帮助文档
- Python|在Anaconda中用pip安装Pytorch后无法用pycharm打开
- 兔老大的系统设计|兔老大的系统设计(一)健康度系统
- javascript|js操作数组的方法
- Java基础|高并发线程/锁/内存处理模型
- 物联网|数字孪生 - 认知篇
- Java基础|Servlet+Filter+Listenler基础入门
- 数据库|MongoDB+集成SpringBoot+索引+并发优化 - 基于《MongoDB进阶与实战(唐卓章》)