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