qq_37756660的博客

在写这个专栏之前，我已经写了好些博客，写过很多关于技术的，也写过更多围绕程序员或者说当时的我自己成长的一些感悟。在回顾曾经写过的一些主题时，发现很多技术的内容可能都随着时间变迁过时了，但关于成长的认知却依旧历久弥新，因此选了这个关于成长的主题。——始于知，终于行。

回顾过去，我们会清晰地看见走过来的路线，但面向未来我们又该如何走下去？但凡过往，皆为序章，过去不可变，未来才是希望，而如何去规划并管理好未来的成长进化之路，才是我们当下要面临的主要任务。我们先从一个高度抽象的维度，来看看这条成长之路。

在前文中定义过程序员的职场阶梯，而阶梯不过就是很多人已经走过的路，我们只需要沿着这条路去持续成长就能爬上还算不低的楼层。只是到了一定楼层后我们会发现上面似乎还有几层，但却看不见下一层的楼梯了。因为再往上走的人就不多了，也就没能成了路，自然也就看不见，这可能就是所谓成长阶梯的断层。在程序员的成长阶梯上，到了一定阶段，我们可能会面临方向的选择，不同的方向选择意味着不同的路径，会碰到不同的断层，而跨越断层也需要不同的方法。那我们会面临怎样的方向选择呢？

程序员的主流成长发展路线，是一个明显的“T”形线路。在纵深方向上，工作到一个阶段后，可能我们就会感到深入不下去了，而且越走会越有沉滞的感觉；在横向上，是广度方面，包括技术专业之外的领域，也会感觉了解甚少，短板明显。有时候，要想产生真正的成长转变与发展突破，就不应自我局限于当下的工作内容和技术专业。

记得以前阅读时碰到过一个观点，是关于 “视角” 的，其中说道：“视角的选择，对解题的难易，关系重大”。而关于成长，放到程序模型中来类比，就是一道图论题，我们求解的是适合自己的最优路径。面对这道成长路径的难题，我们可以从哪些视角来求解？我自己找到了下面三个视角。

还记得开篇词中画了一个程序员的成长路径图，其中在图的左侧部分展示了程序员成长路径上一些主要阶段的定义，在我们从初级走向资深的过程中，会面临一条支路，在这条路上不仅普遍称呼的名称不同了，工作内容可能也发生了变化，角色的转换会带来不少的困惑。这条路就是从 “程序员” 到 “技术主管” 再到 “架构师” 的路径，下面我们就来看看这条路径上的三个角色有何不同？

成长的路上，有时会陷入停顿，感到迷茫，就像前行的一辆车陷在了泥地里，不管你怎么加油踩油门，它只是在原地打转而无法继续前行。这时，你就需要有人来帮助，或推或拉或扶。而从广义的角度看，总会有三类人在身边，你未必是独行。孔子说：“三人行，必有我师”。原意中的“三”是虚数，泛指多人，意思是身边的任何人都可以成为你的老师，拥有值得你学习的地方。成长的路，本是一条越走人越少的路，但若有伙伴同行，你会走得更远，走得更久。这就是成长路上的三人行，此时的“三”不再是虚数，而是指代身边的三类人，它们是：前辈同辈后辈。

曾经在和朋友探讨个人发展的问题时，讨论出一个，该理论粗略地把涉及个人发展的方向分成了三个维度，包括：专业 Profession展现 Presentation连接 Connection而像程序员这样的专业技术人员，都倾向于在专业维度不断发展提升，却往往忽略了另外两个维度。如果三个维度综合发展的话，可能会得到 1 + 1 + 1 >> 3 的效果，即三个维度相加远远大于 3 的效果。

在前文《江湖路》中找到的路是一条之路，技能与战场的升维演化是一个相辅相成的过程。进入了升级后的战场，也需要升维后的技能模型，那我们该如何从旧有的技能模型进行升维演化呢？我想还是用一些形象点的武功招式来类比说明。

回首自己的成长之路，通常每五年就会感觉碰到一个成长的瓶颈点。在传统 IT 行业的第一个五年后，我就感觉明显进入技术成长的瓶颈期；之后也算有点运气，通过转换到互联网行业升级到了新的技术维度。又过了五年，站在十年后的一端，回望过去，刀剑相接，如梦似幻，我渐渐感知到突破这次瓶颈的道路，就意味着走向一个升级后的新战场。

从今天开始，我们进入了专栏的第 5 部分 ——这是一条关于方向、角色和自我定位的探索，那就让我们开始一起走走这条程序江湖路吧。大约三年前吧，读到一篇文章《为何我工作十年，内心仍无比恐慌》，来自一位腾讯产品总监的演讲分享。文中分析了一个让其感到恐慌与焦虑的深层次原因：好像不会什么技能，技能门槛低。这种恐慌和焦虑感在这个行业中普遍存在，不止于产品经理，程序员也一样。

从大学到职场，会经历一次失衡。在学校的时候，虽有时间课程表，但大部分时间还是属于我们自己自由安排的。毕业后，一进入职场，就会发现工作开始占据了主导，而后随着工作日久，越发陷入一种关于工作与生活平衡的选择困惑。

想要取得成就，就会面临竞争，几乎所有的成就，都是直接或间接通过与他人的比较来评价的。不同的选择，意味着面临的竞争水平不同，付出的努力自不相等。

在编程的路上，我们总会碰到历史系统，接手遗留代码，然后就会忍不住抱怨，那我们是在抱怨什么呢？是债务，技术债务。以前说过，，而历史系统的遗留代码往往是大量技术债务的爆发地。然而，技术债务到底是如何产生的？它是我们有意还是无意的选择？这里就先从技术债务的认知开始谈起吧。

作为一名程序员或技术人，总会碰到这样的场景：在一些技术评审会上，和其他程序员就技术方案产生分歧与争论。如果你是一名架构师或技术 Leader，站在技术决策者的立场和角度，该如何去解决分歧，做出决策呢？这背后，有什么通用的方法和原则吗？

回答了标题的问题，这篇文章也该结束了。面对技术这片大海，我们都是一个渔民，三天打鱼，两天结网。愿你的“网”越结越大，捞的“鱼”也越来越多，也欢迎留言分享下你的“打鱼”和“结网”经历。

以前曾接到过一些关于程序外包站点的营销邮件，也看到过身边有些人选择去接一些外包，赚点外快。当然也有人找到过我做外包项目，这时我就必须做出一个评估和选择，面对外包赚钱的诱惑，到底该如何进行更好的选择呢？

大约是 2015 年时，那是一个大众创新、万众创业的 “双创” 年代。当时，创业公司如雨后春笋般出现，又如昙花一现般凋零。也是在那年，招聘时碰到过一个人，一年换了三个公司，我就问：“为什么这么频繁跳槽呢？”而他的答案也让我吃了一惊，他说因为他加入的每家公司，没几个月就都倒闭关门了。那时候，我和我身边的同事都收到过来自创业公司的邀约，有的同事就此去创业了，而我最终选择了拒绝。后来，我复盘了当时的场景，面临这样的选择，会同时有感性和理性的因素。

关于中年之惑，你有哪些看法呢？

我们都知道代码评审（Code Review）很有用、很重要，但现实中我所经历的和看到的团队，很少有能把代码评审落地得很好，并发挥出其应有作用的。这个问题困扰我已久。

成长的路上，写过的代码最终也许会烟消云散，但完成的作品会成为你点亮的勋章。

前面说了用户仅仅反馈了一个说法，站在用户的角度，他们总是希望没有任何问题的。但站在我的角度，我知道我只聚焦了一部分问题，所以我需要清晰定义这部分问题解决的成功标准。比如，针对应用切后台就被系统杀掉，对用户无感知，所以认为收不到消息是有问题的。针对这个问题的聚焦范围，我可以提供第三方推送渠道在十分钟内的推送通知补偿，重新唤醒用户重回应用，避免消息的遗漏。

我们从开始学习程序，到工作十来年，中间可能会出现几次自我感觉技术停滞了。而在这个过程中，我们也会不断地学习很多新技能，但而后其中的不少也会被淘汰在时间的旅程中。一方面，我们在不断地打磨、提升技能，去解决工作中的问题，但久而久之，就会发现技能的提升速度越来越慢，竟渐至停滞，感觉不到进步了。另一方面，程序员所处的这个行业，技术的变化很快，潮流此起彼伏，难免产生技能焦虑。有时，我们会不免幻想要是学会什么屠龙之技，从此高枕无忧，该多好！但这终究只是幻想，哪里又有什么屠龙之技呢？

沟通问题，一直都是程序员的痛点。（左耳听风）的陈皓老师以前在他的博客上写过一篇文章叫《技术人员的发展之路》，里面提及职业发展到一定阶段，也许你就会碰上一些复杂的人和事，这种情况下他写道：这个时候再也不是 Talk is cheap, show me the code!而是，Code is cheap, talk is the matter!这里的 Talk 其实就是沟通，在工作中你要是留心观察，就会发现很多沟通问题，比如，跨团队开会时常发生的一些分歧和争论。

之前看过一些关于算法方面的书，提到了一些最优化问题。最优化问题在现实中非常常见，比如工程设计中，怎样选择设计参数，使得设计方案能以尽量低的成本预算满足设计要求。而近年来热门的机器学习建模也是一个最优化问题，基于一组已知的数据去构建一个模型，让这个模型去适配未来未知的数据达到最优，然后求解关于这个模型的参数。。而从全局来看，这并不是最优的选择，但算法此时就进入了一种尝试的徘徊状态，这就是局部最优点，但算法并不知道这到底是不是全局最优的。

从今天起，咱们专栏即进入第 4 个大主题——。成长的途中，我们总会面临很多的困扰与惶惑，这些困扰和彷徨很多都关乎选择，只有了解并认清这类困惑，我们才可能做出最合适的选择。职业生涯的路上，每个人都会碰到，我也不例外。曾经好几次，我都陷入其中。如今从中摆脱出来后，我就想尝试搞清楚这样一种状态的根源，思考一种方法来缩短它持续的时间，或者说增加它出现的时间间隔。那职业倦怠到底是怎样的一种感受呢？

写了多年代码，做了好多的工程，不停地完成项目，但如果你一直仅仅停留在重复这个过程，那么就不会得到真正的成长与提高。你得从这些重复做工程的过程中，抽象提炼出真正解决问题的工程思维，用来指导未来的工程实践。什么是？。做了多年的软件开发工程，碰到和解决了数不清的问题，最终这些问题，我发现稍微抽象一下，可以归为以下两类：1. 可以简单归因的问题：属于直接简单的因果关系；2. 难以简单归因的问题：属于间接复杂的因果关系。上面的描述可能有点抽象，那具体该怎么理解呢？

在学校时，你学习编程，写写课程作业的代码，但你想过真正的行业里，公司中的规模化开发方式是怎样的吗？在上一篇《核心：安全与效率》的文中，你应该还记得我讲的那个电站的例子，那么编写课程作业的代码就像搭建的 “酒精灯电站”，而工业级的规模化开发才是建设 “真实电站” 的方式。工业级规模化的程序系统开发包括了一系列的过程，而这一系列过程的起点是：需求。

在模块的最后一个主题，我们聊聊工程，不是具体的工程的技术，而是抽象的工程之道。做了很多年的工程，开发了各种各样的系统，写了无数的代码，说起这一切，我们都在谈些什么？我们谈过程，从需求工程到开发流程，从编码规范到同行评审，从持续集成到自动部署，从敏捷开发到极限编程；我们谈架构，从企业级到互联网，从面向服务架构（SOA）到微服务架构（Microservice）；我们谈复杂性，从高并发到高性能，从高可用到高可靠，从大数据到大容量。那么对于这一切，你感觉这里面的核心是什么？

现在很多公司都有一种带新人的导师（Mentor）制度，导师制的初衷是为了帮助新员工快速熟悉公司环境，并提供工作技能和个人成长的帮助，正所谓 “传帮带”。这是用制度建立并约束了一种在新、老员工之间的关系，这本是一个很好的出发点。但想要类似这样的制度关系发挥期望的作用，恐怕就需要 “导师” 和 “学徒” 都有一个更高层次的清晰认知，毕竟制度只能在其中起到催化的作用。

一般来说，公司到了一定规模都会形成自己的职场阶梯，程序员在攀登这条阶梯时，肯定会涉及到一个评定的过程。那从评定者的角度，或者晋升者的角度，该如何看待你在阶梯上的位置呢？晋升的结果和个人利益有直接的绑定关系，而且这个过程从来都不是一个简单的是和否的选择，那你该如何看待这个“不简单”的晋升过程呢？

任何种类的职场上升通道都是一个阶梯，但程序员的阶梯有何不同呢？在程序员职业生涯的发展过程中，都会经历一个修炼成长、打怪升级的过程，而每个公司可能都会定义自己的升级阶梯。以 AT 为首的两大巨头，其对技术人员的级别定义在互联网业界比较公开。例如，阿里的程序员级别从 P4 到 P14，而腾讯则定义了五个大级别：从 T1 到 T5，并且 T4 之前的级别内部还会细分为若干小级别。相对来说，腾讯的 5 个大级别与我自己一路走来经历的几个阶段感觉会比较匹配一些，而大级别之间的分界线也会更明显一些。

让听众了解你，证明你有资格讲这个主题。

对于写作这种展现形式，有一种最好的补充手段就是画图。有时文字描述了半天还不如一张图来得清晰，正所谓：一图胜千言。这对于程序员特别需要的技术性文档或文章写作，都是最好的补充注解，有时甚至起到了画龙点睛的效果。以前在网上发一些技术博文，就常有读者留言问我是用什么工具画图的。其实我感觉他们很可能问错了问题，因为我曾经为了画好图尝试过各种不同的画图工具软件，但最后发现能不能画好图和工具的关系并不大。

程序员群体有个共同的弱点，那就是写得了代码，解决得了问题，但却不能很好地展现自己的能力。从今天开始，咱们专栏即进入一个关于 “展现” 的主题，聊聊（写作、画图和演讲）三类最常见的展现手段。，它是一种能随着时间去沉淀的长尾展现形式。曾有多人问起，写作除了坚持写、持续写、长期写，还有什么其他技巧么？答案是：有的。虽说我并没有上过专业的写作课，但在长期的写作过程中，我已通过实践摸索出来了一套符合程序员这种理性逻辑思维的写作技法，简言之，就是：写字如编码。

在你从程序新人成长起来的过程中，要学会区分，哪些确实是值得学习与推广的好方法，哪些仅仅是自己的个人习惯，特别是在你成长到开始成为技术管理者之后。古语有云：“己所不欲，勿施于人。”而己之所欲，若是自己特有的习惯偏好，也就请勿妄施于人了。若确实觉得是个好方法，尽量建议于人，而非强加于人，即使你手上掌握有强加的权力。反过来看，程序行业，编程实践中，存在大量流行的概念、模式、原则，甚至哲学，它们的产生都有其历史背景和过程，并在一定范围内形成了共识。

无论做什么工作，一路上你总会碰到各种各样的问题，而提问应是你解决问题的一种有效途径。更进一步，如果能把提问固化成为你的一种习惯，那它就不仅仅是一个解决问题的“工具”，甚至还能引导你的人生选择。提问这个习惯，我有三个层面的理解：1. 如何问？2. 问什么？3. 为何问？

试一试，是走出舒适区的一次行动，这本是一个好的出发点，但若只有一个模糊的终点，那么它带来的更可能就是无谓的浪费。试一试，不仅要有一个好的出发点，还需要一个清晰的终点，在这个终点你可能：验证猜想、收获结果、体验过程、理解现实。而在起点和终点之间，你需要选择一条更现实的路径，通过不断地尝试，走出自己的体系。试一试，本该是个好习惯，可别把它用坏了。想必很多人都有过盲目尝试的经历，欢迎留言分享你的经历及反思。

之所以需要先感知与测量，就是为了更好地了解你的时间都花在哪里去了。下一步，

至此，咱们专栏已用 4 篇文章分享了我关于“精进思维”这个主题的理解与思考，期待以后你能得心应手并游刃有余地持续进阶。。习惯的重要性想必你也很了然于胸了，习惯的养成，是让成长无意识自然发生的关键。然而习惯对于成长的具体作用是怎样的呢？想必你也知道，养成好的习惯能帮助我们更快地成长，而在所有的好习惯中，关于时间的习惯是其中的基础，我称之为 “基石” 习惯。如果你的时间习惯不好，那你做其他事情的效率往往也就不高。那么，该如何塑造好时间这块 “基石”呢？我觉得在有效地应用之前，先需要精确地感知与测量。