This commit is contained in:
louzefeng
2024-07-11 05:50:32 +00:00
parent bf99793fd0
commit d3828a7aee
6071 changed files with 0 additions and 0 deletions

View File

@@ -0,0 +1,89 @@
<audio id="audio" title="54 | 侠客行:一技压身,天下行走" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d8/15/d859f61b2bbda1ede0f1e4e7b1db8215.mp3"></audio>
从今天开始,我们进入了专栏的第 5 部分 —— **寻路:路在何方**?这是一条关于方向、角色和自我定位的探索,那就让我们开始一起走走这条程序江湖路吧。
大约三年前吧,读到一篇文章《为何我工作十年,内心仍无比恐慌》,来自一位腾讯产品总监的演讲分享。文中分析了一个让其感到恐慌与焦虑的深层次原因:好像不会什么技能,技能门槛低。
这种恐慌和焦虑感在这个行业中普遍存在,不止于产品经理,程序员也一样。一些传统行业的生命已经远超过一个人的寿命,而 IT 互联网行业还不满三十岁,也许正是因为其还很年轻,生命力旺盛,远超传统行业的发展速度和新陈代谢规律,让其中的从业者深感疲惫,同时对未来又充满了不确定性,而未来的不确定性通常正是让我们感到焦虑的一个主要原因。
## 门槛
技能的门槛高低,决定了让我们产生恐慌和焦虑的水位线。
在前面提到的《恐慌》一文中说,产品的从业门槛足够低,作者十年的从业经历中见过从事产品的人来自各种专业,还有各种改行做产品的。而从业门槛主要来自于技能门槛,特别是硬技能,硬技能属于行业的专有技能,需要足够的时间积累,通常这个积累时间就是你可能熟悉的理论值:一万小时。
产品看起来是一个缺乏硬技能门槛的职业,因而感觉门槛低。而程序员职业其实是有一定硬技能门槛的,但这种门槛随着技术和工具的进步正在变得越来越低。如今 IT 互联网行业当然是繁荣的,繁荣的行业带来利差,自会吸引大量其他行业的从业者进入,而这些进入者自然会选择门槛低的职业工种来跨越边界。
在其他行业干了些年头的人,有些可以在这个 “互联网+” 的时代通过垂直行业专家来进入互联网行业,但要进入程序员这个职业就得赶早了,毕竟硬技能需要的积累时间是很难省却得了的。大部分人都是在大学期间或刚毕业不久就完成了转行到程序员职业的切换,如我的一个高中同学,她本是文科专业中文系的,大二就毅然开始辅修计算机的第二学位了。
还有个行业一直繁荣,需求永续存在而且供不应求,但却从没见过任何其他行业的人进入。我说的就是“医生”这个职业,它的硬技能门槛之高不免让人联想起《冰与火之歌》里的绝境长城,让人完全兴不起翻越的欲望。我听说过小说写得好的前妇产科医生,却没听说过手术做得好的前小说家。
医学院的学生本科都要比其他专业多读一年,但本科毕业可能都找不到什么好工作,至少要读到硕士,想有点发展还得读博,十年一晃而过。而本科毕业的程序员,一进入 IT 互联网行业可能拿的工资比医学博士生刚进入医院还高,这就是行业繁荣的好处。但坏处是,这个行业变化太快,有时你没什么错,只是因为老了。很多互联网公司喜欢年轻人,标榜年轻,员工平均年龄二十多,所以才能最懂年轻人。
而医生呢?这么说吧,你是喜欢年轻有激情的医生,还是经验老道的中年 “老” 医生?
程序员看似是很有技术含量的硬技能门槛,实际远不如医生这个千年来的 “古老” 职业,行业的最低技能门槛要求挡不住很多人热情地涌入,而技能成长的天花板也感觉并不高,如何能不恐慌与焦虑?
## 模型
有时可能我们会有一个职业理想,叫 “一技压身,天下行走”,就像一名侠客一样,学好了功夫,从此闯荡江湖,好不逍遥自在。
之前看过一本武侠玄幻小说,里面有一些角色就叫 “天下行走”,他们都有自己厉害的独门绝技,不厉害怎能天下行走。其中,剑客的剑快,野人的身体坚硬如铁,和尚从不说话修的闭口蝉,一开口就人人色变,这些就是他们独特的技能模型。
**技能模型才是区分不同专业人才特点和价值的核心关键点**
而技能模型的形成是一系列选择的结果。以前玩过一个游戏叫《暗黑破坏神》,正常不作弊地玩,一个角色是很难点亮所有技能的,游戏是故意这样设计的。所以你可以反复玩来尝试点亮不同的技能组合方式,这样游戏才具备反复的可玩性。而与游戏不同的是,人生只有一次,你无法点亮所有技能,只有唯一的一种点亮路径选择塑造独一无二的你。
而这种选择,可能一开始是无意的,比如我成为一名 Java 程序员是偶然的,而你成为一名 C++ 程序员也可能是偶然的,早期的技能点亮策略有很多的偶然性。但到了后期,我们逐渐成长,有了更多的经验和选择权,这时就需要主动选择去建立自己的技能模型。
记得有一篇关于工程师思维的文章是这么说的:
>
工程师思维的大道,就是先创造一个好模型,然后想办法实现这个模型,工程师关心的是能不能用这个模型创造出东西来。
而技能模型其实正是工程师创造的第一个元模型,这个模型决定了后续作为工程师的你还能基于此创造怎样的模型,从而完成产品的实现。
当只拥有一些零散的技能点,而且这些技能点还会随着时间流逝而过时,我们当然会感到恐慌与焦虑;但如果能够将这些技能点组合成我们独有的技能模型,提供独特的价值,从此独步江湖,甚至开宗立派,想必也就没那么恐慌与焦虑了。
以前文章写过关于 “知识体系”的内容,那它和技能模型有什么区别?知识体系本质也是一种知识模型,但技能模型更深一个层次,因为技能是对知识的应用。知识模型构筑了理论边界,技能模型是实践的路径。
## 路径
那么,关于技能模型这条实践路径该如何去选择和构建呢?
程序员作为工程师的一种,必须得有一项核心硬技能,这是需要长时间积累和磨练的技能,要花大力气的,而这个大力气和长时间,也正是这门技能的门槛。关于技能的习得有一个流行的看法是:花 20% 的时间快速获得某个领域 80% 的知识和技能。这看起来像是一种学习的捷径,但一个硬技能领域最核心的竞争力往往都是最后那 20% —— 也就是你用那 80% 的功夫反复磨练出来的最后 20% 的技艺。
古龙小说中有个角色叫荆无命,他腰带右边插着一柄剑,剑柄向左,是个左撇子,江湖中都知道他左手剑快,但其实他右手剑更快。荆无命要是个程序员的话,那可能就同时具备了两个核心硬技能,属于那种 Java 很强,但 C++ 更牛的人。但我从业这些年还没碰到过同时点亮两者的,无论 Java 还是 C++,因为各自都有足够大的生态和体系,已经需要很长的时间来积累和打磨了。
**我们大部分普通人,拥有的是有限的时间与才华,面对的是无限的兴趣和技能,同时修炼多个核心硬技能是不明智,甚至是不可行的**。记得以前读万维钢有篇文章介绍了一本书叫《达芬奇诅咒》,文艺复兴时期的达芬奇是一位多才多艺的人,但一个人如果像达芬奇一样对什么东西都感兴趣,但又没有和达芬奇匹敌的才华,很可能尝试了很多,最终却一事无成,这就中了 “达芬奇诅咒”。
所以,构建核心技能模型其实是关于才华和技能的战略。《达芬奇诅咒》一书作者就选择技能领域推荐了三个标准:
1. 你确实喜欢
1. 你在这个领域有天赋
1. 这个领域能挣到钱
我仔细回味了下这三个标准,真是很接地气,实在可行。你喜欢的领域,至少在启动进入时也容易一些,长时间的坚持时也更有毅力一些;而你有天赋的领域,信心也足一些,并且拥有相对竞争优势;能挣到钱的领域,最好还比别得领域更挣钱,那么外在的经济激励会更强,而同等努力相对收益也更大。无怪乎,一个技术热潮起来后,大家都看到了第三点,急匆匆跳进去,但往往忽视了前两点。
另一方面,多个核心硬技能之间是一种加和关系,若非迫不得已,再下同样的大功夫去修炼另一项核心硬技能显得就不是那么明智了。所以应先深度修炼“一门”核心硬技能,建立门槛,但需要深到何种程度才能天下行走?如果刚开始起步算 0 1 算是行业平均水准,那至少先要专注在核心硬技能上,并修行到 1 以上,能进入前 20% 就更好了。
然后,就可以围绕核心硬技能适度练习和发展一些辅助技能,这些辅助技能大多属于软技能,也有部分硬技能,只是没有核心技能那么硬,通常起到放大和加强核心技能的作用,可以发挥指数效应。这也是为什么核心硬技能要先修行到 1 以上,因为指数关系只有在大于 1 时才有意义。
有些辅助软技能可以通过刻意练习来掌握,而有些则很难,属于埋藏在天生的基因和后天的成长性格中。在漫画《火影》的忍术体系中对这种天生的技能有个术语叫 “血继限界”,其中最厉害的当属 “写轮眼”。想想在职业发展的技能体系中,有什么是可媲美 “写轮眼” 的辅助软技能的?如果你幸运拥有这种 “血继限界”,可别浪费了天赋。
程序员怕什么?就怕技术潮流的颠覆直接废了全身武功。我读大学时就经历过一次,当时主流的企业应用开发是 C/S 架构的 Delphi 和 VB如今已是明日黄花。而武功体系由内力加招式组成技术的演进容易废了招式却不容易废了内力。
张无忌学会九阳神功,一身内力惊人,招式现学现卖也打的少林龙爪手高僧叫屈,所以在点亮技能模型树的过程中,你得分清九阳神功和龙爪手的区别。类比于技能模型树,内力是根茎,招式如花叶,时间流逝,落花残叶,冬去春来,复又发新。
到这里,关于技能的焦虑和建立技能模型的方法,我们就探讨完了,最后总结提炼下:
- **程序员这行的技术门槛没想的那么高,所以就此易引发恐慌和焦虑**
- **建立你自己的技能模型,才能提升门槛和核心竞争力**
- **避开 “达芬奇诅咒”,围绕核心硬技能,发展“一主多辅”的技能模型树**。
从此,种下技能模型之树,让其茁壮生长,方能一技压身,天下行走。
在程序这个江湖上,你又是靠什么在行走天下呢?欢迎你留言分享。

View File

@@ -0,0 +1,79 @@
<audio id="audio" title="55 | 江湖路:刀剑相接,战场升级" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5b/8d/5bbb65d4e61b4406c1f91d9091b7bc8d.mp3"></audio>
回首自己的成长之路,通常每五年就会感觉碰到一个成长的瓶颈点。在传统 IT 行业的第一个五年后,我就感觉明显进入技术成长的瓶颈期;之后也算有点运气,通过转换到互联网行业升级到了新的技术维度。
又过了五年,站在十年后的一端,回望过去,刀剑相接,如梦似幻,我渐渐感知到突破这次瓶颈的道路,就意味着走向一个升级后的新战场。
## 刀剑相接:杀人术
天下风云出我辈,一入江湖岁月催。
你狠狠地敲下键盘的回车键,终于看见程序按预期输出了正确结果。长长吐了一口气,点上一支烟,环顾四周,独自一人,又是一个夜深人静的晚上。在一种搞定 Bug 的满足与空旷寂寥的忧伤中,你不禁迷惘。
记不清这是你修复的第多少个 Bug 了,甚至记不清这是你参与开发和维护的第几个系统了。就像一个剑客在这个江湖上行走多年,已记不清死在自己剑下的人有多少,拔剑,收剑,有人倒下,你继续行走,如今 “杀人术” 已成。
对一个程序员而言何谓 “杀人术”?你选择了一门语言开始学习编程,就像一个刚入江湖的人选了学剑或刀。再弄几本江湖宝典,假想了一个项目开始练习,熟悉基本的使用套路。然后走入江湖,拜入门派,腥风血雨,数年后剑鸣空灵,刀啸云天,飞刀无影,“杀人术” 终成。
这就是一个程序员的成长之路,你选了门武器,学了基本招式,然后进入江湖不停地在厮杀中成长。终于你能搞定各种各样的系统问题,了解不同系统的设计模式。每过数月或一年半载,你总会发现过去的代码写得不好,再重构上一遍,改进你的招式,数年后,终成江湖高手。
一个程序员修成 “杀人术” 大概需要多久?按照一万小时理论,如果你在某一领域每天持续学习和实践练习十小时,最快也要三年。但这三年是没算各种可能的中断的,比如:生病、偷懒、假期休闲娱乐等等,所以大部分人的平均时间可能需要五年。
五年成术已算理想,实际上我自身用了更长的时间,走了更多弯路。从 Basic 程序入门,后来 VB 再到 Delphi ,然后 C 最后 JavaJava 也经历了几代变迁,但还算一脉相承。技术的发展,时代的变迁会让 “杀人术” 也在不停地演化。而今剑术已成,然拔剑四顾,却发现已进入枪炮时代,不免心下茫然。
经历了一万小时的杀人术训练与实战后,技能增长曲线已经进入了对数增长的平缓期,过于单一的技术维度成为了我们的瓶颈和焦虑的源头,该如何去突破这样的瓶颈点?
## 认知升维:化形
爱因斯坦说过:“我们不能用制造问题时同一水平的思维来解决问题。”
技能维度的瓶颈问题,经常会让作为程序员的我们陷入一种常见的平面思维方式。比如,一个程序员做了十多年桌面客户端开发,后来移动崛起,桌面式微,就颇感焦虑,这就是他所面临的技能维度的瓶颈。而他想尝试突破的方法,可能却是转到服务器的后端开发,因为感觉这个领域还一直比较长青。
然而这只是从一个领域的核心硬技能转换到了另一个领域,但这两个领域基本是独立的,关联性很弱,而且交叉的区域也很薄,也就意味着很多经验和能力要重新积累。这就是从问题本身的维度去寻找到的解决方案,而爱因斯坦说了,我们需要到更高的维度去寻找答案。而更高的维度就是认知的维度,所以首先需要的是**升维我们的认知结构**。
在我修行成术的过程中出现了好多新技术,当时我总想忙完这阵就抽空去学习了解下。但一过几年也一直没能抽出空去看,如今再去看时发现好些当年的新技术已不需再看了。五年成术是立足于一点,成立身之本;而下一阶段不该是寻找更多的点,而是**由点及线、由线成网、由网化形**。围绕一个点去划线,由一组线结成网,最后由网化成形,**“化形” 表达了一种更高级的知识和技能运用形态,比一堆离散的知识技能点有价值得多**。
而对于认知升维,由点及线、由线成网、由网化形,其实走的是一种 “升维学习” 之道。这个过程几乎没有终点,是一个持续学习、不断完善的过程,最终结多大的网,成什么样的形,全看个人修为。一条线至少要两个点才能画出,那么第二个点的选择就要看能不能和第一个点连起来了,而这比在一个维度上去预测和乱踩点要有效得多。
其实这套道理在金庸设计的武学体系中也很是明显。这里就以大家最熟悉的《射雕》三部曲为例来看下。郭靖一开始师从江南七怪,后来又跟全真七子中的几位学过功夫。这在功夫里就是两个点,但没看出这两个点有何联系,最后郭靖江湖成名,终成一代高手靠的是什么?降龙十八掌。为什么有十八掌这么多,从小说里的描述表达了一个体系的意思,一个体系结网成形,最后的形态命名为降龙十八掌。
其实郭靖还学了另一个更有体系、形态更牛的武功秘籍——《九阴真经》。除了郭靖,《九阴真经》还有很多人看过、学过,有高手如:黄药师、王重阳等,也有一般人如:梅超风。高手们本身有自己的武功体系和形态,所以看了《九阴真经》也仅仅是从中领悟,融入自己的体系中甚至因此创造出新的武功形态。而梅超风之流则仅仅是学点其中的招式,如:九阴白骨爪,和之前自身所学其实没有太多关联,武功境界终究有限。
所以,**升维化形,化的正是技能模型,而这套模型基本决定了你的功力高低**。
再回到前面那位桌面端程序员的瓶颈问题,升一点维度看更泛的终端,桌面端不过是这棵技能模型树上的一个分枝。树并没有死,甚至更壮大了,只是自己这棵枝干瘪了些,所以可以去嫁接其他分枝获取营养,而非想要跳到另一棵树上去,重新发芽开枝。
## 战场升级:十面埋伏
结网化形,走上升维之道,因而战场也变大了,但你的时间并没有增多,这就存在一个理论学习和战场实战的矛盾。
到底是应该更宽泛地看书学习建立理论边界,还是在实战中领悟提升?关于这点,你需要选择建立适当的平衡,走两边的极端都不合适。在学校的学习更多是在建立理论体系,而在工作前五年的成术过程则更多是偏实战。
**再之后的阶段又可能需要回归偏理论,提升抽象高度,从具体的问题中跳出来,尝试去解决更高层次、更长远也更本质的问题。而从更现实的角度来看,你的环境也会制约你能参与实战的经历,导致有些东西靠实战可能永远接触不到,不去抽象地思考是无法获得和领悟的。**
历史上关于理论和实战有很多争论,还留下了一些著名的成语。理论派的负面历史代表人物有:赵括。还有一个关于他的成语:纸上谈兵。他谈起军事理论来一套一套的,一上战场真打起来就葬送了数十万将士的性命,所以大家都会以赵括为例来批评没有实战经验支撑的理论靠不住。
但其实还有另一个更著名的历史人物,也是理论派出身,在真正拜将之前也没什么实战经验。并且也有关于他的成语,如:背水一战,这是他抽象地思考过很久的战法,但也是第一次上战场使用,一战而青史留名。
他就是韩信,历史上说他率军出陈仓、定三秦、擒魏、破代、灭赵、降燕、伐齐,直至垓下全歼楚军,无一败绩,天下莫敢与之相争。王侯将相韩信一人全任,一时国士无双,属于中国古代从理论到实战的谋战派代表人物。
韩信的对手项羽在历史上就是一个实战派代表人物,个人的 “杀人术” 相比韩信高出怕不止一个等级。但其实他和韩信根本不在一个维度上,韩信在最后面对项羽前,已通过众多大大小小的战斗去不断实证和完善了他的谋战理论。垓下之战项羽中十面埋伏,致其乌江自刎,更像是一场高维打低维的降维攻击。
所以,关于理论和实战的关系,从这个历史故事可以有所体会。而 **“十面埋伏” 这样的技能维度显然比 “霸王举鼎” 要高出不少,而升维后的技能,也需要升级后的战场才发挥得出来**。
技能的成长速度总会进入平缓阶段,并慢慢陷入瓶颈点,然后也许你就会感到焦虑;而焦虑只是一种预警,此时你还未真正陷入困境,但若忽视这样的预警,不能及时进行**认知和技能升维**,将有可能陷入越来越勤奋,却越来越焦虑的状态,结果走入 “**三穷之地**”(包括如下三种“穷”):
1. 结果穷:技能增长的边际收益递减;
1. 方法穷:黔驴技穷,维度过于单一;
1. 时间穷:年龄增长后你能用来成长的时间会变少,分心的事务更多,而且专注力会下降。
认知和技能升维带来新的成长收益,同时防止了单一维度的死胡同,而年长的优势正在于经验带来的理解力和思考力的提升。
最后,总结下今天的分享内容,在程序江湖上,从刀剑相接到战场升级走的是这样一条升维路:
- **刀剑相接的战场,我们靠 “杀人术” 也即硬技能求生存,但时间久了就会有瓶颈**
- **技能升维,需要认知结构先升维,“我们不能用制造问题时同一水平的思维来解决问题”**
- **升维后的技能,也需要一个升级后的新战场,走上理论结合实践的 “谋战” 之路**。
在我的寻路过程中,我找到的就是这样一条技能升维之道,那你呢?

View File

@@ -0,0 +1,71 @@
<audio id="audio" title="56 | 御剑流:一击必杀,万剑归心" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/19/c0/19daeb4a4b5127f74850718efbeba9c0.mp3"></audio>
在前文《江湖路》中我找到的路是一条 “**战场升级,技能升维**” 之路,技能与战场的升维演化是一个相辅相成的过程。进入了升级后的战场,也需要升维后的技能模型,那我们该如何从旧有的技能模型进行升维演化呢?
我想还是用一些形象点的武功招式来类比说明。
## 拔刀斩
拔,提手旁,喻义需要亲自拔刀动手。
而拔刀术源自日本古武道,其核心思想便是一击必杀,利用瞬间高速的拔刀攻击对敌人造成出其不意的打击。其讲究的是快,也即速度和锋利度。
武士不断修行拔刀术,力求一击杀敌,而程序员学习和练习编程的过程也是类似的。最终,你的编程技能到达了一个什么样的程度,就是看它的锋利度,即面临一个个程序问题能否一刀见血,一击必杀。
刚入门的程序员上线发布碰到了一个问题,抓耳挠腮,冥思苦想,加班加点终不得解。于是跑来向你这个高级程序员请教,此时时钟指向了凌晨一点。你放下手中刚泡好正准备吃的方便面,一支燃烧着的半截烟头挂在你的指尖。你犹豫了一下:是猛抽两口还是灭掉烟头去处理这个紧急问题?
最终,你终究不舍地把半截烟头小心地放在方便面盒边沿,再用塑料的方便面叉把面盖和烟头一起固定住。然后,你挽起了袖子走到这个年轻程序员的电脑前,迅速扫了几眼报错的错误日志,再调出你心爱的 vi 编辑器,噼里啪啦地改动了几行代码,保存,关闭,再重新构建,发布。电脑黑底白字的界面不停地滚动着,你已站起身向散发着两种味道的方便面走去,并回头轻轻对年轻程序员说了声:可以了。
这就是你向年轻程序员展示你的拔刀术,问题一斩而绝。好吧,这是一种诡异的优雅,似乎任何问题对于电影里的程序员而言,在电脑前噼里啪啦敲上几行代码都能解决。但现实中大部分时候都比看上去要更困难一些,真实世界的拔刀术和动漫《浪客剑心》里剑心的 “天翔龙闪” 相比,终归显得笨拙了许多。
而拔刀术正是我们第一阶段的技能模型,在我们追求 “天翔龙闪” 的境界时,看上去并不遥远,但越走到后面,却越来越慢了,似乎永远也到不了,这就是已经进入了第一阶技能的瓶颈区间了。
在瓶颈区中,进境缓慢近乎停滞,就可以尝试下技能升维 —— 从 “拔刀” 到 “御剑” —— 看能否在新的战场找到突破点。
## 御剑术
御,双人旁,喻义贴身教授与把控。
御剑术,这个招数的类比来自好多年前(我那会还读初中吧)玩过的一个电脑游戏——《仙剑奇侠传》,我记得这也是游戏里主角在第二阶段学会的技能。如果过去面临问题你需要拔刀解决,那这里的 “刀” 就是你的知识、技能和经验。那御剑术里的 “剑” 又是什么?
记得以前读过一篇关于高级程序员的文章,其中提出了一个组合三角的观点,先看下面这张图:
<img src="https://static001.geekbang.org/resource/image/56/0f/560e4be757a98a300bf7e980e8566a0f.png" alt="">
图中蓝色三角区域表明,随着你从入门初级成长到高级程序员的过程中,需要得到的帮助和指导越来越少;而红色三角区域表明,你能提供的帮助和指导应该越来越多。所在,在前面那个想象的 “泡面拔刀” 的场景中,作为高级程序员的你,更理想的做法应该是去指导年轻程序员如何解决问题的思路,而不是自己拔刀,唰唰两下搞定。
对,很多高级程序员都会以 “等把他教会,我自己早都搞定了” 为由,忍不住自己拔刀。**理解、掌握并应用好一种知识和技巧是你的 “拔刀术”,但分享传递并教授指导这种知识和技巧才是 “御剑术”**,而 “剑” 就是你面前更年轻、更初级的程序员。
曾经多少次面对年轻初级程序员交付的结果,我都有一种懊恼的心情,怀疑当初是不是该自己拔刀?那时就突然理解了驾校老司机为何总是满腔怒火地吼着:“让你松点离合,只松一点儿就好…”,而当初的我刚学开车时,一开始不是松少了,就是熄火了。
从 “拔刀术” 到 “御剑术”,其技能模型的招式和对象变化了,但本质框架却是类同的,这里的关键点是:如何剥离自我,通过他人来完成设计和实现,并达成解决问题的目标。
## 万剑诀
诀,言字旁,喻义以言引导,影响多于控制。
所有的程序员都是从修行 “拔刀术” 开始,但只有极少数人最终走到了剑心 “天翔龙闪” 的境界,所有未能突破的我们都进入了瓶颈停滞区。我们不断学习和练习,终于练到拔刀由心,收发自如,终成习惯,但要将这个技能升维,跨越战场,却正是需要打破这个习惯。
其中,**从 “拔刀术” 到 “御剑术” 是习惯的打破;从 “御剑术” 到 “万剑诀” 则是量级的变化**。因而,“御剑术” 是修行 “万剑诀” 的必经之路。嗯,游戏里也是这么设定的。
“万剑诀” 正如其名,御万剑而破敌。回到现实中,这是一项高杠杆率的技能。而高杠杆率的活动包括:
- 一个人可以同时影响很多人。
- 一个人可以对别人产生长远的影响。
- 一个人所提供的知识和技能,会对一群人的工作造成影响。
这就是 “万剑诀” 的核心要诀。应用到程序员修行之路上:如果走上同时影响多人的路线,这就是一条团队管理和领导者之路;如果走上影响长远的路线,你可能乐于分享、传授,这可能是一条布道师的路线;如果你通过提供知识和技能来影响其他一群人的工作,那么这可能是一条架构师的路线。
“万剑诀” 和 “御剑术” 的共通之处在于都以人为剑,观察、揣摩每把剑的特性,先养剑再御剑最后以诀引之。**若 “拔刀术” 是自己实现的能力,那 “御剑术” 和 “万剑诀” 都是借助他人使之实现的自信和能力**,只是后者相比而言规模更大,杠杆率更高。“万剑诀” 的重心在追求问题解决的覆盖面,而面临每个具体问题时就需要依赖每把剑的锋利度了。
另外,“御”之一字更着重了一层控制的含义,而 “诀” 之一字在于影响多于操控,这里面的关键点就是:剑本身的成熟度。不够成熟的剑只能 “御” 之,足够成熟的剑方能 “诀” 之。
走上 “万剑诀” 之路后,还能再领悟 “天翔龙闪” 的奥义么?也许这是时代演进让我们不得不做出的选择,今天的程序江湖掌握了 “天翔龙闪” 奥义的 “神” 级程序员已经越来越成为一个传说,数十年前,那个英雄辈出的年代已不复再现。
拔刀术,是亲自动手斩杀问题,难处在于维度单一,后期进境陷入瓶颈停滞;御剑术,是指导他人解决问题,难处在于打破习惯,剥离自我;万剑诀,是借助他人使之实现,难处在于剑的养成。
它们的共通之处,都是基于长期的编程和工程训练,建立的系统化思维能力,创造模型来解决问题,而变化在于模型的适用对象不同,导致需要不停地调试合适的 “模型参数” 来适配问题,并且不论是技术框架还是人的 “模型参数” 都是在变化之中的。
最后,在你的技术升维演进转型路线上,你对这类变化的感受和认知是怎样的?欢迎留言分享。

View File

@@ -0,0 +1,138 @@
<audio id="audio" title="57 | 三维度:专业、展现与连接" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d4/81/d45b00c573ff08b94ba72a4df0068081.mp3"></audio>
曾经在和朋友探讨个人发展的问题时,讨论出一个 **PPC 理论**,该理论粗略地把涉及个人发展的方向分成了三个维度,包括:
- 专业 Profession
- 展现 Presentation
- 连接 Connection
而像程序员这样的专业技术人员,都倾向于在专业维度不断发展提升,却往往忽略了另外两个维度。如果三个维度综合发展的话,可能会得到 `1 + 1 + 1 &gt;&gt; 3` 的效果,即三个维度相加远远大于 3 的效果。
## 一、专业 Profession
什么才算是 “专业”?其实没有一个标准定义,我尝试将其进一步分解为三个子维度。
### 专业能力
专业能力,包含了知识和技能。以程序员为例,具备专业能力的软件工程师应该拥有系统的知识体系和相应技能。
那么程序员的系统知识体系和技能又包括哪些?曾经在知乎看到过一个抽象的类比,它用我们在学校学习的各种学科体系来类比程序员的专业知识体系和技能,我结合自己的理解也做了一些延伸,包括下面这些方面:
- 数学:这个不算类比,因为数学就是计算机科学的基础;
- 物理程序世界中的基本定律如CAP、NP、算法与数据结构
- 化学:程序世界中的 “元素” 和属性,如编程语言平台、各类框架和系统特性。
在程序世界里,学好 “数理化” 基本也算走遍天下都不怕了,到哪都能找个工作,但这还不够。“数理化” 属于硬知识与技能,实际工作中还需要软知识与技能。而软知识与技能又包括如下内容:
- 语文:除了能写代码,还得能写好文档,起得好名字,表达好逻辑,让代码更可读、可懂;
- 英语:高级编程语言几乎都是英语的子集,第一手的技术材料多来自英语世界;
- 生物:不同的技术都发展出了不同的生态体系,今天的系统几乎都在某种生态之中;
- 历史:任何一门新技术,都有其历史渊源,它从哪里来,将会到哪里去;
- 艺术:编程是一门艺术,一种逻辑与审美的表达;
- 经济:成本、收益、效率,有关技术决策的核心;
- 建筑:有关架构的一切,钢筋、水泥、脚手架、灾备、抗压、防单点以及相关的权衡。
当把这些学科的知识和技能都掌握得七七八八了,那么才算具备了专业能力。
### 专业行为
专业行为,包括规范化的工作流程和作风,严格的职业纪律与操守。
这些专业的行为最终会内化成一个人的习惯敏捷专家肯特·贝克Kent Beck说过一句话“我不是个优秀的程序员我只是一个有着优秀习惯的普通程序员。” 所谓 “优秀习惯”,就是专业行为的一个重要体现。
专业能力加上专业行为,会让你从周围的合作者那里得到一个做事很专业的评价。
### 专业产出
专业产出,指最终产出的结果是稳定的,可预测的,处在一定品质标准差范围内的。
这一点可以用小说家类比。比如,金庸写了 15 本武侠小说,从第一本到最后一本的产出质量都在一定的水平之上,他的最低标准也高于绝大多数人,品质标准稳定可靠。而同时代的古龙,就不是这样的,早期古龙的小说良莠不齐,品质标准的波动范围很大;其中的分水岭是《绝代双骄》,之后的小说才开始逐渐稳定在一个很高的品质标准之上了。
所以,一个专业的程序员,交付的程序应该像金庸和后期的古龙那样,在一个可预测且稳定的品质标准之上波动。
所有技能维度的成长都是一条对数增长曲线,迟早会进入上升的平缓区,在这个区间 “投入增长比” 不高,这时就可以适当发展下后面两个维度,将会是不错的选择。
## 二、展现 Presentation
展现建立于专业的基础之上,所以展现也对应着专业的三个子维度。
- 展现专业能力:包括代码、架构、认知、决策;
- 展现专业行为:包括沟通、交流、表达、协作;
- 展现专业产出:包括作品、方案、洞察、演示。
对应这些展现的需求,有不同的展现形式,无外乎下面这些。
- 代码Github 等开源站提供了最直接的围绕专业能力中编程能力的所有展现形式、证据和历史;
- 交流:在日常的即时通讯、邮件、会议、交谈与协作中,展现了关于专业行为的一切;
- 演讲:有关专业产出的重要形式,如汇报(业绩产出)、分享(作品与影响力产出);
- 写作:文字作品,一种长尾影响力的产出形式。
在大部分情况下,你的专业价值评估都是由你的展现水平来决定的。
## 三、连接 Connection
我把社交连接分成了 **5** 个圈层,一般每个人都会具备前两个圈层,而只有在展现的基础之上,才有扩大连接到后面三个圈层的可能性。
### 10
人生的每一个阶段,都会有一些最要好的朋友,也就是好朋友,这是我们社交关系中最强的连接了。
一般这个数字都低于 10而我自己的经历是每一个阶段其实都没有超过 5 个。从小学、中学、大学、工作,包括从一个城市到另一个城市的不同阶段,各个阶段都有一些关系很好的朋友,但每经历过了一个阶段,这些好朋友就会发生变化。
很少有人,小学时候的好朋友,到了如今还是好朋友的,人生的变化实在太难预测。而这种好朋友的亲密关系,在每个阶段对你都是最有意义和价值的,会让你感到生活的快乐与幸福。
因而50% 以上的社交时间都值得花在每个阶段最好的这 5 个朋友身上。
### 100
有一个神奇的数字叫 “邓巴数”,它来自神经科学领域,研究认为:
>
人的大脑新皮层大小有限,提供的认知能力只能使一个人维持与大约 150 人的稳定人际关系,这一数字是人们拥有的,与自己有私人关系的朋友数量。也就是说,人们可能拥有 150 名好友,甚至更多社交网站的 “好友”,但只能维持与现实生活中大约 150 个人的 “内部圈子”。而 “内部圈子” 好友在此理论中指一年至少联系一次的人。
按这个定义,我自己的感受是很难维持这么多联系,因为社交负担太大了。当然如果把上文中的 “联系” 理解成朋友圈点个赞也算的话,勉强也能达到吧。实际上,好多曾经阶段属于好朋友的人,过了那一个阶段,比如考上大学,大学毕业后各奔东西,慢慢也就进入了这个圈层。一开始还常联系,慢慢联系会越来越少,最后只在重要节假日(如春节)发个短信或红包了。
曾经熟悉的同学、同事们,大部分都在这个圈层中,除此,也会有一些当下新认识的熟人。总之,这个圈层中都是一些你们彼此还算认识,并且在一定程度上也彼此认同对方一部分价值的人。
以上就是几乎所有人都有的社交连接圈层。再往后的三个圈层,就只有极少数人拥有了。
### 1000
2008 年著名科技作家凯文·凯利写了一篇文章《一千个铁杆粉丝》1000 true fans这里的 1000 连接圈层就是这么来的。不过这有个前提,就是你必须是一个创作者,而凯文·凯利的观点是:
>
任何从事创作或艺术工作的人,例如:艺术家、音乐家、摄影师、工匠、演员、动画师、设计师或作者等,只要能获得一千位忠实粉丝就能维持生活。
他大概是这么计算的通过出售创作作品每年从每个铁杆粉丝上获取100美元的收入那么每年大概有10万美元的收入就足够生活了。今天获得 1000 个粉丝不算太难,但在前面加上铁杆,就太难了。所谓铁杆,就是不论你创作的是什么,他们都愿意支付买单。
而我理解 1000 个铁杆也不必是固定的同一批人,可能是流水变化的 1000 人,他们只是每年为你不同的作品支付买单而已,但前提就是你得有持续的创作能力。
### 10000
这个层次是拥有一万个关注者(如:微博)或订阅者(如:微信公众号)。
这个量级才算是拥有了培育自己观点和内容种子的一块自留地,在这块土地上你可以播下你的观点,可能有人支持,也有人反对,更多人是不置可否,但至少你可以开始拥有了反馈。但若没有这块自留地,你的声音或观点几乎不会在互联网上收到什么反馈,也无法形成有效的讨论和互动。
### 100000+
自从有了微信公众号100000+ 现在也是一个神奇的数字了100000+ 的存在,体现了一个信息、观点与影响力的传递网络。
五种连接圈层,第一层次 “10” 的连接是强连接;其他的都是弱连接,弱连接的价值在于获取、传递与交换信息。**强连接交流情感,弱连接共享信息**。
而建立连接的关键在于:**给予**。也许并不需要物质上的给予,仅仅是心理上或是虚拟的给予。所以说为什么展现是扩大连接的基础,展现即创作表达,创作即给予。另外,建立连接得先提供价值,而且还得源源不断。
关于 PPC 个人发展理论的分享就到这里了,我们总结一下:
- 专业,建立价值内核;
- 展现,提供价值输出;
- 连接,完成价值交换。
**专业是价值,展现是支点,连接是杠杆。**
最后,补充说明下:虽然本文指出了三个维度,但实际这三个维度并不是均衡发展的,每个人都需要根据自己的具体特点和主观意愿去做选择平衡。其实,任何一个维度发展到极致,都会有巨大的价值,但极致,何其难矣。
关于这三个维度的发展,你有怎样的观点呢?欢迎留言分享。

View File

@@ -0,0 +1,83 @@
<audio id="audio" title="58 | 三人行:前辈、平辈与后辈" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/67/fd/6793d75e19d6aebf08580604f3f46cfd.mp3"></audio>
成长的路上,有时会陷入停顿,感到迷茫,就像前行的一辆车陷在了泥地里,不管你怎么加油踩油门,它只是在原地打转而无法继续前行。这时,你就需要有人来帮助,或推或拉或扶。而从广义的角度看,总会有三类人在身边,你未必是独行。
孔子说:“三人行,必有我师”。原意中的“三”是虚数,泛指多人,意思是身边的任何人都可以成为你的老师,拥有值得你学习的地方。成长的路,本是一条越走人越少的路,但若有伙伴同行,你会走得更远,走得更久。
这就是成长路上的三人行,此时的“三”不再是虚数,而是指代身边的三类人,它们是:
- 前辈
- 同辈
- 后辈
这三类人代表了不同的成长路径和成长阶段。你应该有一个动态的列表,在成长的不同阶段将这三类人中的典型代表放在这个列表中仔细观察。
如果放在职场上,前辈可能就是你的上级,是比你更资深和有经验的人,是走在你前面的人;同辈自是你的同事,你们在不同的领域各有所长,甚至在同一领域做得比你还好,但不管怎样肯定是让你尊敬的人;而后辈可能是你的下属,他们也许正在走你曾经走过的路,可能正在做你一年、两年或三年前做过的事,而且可能做得比当时的你更好。
如果你在身边都找到了这三类人的典型代表,你观察他们,便是以他们为尺来度量自己;你学习他们,便是以他们为模来塑造自己;你加入他们,便是从后辈的重复中去反思过去,从同辈的领域中去扩展当下,从前辈的脚印中去引领未来。
## 前辈
前辈,是那些走在你前面的人,他们不止一个,且每个人都会有不同的路径。观察他们的路径,哪个更适合自己,哪个人的哪些方面让你更想要去模仿。在职场上,这些人似乎都有差不多的等级,但实际上每个人都有不同的特点和路径。
在不同的阶段,会有不同的前辈。而最适合作为前辈代表的人,应该在你前方不远处,因为这样的观察、模仿和借鉴才更有意义。毕竟走在你前方太远的人,他们的行为方式和路径你都很难看得清晰,而且很可能你们的工作活动已经处在不同的维度了,这阶段的你还理解不了。比如,刚入门的新手,适合观察和借鉴的前辈应该是比较熟练的中级工程师,而不是架构师。
程序员有时爱自比农民,自称 “码农”,因为程序员每天写代码的工作,就像农民种地。一个初出茅庐的程序员,不断地通过提升技能、吸收经验和改进工具来提升产量。从一开始的手工作业,到利用耕牛(新的技能和工具),再到现代化的机器工程作业(进一步改进的技能和工具),所负责的田地亩产量越来越高,每天能耕耘的土地面积也越来越大。直到有一天,技能提高和工具改进接近了极限,耕种的土地面积和单位产量增长都渐渐停滞。
之前的这个改进过程都是一个自然连续的成长过程,而当你进入极限区增长停滞后,再给你更大的土地,要求更高的产量时,这个连续的增长过程就被打断了,你会看到虽有前辈在前方,但中间的路却断了。
在这个断点之前,前辈的价值在于:**他们走过的路,你不用再去摸索,只需快速顺着走下去**。这个过程中你只需要刻意地玩命练习去解决自然连续的快速成长问题,而在断点之后,前辈在没路的地方留下的 “脚印” 也解决了非连续性的跨越问题。
十多年前,我以为程序员的成长终点是架构师,后来我知道了,程序员的自然连续成长终点是资深程序员,也许还有 “神” 级程序员。但架构师却是从某个点开始断裂分叉的另一条路,从程序员到架构师,就需要跨越非连续性断点,而转型到技术管理者也会面临同样的非连续性断点。
跨越非连续性的断点转变意味着什么?有一部电影叫《爆裂鼓手》,电影中有两个角色,一个鼓手,一个指挥。鼓手类似程序员,指挥则像架构师。成为顶级鼓手的路是玩命练习打鼓,成为指挥的路则是放下鼓槌,拿起指挥棒,协调各种乐器的演奏。
放下了乐器,未必是放弃了音乐,电影中的指挥,任何时候乐队中的任何一个乐器吹(拉、弹、打)错了一个音,他都能立刻分辨出来。这就是另外一条路的另一套技能,是为了得到更大规模的生产力和更震撼的演奏效果(品质)。
除此之外,**前辈的另一个价值在于塑造环境,而环境决定了整体的平均水平线**,在这个环境中的个体很少有能大幅偏离的。
就以我的中学环境为例,当年我进入这所少数民族中学时,那一届高考最好的学生是考上了中央民族大学。六年后,到我参加高考时,学校师生都在为实现清华北大的零突破努力,虽然依然没能实现,但这届学生的最高水平已经可以考上除清华北大之外的任何大学了。
在我所在中学的这个环境中,每一届高考学生都是下一届的前辈;每一年这些 “前辈” 们都在把学校的高考水平线抬高一点点,在前进道路的尽头继续探索走出长一点点的路来,而到我的下一届终于实现了零突破。
所以说在一个既定环境中,有强悍的前辈是我们的好运气。
## 同辈
同辈,本是那些与你并行前进的人。
同辈,特别是临近的同辈间普遍存在竞争,这也是所谓的 “同辈压力” 的来源。而很多时候我们的进步就是被这种压力逼出来的,这样压力转化为动力,同辈就成为了动力源。
还是以中学这个环境为例,同届的同学之间就是一种同辈关系,而且有相当的竞争压力,都在竞争大学的录取名额。在参与考试竞争这件事上,我可以做到期末或模拟考试班级第一或者年级第一,但高考的竞争其实是在全省范围的同届学生之间展开的,每次模拟考试下来发现离最高分还差很远,我就产生了一个困惑:为什么会觉得无论如何我也不可能达到那个最高分?
如今我自然明白了,我当时做不到是因为在学习和考试这个领域,我没有一个参考视角获知最高分的同学是如何学习的,而且这样的同学所在的学校环境,其整体水平线要远高于我所在的学校。因而,我想如果当时能有一个环境,让我和这样的同学产生交流和共同学习,那么必然我也可以得到提高。
中学是一个相对单一维度的领域,同辈同学间都是在忙于学习和考试;而到了职业和工作领域后,维度就丰富了很多,每一个同辈都可以拥有自己独特的领域,他们之间得以互相观察,并能相互沟通、交流与合作。
那什么是领域?这听起来有点像是一个玄幻小说的术语,在一些玄幻小说中,拥有领域的人物都是超厉害的,在他们的领域中,都是近乎无敌的存在。**领域,是一个你自己的世界,在这个世界中,你不断地提出问题并找到有趣或有效的解决方案**。进入这个世界的人,碰到的任何问题,你都解决过或有解决方案,慢慢地人们就会认识到你在这个世界拥有某种领域,并识别出你的领域。然而,计算机专业毕业的程序员们,人人都拥有专业,但工作十年后,不是人人都能拥有领域。
所以,在你前行的路上,碰到一个拥有领域的同行者,是一种幸运。所谓术业有专攻,每一个拥有领域的人,都有值得敬佩的地方,因为这都需要付出艰辛的努力。
每个人都能拥有一个自己的领域,在自己的领域内去耕耘、创造、提升,纵向提升这个领域的深度,横向扩张领域的维度,当和其他人的领域发生交集时,取长补短,也许还会产生意外的收获。
同辈,除了竞争,也有碰撞与交流,它会成为你的催化剂。
## 后辈
后辈,他们正沿着你走过的路直面而来。
好些年前,工作没几年,带了两个刚毕业的学生。我把我的自留地分了一点让他们种,每隔两天我就去看看他们种的怎么样?每次看完,我都忍不住想去自己再犁一遍。后来我还是没忍住,最后又自己种了一遍。如今回想起来,虽然保障了当时的产能,却牺牲了人的成长速度。
**人,似乎不犯一些错,就成长不了,也许这就是成长的成本。**
如今,我再回头看这样的路径和例子,就会以成长思维去考虑,而不仅仅是产能视角。为了获得长期的产能效率,有时不得不承担一些短期的成本压力。而后辈们,既可能重复犯下曾经的错误,也可能走出更好的路径。通过观察他们的来路,我反省到了过去的错误,也看到了更好的路径。
回望后辈直面而来,假如再来一遍,我能做得更好吗?我们无法改变过去的事实,但可以从思想上修正过去,以更好地作用于现在和未来。
成长路上三人行,有前辈、同辈和后辈。前辈塑造环境,开辟道路,留下脚印;同辈之间有竞争,也有交流与合作,既带来压力,也激发动力,催化能力;后辈带来反思,也提供支持。
前辈探路开拓,同辈携手并行,后辈参考借鉴。
在成长的路上,你需要找到当前阶段的三类人,也许就会感觉这条路走起来也就没那么迷茫和孤单了,你觉得呢?

View File

@@ -0,0 +1,87 @@
<audio id="audio" title="59 | 三角色:程序员、技术主管与架构师" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7e/51/7ea6752e61ee6e2ae7fb2d634f7fa051.mp3"></audio>
还记得[开篇词](https://time.geekbang.org/column/article/12148)中我画了一个程序员的成长路径图,其中在图的左侧部分展示了程序员成长路径上一些主要阶段的定义,在我们从初级走向资深的过程中,会面临一条支路,在这条路上不仅普遍称呼的名称不同了,工作内容可能也发生了变化,角色的转换会带来不少的困惑。
这条路就是从 “程序员” 到 “技术主管” 再到 “架构师” 的路径,下面我们就来看看这条路径上的三个角色有何不同?
## 程序员与寻路
当我刚进入软件行业成为一名程序员时,我的理想就是成为一名架构师。
“架构师”这个词的英文叫 Architect原意是建筑师因为软件行业参照借鉴了很多建筑行业的概念所以就借用这个词。我是在学校读书时知道“架构师”这个名词的当时很多软件方面的书都是翻译过来的也不知道是谁最早把 Architect 翻译成了“架构师”的。总之从那时起,“架构师”这个名词对于我这个刚准备走出校门的学生来说就特别高大遥远,自然当成了最初的一个职业目标。
但遗憾的是在我从业前几年的好几家公司,都没有架构师这个职位,直到后来进入了互联网公司。到了京东后,不仅有架构师职位,还有架构师团队;在这里,不仅有了方向,还可以放心地作为一名程序员发力狂奔:不停地写程序,优化代码,追求更优、更简洁的代码,重构了一遍又一遍,解决了一个又一个问题。
在前面的文章中,我将程序员具体和代码相关的工作比作剑术,修炼代码技能类似练剑的过程。很多程序员梦想着有一天能成为一代高手,面对敌人,抽刀拔剑,刹那间交击,归剑入鞘,敌人倒下。就像线上系统突然出现大问题,你打开电脑,看了几眼日志,敲下几行代码,系统分分钟恢复。
一个好的程序员当然要能写得一手好代码。在工作前十年中,我每天的主要工作内容就是编程写新代码,重构旧代码,直到有一天发现这样不断继续下去,我的“剑术”已精进迟滞,进境有限。而当时所在的系统开始向大规模分布式化方向发展,更大的价值已不再是代码实现层面上的局部优化。
那时我开始在团队承担起整体的系统设计工作,此时若再专注于局部代码优化其实是在驱动细节而非本质了。作为资深程序员出身的架构师,单兵作战能力都是极强的,就像《进击的巨人》中的利威尔兵长,具备单挑巨人的能力。可当面对成群结队的巨人来袭时,个人单挑能力的作用始终有限。
这时,**从程序员到架构师不仅仅是一个名称的变化,它也意味着技能和视角的转变**。在地上飞奔了七八年的程序员,在面对成群的巨人袭来时,深深地感觉到,杀光巨人不应是目的,真正的目的应是到达彼岸。所以,选择合适的路径,坚定地前行,清除或绕过挡道的巨人,到达目的地。
是的,我是到了资深程序员阶段直接转向了架构师。而在路径图上还有另一条路,会经历另一个角色:技术主管,这是一个从程序员到架构师阶段的过渡角色。
## 技术主管与过渡
技术主管,有些公司可能又叫 “技术经理”英文一般是“Tech Leader”或简称“TL”。
技术主管是开发团队中的某位程序员需要对整个开发团队负责时所承担的角色。既要对最终交付的软件系统负责,另外也会像一个程序员一样去开发实现系统。一般一个技术主管约 70% 的时间可能花在了开发任务分解分配、开发实践、代码审核和风险识别上,而余下 30% 的时间则花在为了保障系统按时交付所需要的各种计划、协作、沟通和管理上。
在拉姆·查兰 (Ram Charan) 写的《领导梯队》一书中提到一个人的工作角色中至少有百分之五十以上的时间是花费在管理事务上那么他的角色才算是一个经理Manager。所以技术主管经理更多还是偏重于技术工作有点类似产品经理属于以经理命名却非真正的经理角色。
例如:在一个开发团队中经常会碰到技术方案和实现细节方面的分歧,如果程序员无法自主友好地完成对不同技术意见的统一,这时候技术主管就需要介入去了解两种不同意见所造成的冲突,对事不对人地去把问题搞清楚,分析各自方案的利弊,必要的时候甚至能够提出第三种更好的技术方案,以帮助开发团队达成共识。
另一方面,技术主管即使在日常的开发实现中,重点的内容一般也不是放在某个具体的功能实现上。在完成了具体的开发任务评估、分解并分配后,技术主管应该负责设计整体代码的结构和规范,必要时引入能提高整个团队生产力的新工具,推广代码模板,总结最佳实践。并且技术主管需要经常性地关注整个团队完成一项研发任务的水平和实际要求的水平之间的差距问题,让团队不仅满足及时的软件系统交付,同时又得到成长。
现实中,一个开发团队中最优秀的程序员容易被指定承担技术主管的角色,但优秀的程序员又很容易陷入到实现功能的细节中,满足于完美的实现,优雅简洁的代码。但实际上,这样优秀的程序员转入技术主管这个角色后,就很容易尝试控制设计和代码的实现,他们很难接受代码不按照他们希望的方式去编写,这个是他们作为优秀程序员一直以来的工作习惯,长此以往他们自身很容易变成整个开发团队的瓶颈,而团队里的其他成员也未能得到足够的锻炼和成长。
所以技术主管实际相比团队里的其他程序员对系统的视角更开阔,以更有策略和长远的方式来考虑问题。**他们即使拥有比团队里所有其他程序员更高超的开发实现技能,对所有开发任务拥有最强大的实现自信,也需要转变为另一种 “借助他人使之实现” 的能力和自信,因为技术主管是一个承担更广泛责任的角色**,必然导致能够专注有效编码的时间会相比以前减少很多,而这一点正是优秀程序员转变为技术主管所面临的最大挑战之一。
最适合技术主管角色人,不一定是团队中编程能力最好的人,但必然是团队中编程、沟通和协作能力最综合平衡的人。而技术主管之所以是一个过渡,就在于继续往前走,如果偏向 “主管” 就会成为真正的管理者(经理),如果偏向 “技术” 就会走向架构师。
## 架构师与取舍
架构师是一个在业界拥有知名的称谓,但在绝大部分公司却不属于一个职位序列,许多公司都很纠结于如何定义架构师的角色,以及架构师所做的工作。
以前听阿里的同学说 P7 属于架构师职位,不过最近在看另一个阿里同学写的文章提及:前几年是有专职的“架构师”职位的,现在已经回归到 “工程师”“技术专家”“研究员” 这样的纯技术职位。可见在一线互联网公司关于架构师的定义也是很模糊的。
[前面](https://time.geekbang.org/column/article/41571)我曾引用过一篇文章《在首席架构师眼里,架构的本质是…》中提到的架构师能力模型图,我结合自己的经验和理解,稍微扩展解释了一下,如下:
<img src="https://static001.geekbang.org/resource/image/fa/60/fa72958586ef125d1cf1356542163a60.png" alt="">
正因为业界和公司对架构师这个角色的职责定义很模糊,所以很多经验积累到一定程度的优秀程序员,并且在公司内被提升到一定高度的技术级别后,都会冠以 “架构师” 之名。但实际情况是大部分刚刚冠以“架构师”之名的优秀程序员,其能力模型大部分还停留在上图中的蓝色区域,而对其他区域并未有过系统性的认知和训练。
看过了架构师的能力模型,我们再来试着分析下其对应的职责。技术主管的角色与架构师这一角色会产生一些职责上的重叠,事实上我认为在团队规模比较小的时候(十来人的规模),架构师和技术主管的职责几乎完全重叠,甚至技术主管还会代理一些团队主管的角色。
随着软件系统复杂度和规模的提升,团队也相应变大,那么一个架构师此时所处的职责位置就开始和技术主管区别开来。**如果把技术主管想成是站在楼顶看整个系统,那么架构师此时就是需要飞到天上去看整个系统了**。
开发功能,解决 Bug优化代码这是一个高级或资深程序员的拿手技能也是地面作战的基本技能。而一个架构师还需要掌握空中的技能也许就像《进击的巨人》中的立体机动装置让其能在需要时飞在空中看清全局也能落地发起凌厉一击。
那多了一个空中的维度,过去在地面练到精熟的剑术,飞在空中还有效么?这就需要时间去学习,适应新维度的技巧。这不是一个容易掌握的技能,这也正是前面我写过的从一个点到另一个点连成线的技能升级,需要一个升维的学习过程。
架构师站在更高的空中维度去做关于软件系统的抽象和封装。如果技术主管的抽象和封装层次更多考虑的是语言函数、设计模式、代码结构等这一类的事务,那么架构师是站在整体软件系统高度,考虑不同子系统之间的交互关系、技术的合理性、需求的完整性、未来的演进性,以及技术体系发展与组织、产品商业诉求的匹配度。
这是相对技术主管更高维度的全局视角,另一方面依然有很多技术主管可能感觉没把握的技术决策和技术争端需要架构师的介入协调。之所以要找架构师来对一些技术争端和方案进行决策判断,很多情况在于程序员对架构师在技术领域内专业力和影响力的信任,而建立这种专业力和影响力是实际构建架构师非权威领导力的来源。
何谓 “非权威领导力”?非权威自是相对权威而言,管理者的权威领导力来自于公司正式任命的职位和职权,而架构师在大部分公司基本连职位职责都没定义清楚,更没有职权一说,所以实际上就不会有任何权威领导力。所以,**架构师要发挥更大的作用和价值就需要去构建自己的非权威领导力,而这需要长期的专业力和影响力积累**。
除此之外,架构师还承担着在技术团队和非技术团队(例如:产品设计等团队)之间的接口作用,明确产品的边界,勾勒技术蓝图,协调不同技能的技术团队协作,完成最终的软件系统交付。这时架构师的角色就像服务化架构中的 API定义了协作规范、交互协议和方式但并不会聚焦在具体的实现上。
在更大规模的系统上,架构师似乎还要去涉猎更多的跨领域知识,否则很可能无法做出最适合的技术决策。但人终究是有局限的,你不可能学完所有的领域,所以特定的领域又会涌现一些垂直领域的架构师。比如:数据架构师、网络架构师、业务架构师、安全架构师。因而某一个领域背景出身的架构师,对其他领域也只能做个初步了解,当需要做出关于涉及其他领域的架构决策时,就需要和其他领域的垂直架构师做深度的沟通交流,以辅助决策判断。
一旦选择走入架构师这条路,基本你就从一名出色的程序员这个领域走出,需要尽快去补充上面能力模型中指出的其他能力。这一点会让刚刚走上这条路的程序员很不适应,因为承担了更多其他职责,就必然会减少在编码实现的时间,慢慢就会怀疑自己的编码能力会退化,也跟不上一线最新的技术栈、各种酷酷的新工具。
舍得,舍得,没有舍就没有得。成为架构师会拥有一个更立体的知识、技能矩阵,这是你的得,获得了一个面,在某些点上必然面临被超越的结局。工作在一个面上,一个有经验的架构师应该能够很好地表达某些技术指导原则,借助他人使之实现,并且了解和把握什么时候该插手,什么时候该放手。
这就是架构师从技术 “实现力” 到 “掌控力” 再到 “决策力” 的能力变迁。
从程序员,到技术主管,再到架构师,名称变化了,角色的困惑我们也分析了,最后总结下这三种角色的工作内容和职责,如下表:
<img src="https://static001.geekbang.org/resource/image/79/74/79c25644c6e01482d4b1f37e6a11b674.png" alt="">
每种角色有不同的技术和组织职责,只是在每种职责分配的时间比例不太一样。看完上表的职责范围,是不是感觉有时安安静静地做个程序员,要心净多了。
如今的你,正走在哪条路上呢?

View File

@@ -0,0 +1,114 @@
<audio id="audio" title="60 | 三视角:定位、自省与多维" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/09/52/09c106f9d2de5a8923938a6073898e52.mp3"></audio>
记得以前阅读时碰到过一个观点,是关于 “视角” 的,其中说道:“视角的选择,对解题的难易,关系重大”。而关于成长,放到程序模型中来类比,就是一道图论题,我们求解的是适合自己的最优路径。
面对这道成长路径的难题,我们可以从哪些视角来求解?我自己找到了下面三个视角。
## 定位
定位,是一个时间视角,回顾初心,定位未来。
还记得当初为什么选择程序员这个职业么?如今程序员所在的行业处于发展上升期,薪酬待遇整体高于传统行业,所以各类程序员培训机构如雨后春笋涌现,流水线般地为各类只差程序员的公司批量供应,这样的批量生产似乎有点把程序员当成了工厂的工人。
而程序员的工作实际更贴近于工匠,既有创造性的工艺性工作,也有模式化的工程性工作。想清楚自己成为程序员的初衷是什么?如果只是为了进入一个相对高薪的行业,得到一份工资高于平均水准的工作,终究是走不了太远的。
很多入门的新手程序员都是刚从学校毕业的,曾记得在吴多益的一篇工程师成长分享的材料上,如是说:
>
从小到大的教育,你习惯性被安排:“课后作业是 X1、X2后天必须交”“本学期的必修课有 XX、YY必选的选修课有 ZZ、WW”。
十几年来你都是这样度过的,但现在你已经不在学校了,你要安排你的未来。
刚入职场的程序员依然保持这个习惯,等着主管来安排。但如果你每天的工作就只是完成被安排好的任务,那么你自己的成长就会非常缓慢,因为主管安排任务时并没有那么多的精力来考虑任务是否适合个人的成长发展。这些任务是组织发展的需要,而不一定适合个人的成长发展,但组织是付了薪酬来让你完成任务的,所以这是工作的必需部分。
自己才是职业生涯的管理者,要想清楚自己的发展路径:远期的理想是什么?近期的规划是什么?而今日的任务和功课又是什么?今日之任务或功课哪些有助于近期之规划的实现,而近期之规划是否有利于远期之理想?
为什么今日除了任务外还要有功课?功课是学校里的概念,职场里没有,所以离开学校进入职场的功课都是自己给自己安排的。任务来自主管的安排,功课来自自己的安排。很多时候你只去完成任务却从未给自己安排功课,而等着被安排和主动安排之间,在未来将产生巨大的差别。
一开始你可能只有模糊的远期理想,也没那么清晰的近期规划,但一定要有足够清晰明确的今日任务和功课,即使在你的主管因为各种原因没给你安排的情况下。虽说方向不太可能一朝就定好,但也不要不管不顾地埋头走路,你需要抬头看路,定期检视,因为如今环境和大势的变化也很快。在边走边看的过程中逐步就清晰了近期的规划,甚至远期的理想。
另外,主管在你职业发展的路上,除了大部分时候给你安排任务,偶尔也可能给你创造机会,而机会出现时你能否抓住,全在今日之功课上。
**定位的视角,是关于一条成长的时间路径,它关乎:昨日初心,今日功课,明日机会。**
## 自省
自省,自我的视角,关乎自身,是一个观察自己成长路上行为的角度。
乔治·海尔迈耶George Heilmeier是一位美国工程师和技术管理者他也是液晶显示技术的主要发明者之一。他在科研领域最著名的事情就是他提出的 “海尔迈耶系列问题”:
>
<p>你要做什么?不要用术语,清晰地表述你的目标。<br>
&nbsp;<br>
这件事现在是怎么做的?现在的做法有什么局限?<br>
&nbsp;&nbsp;<br>
谁在关心?你的方法有哪些创新?你为什么觉得你的方法能够成功?<br>
&nbsp;&nbsp;<br>
如果你的方法能够成功,它能带来怎样的变化?<br>
&nbsp;&nbsp;<br>
你的方法需要花多少钱?需要花费多少资源?要怎样在过程中和结束时进行评估?</p>
我觉得这个系列问题,用在程序员个人成长上也有异曲同工之妙,因为现在的技术方向和路线太多,即使选定了路线依然会有很多茫然和困惑。如果你想要学习一门新技术或在项目中引入一项技术,就可以试试套用 “海尔迈耶系列问题” 来自省一番。
- 你学习这项技术的目标是什么?清晰地表述出来。
- 这项技术现在是怎么做的?有什么局限吗?
- 这项技术有什么创新之处?为什么它能够取得成功?要是在项目中引入这项技术,谁会关心?
- 如果这项技术能成功,会带来怎样的变化?
- 采用这项技术的成本、风险和收益比如何?你需要花费多少资源(时间、金钱)?如何去评估它的效果?
程序员有时粗浅地学习并了解了一点新技术,就想着如何应用到真实的项目中。这时用上面的问题来问问自己,如果有回答不上来的,说明你对这项技术掌握并不充分,那就还不足以应用到实际项目里。
除了技术领域,你成长路上的许多行动,都可以此为参考坐标来反思:“这项行动的目标清晰吗?行动的方法有可参考的吗,局限在哪?我能有何创新之处?完成这项行动,会给我带来怎样的变化?我要付出多少时间、金钱和精力?行动过程中我该如何评估?行动结束的标准是什么?”
这就是**自省,从埋头做事,到旁观者视角的自我反思**。
## 多维
多维,是一个空间视角,关乎如何选择不同维度的成长路径。
有些时候,程序员写了几年代码,觉得太枯燥乏味,就想着是不是可以转管理,比如转技术主管之类的。从技术到管理似乎就是一条多维度的发展路径,是这样吗?不是的,这不叫多维扩展,而仅仅是想从一个维度逃离,转换到另一个维度。
打造多维度竞争力的前提是,要先在一个维度上做得足够好,让其成为你赖以生存的维度,这个维度就是你的核心基础维度,而它是其他维度得以发展的根基。其中,“足够好”的程度,可能就是指我们常说的 “精通”。
关于“精通”的概念,每个人的理解可能会有所不同,但我认为“精通”肯定不是无所不知,而是可以拆解成两个层面:第一,如学校时期学过的卖油翁所说的“无他, 惟手熟尔”;第二,在一个领域形成自己的体系和方法论。
第一个层面,表达了在当前维度的不断精进,在精进这个方向上,有一本书和咱们专栏主题类似,但更微观一些,偏向于 “术” 的层面,但又有点从 “术” 悟 “道” 的意思。这本书叫《程序员修炼之道:从小工到专家》,书里覆盖了一名程序员真正面临的一些问题,比如:
>
<p>与软件腐烂作斗争&nbsp;&nbsp;<br>
避开重复知识的陷阱&nbsp;&nbsp;<br>
编写灵活、动态、可适应的代码&nbsp;&nbsp;<br>
使你的代码 “防弹”&nbsp;&nbsp;<br>
捕捉真正的需求&nbsp;&nbsp;<br>
无情而有效的测试&nbsp;&nbsp;<br>
无处不在的自动化</p>
这些具体问题的解法,就是第一层面。然后逐步上升到了第二层面,它的方法体系,一篇书评中将其称为本书的 “哲学”:
>
本书的哲学将渗入你的意识,并与你自己的哲学交融在一起。它不鼓吹,它只是讲述什么可行,但在讲述中却又有更多的东西到临,我们有时称之为 “无名的品质Quality without a name”。
当这些问题倒下而你还在程序员的阵地上时,想必你就会让人感受到那种 “无名的品质”,此时你也就在当前维度走到了 “精通” 的门前。在第一层面上你达成了品质和效率,然后在第二个层面上,抽象出了当前维度的 “解”,那么就可以通过 “启发式” 方法应用到其他维度,具备了向其他维度扩展的基础,从一个细分领域到另一个关联领域的 “精通” 能力。
所谓 “**启发式**” 方法,就是 “在某个视角里,使用这个规则能够得到一个解,那么你受此启发,也许可以把这个规则用在别的问题上,得到别的解”,而规则就是你在一个维度里抽象出来的方法论体系。
当你感觉在技术维度进境迟滞时,可以尝试扩展到英语维度去,接触一手的技术论文或资料,说不定就能获得启发,找到新的技术维度进境之路。作为多年的程序员,已经形成了用工程师思维分析和求解问题。抽象出来看,程序员都是对问题领域进行建模,然后再用代码实现求得一个 “概率解”。
编程实现得到的难道不是一个确定的系统或服务吗?为什么是 “概率解”?系统或服务是确定的,但解决的问题,如:需求满足率、服务可靠性,却是概率的。每完成一个系统版本的发布,到底多大程度地满足了用户需求,其实是一个概率,这个概率可以通过用户反馈得到一个大概的感知,但你几乎不会知道一个确定的值。而可靠性,相对来说会更可量化,比如在 99.9% 99.99% 之间波动,但也不会是确定的百分百。
工程师的这个求解模型,可以转移应用到其他很多与你息息相关的工作生活领域,比如投资理财,把钱存银行定期赚钱的概率解无限接近百分百;但买基金、买股票的概率解对大部分人来说就完全靠赌和猜了,因为缺乏一个合适的模型去求解,而对领域建模应该是程序员的强项,也是可迁移扩展到其他维度的能力。
即使是学习成长本身,也可以用工程模型来求解。这时你的学习维度就需要扩展一下,不仅仅局限于你当前的专业领域,还可以了解点神经科学,认知心理学之类的,并配合自己的现实情况、作息习惯,去建立你的学习模型,获得最佳学习效果。而学习效果,也是一个 “概率解”。虽然你不能知道确切的值,但我想你肯定能感觉出不同模型求解的效果好坏。
简言之,**多维的路径,其实是从一个核心基础维度去扩散开的**。
最后,我们总结下,在求解成长的最优路径时,视角的不同,对求解的难度差别巨大。我分享了我的三个视角:**定位,时间视角;自省,自我视角;多维,空间视角**。通过三个不同的视角,探讨了关于 “我” 与所在现实的时空关系,从中尝试提炼出一种方法,用于探索最适合自己的成长路径。
成长最优路径,求的依然是一个概率解,只是我感觉通过这三个视角去求解,也许概率会更高。
你不妨将这个三维度,套在自己身上,感受一下呢。