走出迷茫，在技术上持续精进

  感觉这篇文章写的很好，分享出来，原链接http://gitbook.cn/m/mazi/article/59434736475c5d0392016cb9?readArticle=yes。

作为开发者，工作了 2~3 年后，往往会感到迷茫：能够使用一种或者几种技术解决一些问题了，却觉得自己停滞了，不知道接下来怎么办。于是我们有时羡慕做管理的，觉得他们轻松、地位高、赚钱多，有时又羡慕技术大咖，觉得他们能搞定别人搞不定的问题，像神一样会发光，可是回看我们自己，到底是接着做技术呢，还是转管理呢？如果做技术，接下来该怎么精进，如果不做，又该怎么转型？这都是问题……每日煎熬着我们。

我有十几年的开发和管理经验，对于开发者的各种迷茫，深有体会。一般来看，开发者的迷茫分两个层面：

1. 方向上的迷茫，即我到底适不适合做开发、要不要继续在开发的路上走下去。

2. 执行层的迷惑，即我继续做开发，该怎么找目标、学点什么、学到什么程度、如何能一直精进。

我们的 Chat 就从这两方面来展开，先讲如何确认自己是否要继续做开发，这部分会提供一些方法（比如工作的三种分类、时间感觉、成就感来源、工作感受等），让大家能够自我觉知和判断；然后我们会沿着开发这条线继续前进，看看如何在技术上持续精进，这部分最重要的是对标管理法及其四种典型标杆；再接下来，我们会讲怎样设定有效目标，找到下一步行动，把精进落地；最后，我们会介绍四个习惯，让精进成为你自身的一部分。

我要继续做开发吗

有几种方法，可以帮助你判断要不要继续做开发：

1. 工作的三种维度。

2. 成就感来源。

3. 对时间的感受。

4. 对开发工作的感受。

工作的三种维度

根据交互对象不同，工作可分为三类：

• 数据和信息处理

• 人际互动

• 事务型操作

开发者偏重与数据和信息打交道，以信息和数据为输入，也以信息和数据为输出。

假如你发现自己更愿意围绕着人际交互来做事情，希望自己的工作中大部分时间都在和人打交道，那可能你更适合做销售、市场、客服、咨询师等方面的工作。

假如你发现自己更愿意做操作性的工作，比如修理电脑、组装电脑、搭建局域网、修理汽车等，那可能软件开发工作可能不太适合你。

假如你觉得信息很迷人，很享受与信息和数据之间这种确定性、一致性、可预期性较高的互动方式，也很享受通过组织、修改、整合、创造信息来解决问题这种工作方式，那你有比较大的概率是适合做开发的。我们可以继续往下看，用其它方法来继续分析自己。

成就感来源

2015 年底创业失败，我决定找一家单位上班。此时我 35 岁，在很多人眼里这个年龄的程序员已经要被淘汰了。我面临的选择是：做开发开始做管理。

从 2009 年开始我就在做技术管理工作，这时比较传统的做法是，找一个研发经理的职位来做（当时有几个不错的机会），一来职业生涯有延续性，而来薪水也高。可是我后来选择了到全时云商务做开发工作，让很多朋友大跌眼镜。

我为什么这么选择？其中的关键点是：我觉得亲力亲为解决问题更有成就感。

回顾我多年的开发和管理经历，我发现在我写作《Qt Quick核心编程》时，在我一周 7 天不休息加班加点重构智能机顶盒播放器时，感觉最为充实，最有意义感。而在我做管理工作时，即便带领团队完成了某项任务，我也没什么特别的感觉，即便有一些兴奋感和成就感，也很快会被委派任务、一对一谈话等事情淹没。

所以我思来想去，决定做回开发，这样我更能感受到意义和价值，更有成就感。

每个人的成就感来源都不一样，假如你像我一样，High 点在于自己动手解决具体的技术问题，那开发工作就更适合你；假如领导和管理别人完成目标让你更有快感，那管理工作适合你。

实际上这一点和前面介绍的“工作的三种分类”是类似的。你越倾向于做人际互动类的事情，就越适合做管理工作，你越倾向于和数据、信息交互，就越适合做开发工作。

寻找成就感来源可以遵循下面的步骤：

1. 回顾你做过的事情，找出那些让你情感反应强烈的，记录下来。

2. 分析你的情绪底色，是快乐、高兴、振奋、愉悦、充实等积极情绪，还是沮丧、灰心、挫败、失落、空虚、失望等消极情绪。

3. 挑选出带给你强烈积极感受的事件，它们就是你的成就感事件。

4. 分析成就感事件，看看它们用到了什么知识、技能、软能力，看看在这些事件中，你印象深刻的交互对象是什么（数据、人、事务）。

可能有的朋友会说，即便有这 4 个步骤，也判断不出来自己的成就感来自哪里，不怕，下面这个简洁的方法可以帮到你。

对时间的感受

做个小测试，用是和否来回答下面 3 个问题：

1. 写代码让你觉得时间很难熬，一秒犹如一万年。

2. 当你回顾一天、一周、一月的工作，经常后悔自己在开发上投入了太多的时间。

3. 你觉得花费在软件开发上的时间没有什么意义。

如果你的答案是三个“是”，那么，你可能不该再做开发了。如果是三个“否”，那么，再回答下面 3 个问题：

1. 写代码时有沉浸感，感觉不到时间流逝，被中断时经常有意犹未尽的感觉。

2. 当你回顾一天、一周、一月的工作，经常觉得自己应该在开发上投入了更多的时间。

3. 你觉得花费在软件开发上的时间非常值得。

如果你的答案是三个“是”，那么恭喜你，开发工作是你的最爱，继续做下去吧，跟随自己的感觉。你可以跳到“在技术上持续精进”那部分，接着阅读。

如果你的答案有“是”有“否”或者不太确定，再往下看。

对开发工作的感受

你可以用下面这些问题来探索自己对开发工作的感受：

1. 看到代码是否有“似曾相识燕归来”的温暖？

2. 隔一段时间不写代码，是否会充满怀念，有想打开 IDE 写点什么的冲动？

3. 是否经常有这样的时刻：看着自己的代码，有种“相看两不厌，唯有敬亭山”的喜悦？

4. 有没有那么一些时候，你看着自己的代码，会不自觉地想：这里或那里改改是不是更好一些？

5. 当你看到令人眼前一亮的 App 或网站或其它软件，会不会发出“要是我来做该怎么做”之类的问题？

6. 你有没有想让别人阅读你代码的冲动？

7. 你有没有读别人代码的冲动（想看到更好的代码）？

8. 别人指出 Bug、错误或设计瑕疵，你会生气、拒绝还是接纳感激？

9. 修复一个 Bug，你是为这个 Bug 被解决掉高兴多一些还是为你的代码（软件）更完美而高兴多一些？

10. 听到新语言、新框架、新系统、开发者大会等相关的消息，你是很想了解还是懒得搭理？

11. 有技术大咖在你身边出现时，想去结交还是懒得理他？

12. 看见别人的烂代码，你是吐糟真 TM 烂然后绕过还是想撸起袖子把它改好？

13. 看见别人的优秀代码，会不会羡慕，会不会想“要是我也能写出这么漂亮的代码就好了”？

14. 当你完成一个模块、功能、系统，解决一个问题时，是有“快感”、“成就感”还是有“终于交差了”的感觉？

15. 想到你开发的软件可以帮助别人解决问题带来好处你是否感到期待、兴奋？

16. 你是否想建立属于自己的软件资源（比如工具、类库）？

17. 你是不是像蜜蜂一样总是把看到的与软件相关的好东西收藏起来？

18. 为了可以继续做开发，你是否愿意忍受一些不愉快的事情，比如领导的批评、客户的抱怨、需求的变更？

思考这些问题，体会自己的感受。

完成这个练习，根据自己的感受，你就可以判断出来要不要继续做开发。

如果通过上面这些方法，综合分析之后，你发现自己更愿意在开发之路上前进，那 Ok ，咱们接着往下走，看看执行层面上我们该怎么做才能保持精进。

在技术上持续精进

在专业领域成长的一般模型如下图所示：

模型中有三个要素：

• 现状

• 目标

• 执行计划

每个人都可以评估自己的现状，我在做什么、用什么技术、技术达到了什么程度、拿多少薪水、什么职级、是否被领导认可、与人协作是否顺畅……有很多维度，静下心来思考一下，在纸上列一列，就能自己得出当下的状态。

而目标则很可能随着旧目标的达成而消失，或者随着日复一日的编码、Debug、交付而褪色，或者随着每个月的薪水蒸发掉。一旦我们失去了目标，就会陷入迷茫，被动工作，进而，慢慢失去竞争力。

所以，要想日有寸进，必须要在日常的开发工作中找到努力的目标。这非常关键——很多人就是因为没有目标而放任自己随波逐流被动工作最终变得庸常而被他人淹没或者被组织淘汰。

因此我们引入原本用于企业的对标管理法，帮助自己在日常工作中找到贴合自己的目标。一旦我们找到目标，对比现状，就可以找到差距和前进方向，有了方向，就可以制定计划，稳步前进，获得提升。

下图是实践对标管理法指导个人成长的基本过程：

以下解释来自百度百科：

对标管理，由美国施乐公司于 1979 年首创，均将其视为现代西方发达国家企业管理活动中支持企业不断改进和获得竞争优势的最重要的管理方式之一，西方管理学界将对标管理与企业再造、战略联盟一起并称为20世纪90年代三大管理方法。

对标管理是指企业以行业内或行业外的一流企业作为标杆，从各个方面与标杆企业进行比较、分析、判断，通过学习他人的先进经验来改善自身的不足，从而赶超标杆企业，不断追求优秀业绩的良性循环过程。

所谓“对标”就是对比标杆找差距。推行对标管理，就是要把企业的目光紧紧盯住业界最好水平，明确自身与业界最佳的差距，从而指明了工作的总体方向。

在针对个人运用对标管理法时，可以从四个方面来寻找标杆：

• 优秀的人

• 一般性规律

• 技术本身的知识层次

• 项目指标

接下来我们就从这四个方面展开，看看怎么寻找我们的目标。

从优秀者身上找目标

我们身边一定有人在某方面做得比自己好，比如：

• 张三设计文档写得结构合理、条理清晰

• 李四 UML 图表画得准确

• 王五对 ES6 标准掌握得好

• 赵六对代码管理门清

• 钱七架构设计能力超群对产品的架构如数家珍

• 毛八每天上班前都会列出要完成的三件事下班时都会总结

• 胡九学习新技术特别快总是在项目组中担任技术预研角色

• ……

别人做得好的方面，都可能是我们努力的方向。我们要用善于发现的眼睛，找到身边人的突出之处。

在向优秀者对标时，下面的问题清单可以帮助我们有序地、系统的分析标杆：

• 他在什么事情上做得突出？是怎么做到的？

• 他有哪些知识、技能是我不具备的？

• 他有哪些提升效率的工具？

• 他有哪些好的工作习惯？

举个例子。

袁大每天都能准时下班，工作还完成的蛮好。你对这点很感兴趣，就观察他做事，发现他过一段时间就会翻看一下纸质笔记本，或者用笔在本子上记录点什么，还有，每天下班的时候，他都会在本子上写点东西。

于是你就跟他聊天，发现他每天下班都会在笔记本上记录今天完成了什么、遇到了什么问题、明天做什么。还了解到他每天都会早到半个小时左右，利用这半个小时规划一天的工作。

后来你明白了，袁大培养了一个“早规划晚回顾”的工作习惯，通过这个习惯，保证每天都有几件重要的事可做，每天都有目标，有节奏，这样就可以不慌不忙的工作。

于是你就会思考：袁大的习惯可以不可成为我的习惯？

这个时候，你就找到了一个提升的方向：培养每日完成三件事的习惯。一旦你养成这个习惯，习惯的力量就会帮助你集腋成裘，完成从量变到质变的过程。

再举个例子。

你发现组里的袁二，排查 Bug 特别厉害，像一休哥一样，点点头沉思一下，就可以说出问题所在的地方。即便是别人代码引入的 Bug ，他也可以很快找到原因——只需要翻翻代码，和这个人聊几句。

为什么袁二这么牛？

你向他请教，发现他做到了以下几点：

1. 对业务特别熟悉，非常清楚某个业务到底是什么，用户在软件上怎么使用这个业务。

2. 对业务逻辑和代码的映射关系特别熟。

3. 爱看代码，所有人的代码都看。

好啦，正好你总是被 Bug 困扰，往往一个 Bug 能让你愁烦一个星期，是不是有努力方向啦？

一般性规律

所谓一般性规律，指的是那些通用的，可以指导我们什么时候做什么事情的规律。

举个例子，舒伯的生涯发展阶段理论就是一般性规律，男大当婚女大当嫁也是一般性规律。

对于开发者来讲，要关注专业能力成长的一般性规律，即：技术成长三阶段。如下图所示：

在技术领域内的成长，基本上都会经历三个阶段：

1. 专项能力的提升，这是初级阶段，你为了做事情，必须先具备某些基础能力，比如你要学会 Python、Visual Studio、Vue、TensorFlow 、Mybatis 等。

2. 技能体系的构建，这是中级阶段，你拥有了一组技能，围绕某个方向构建了自己的知识图谱，能够用自己的方式来解决问题。比如在C++这个方向上，你用 C++、Qt、OpenGL、libevent、ffmpeg、WebRTC 等组成了自己的知识图谱，可以胜任流媒体方面的产品开发。

3. 融合创新，这是高手阶段，你具有了丰富的实践经验，具备了 T 型知识结构，形成了自己的思维框架和解决问题的框架，能够融合不同领域的知识，组合各种资源，创造性的解决各种问题。此时你跳出了具体的技术束缚，站在了更高的层面，用底层认知和思维来指导你的工作。

对开发者来讲，一年左右经验，多数人处在第一个阶段——专项能力提升的阶段，熟悉某种编程语言，可以完成别人安排的一个小模块的开发。

三年及以上的经验，就应该进入到第二个阶段了。当你在某个技术方向上构建了技能体系，就可以完成相对复杂的工作，可以独立的做一些事情，甚至可以辅导初级开发者来完成工作。这个时候，你往往已经是团队里富有生产力的成员了。

五年往上的开发经验，应该进入到融合创新阶段，能够独当一面，可以独立的完成特定项目的评估、设计、技术方案选择等事情。此时你往往是团队里的技术领袖或者技术管理者，具有比较大的影响力。

假如一个开发者干上八年十年，还到不了第 3 个阶段，可能就需要考虑通过其他方式来提升自己的竞争力，保住自己在团队中的位置。

这个模型更适合应用开发人员，对于做基础研究的开发者，比如音频算法、图像处理算法等，第三个阶段，可能是在他所在的领域内钻得更深，成为专家。

我们了解了技术成长的三个阶段，就可以结合自己的工作情况，判断自己当下处于哪个阶段，该做什么事情。

比如你做了 2 年 PHP 开发，可能你处于从第 1 阶段向第 2 阶段转型的过程中，此时提升的方向，就可以考虑和PHP相关的技术栈，比如了解 HTTP 服务器如何和PHP整合在一起，比如了解数据库，比如了解操作系统，这样你就可能会定下掌握 LAMP （Linux/Apache/MySQL/PHP）或者 LNMP（Linux/Nginx/MySQL/PHP） 技术栈的目标。

技术本身的知识层次

一门编程语言、一个技术框架，其本身的知识层次，也会有深浅，在学习时，也存在先后顺序和一般性规律。从这个角度上讲，技术本身的深浅层次，也可以用于个人对标管理。

一般来讲，学习一门技术时，有三个阶段：

1. 基础开发，了解 API，基 于API 开发应用。

2. 熟悉内核及原理，主要是了解框架的设计原理，阅读源码，洞悉内在机理。

3. 优化框架，主要是针对框架的已有功能的不足进行完善、优化，或者使用框架提供的机制扩展框架功能，或者对框架进行定制，让它适合特定情境。

我比较熟悉 Qt ，Qt 这个应用开发框架，三阶段的划分可能是这样：

多数技术框架，通过分析，都可以划分出类似上面的知识层次和学习阶段。

以这个作为对标的标杆，就可以弄明白每个阶段应该达到什么程度，还可以定位自己处在哪个阶段，当前阶段的任务有没有完成，接下来该该学什么。

项目指标

开发者的工作往往是由一个又一个的项目串起来的，每个项目都会有预期结果，都会界定怎么样才算是完成，然后会有一系列的指标用于衡量项目做得怎么样，比 如 Bug 率、延期时间、并发用户数、持续运行时间、单元测试覆盖率、安全性等。

我们在做项目时，就可以用这些指标来要求自己，这样你每个项目都有目标，都可以制定一些策略，帮助自己来实现这些目标。

很多开发者其实不大关心交付时间、Bug率、冒烟测试通过率、并发用户支持、内存占用、CPU占用、电池消耗等问题，往往是做完了，能跑，就这样吧。

以这样的态度来应付开发任务，其实损失最大的是自己，因为你白白失去了锻炼和提升的大好机会。

如果我们以项目指标来要求自己，把项目指标分解到开发工作中，并且在开发过程中贯彻执行，我们的收获一定比被动完成任务多得多。

举个简单的例子，你用 Java 开发一个电商类的 Android App，内存占用就应当是你关心的一个指标，否则你的应用就会经常出现 OOM 错误，严重损害用户体验，导致用户大量卸载，最终影响产品的市场。

如果你把内存占用作为重点考虑的指标，你一定会考虑如何使用图片预缩放、重用、解码格式、缓存等策略来优化内存占用，甚至你会自己设计一个图片缓存池或者特殊的 ListView 来专门处理用户快速浏览商品时巨大的内存消耗。

你有了这样的考虑，做出来的 App 肯定比你从未考虑过内存占用问题而稳定得多。

目标的设定与执行

当我们运用个人对标管理法从人、规律、技术、项目等四个方面找到目标后，还要仔细地考虑两个问题：

• 这个目标适合我吗？

• 如何完成这个目标？

适合性评估

先来看看如何判断某个目标是不是适合我。两方面：

1. 这个目标和我的职业规划是不是一致？

2. 这个目标和我当下的工作是不是可以关联起来？

你所在的团队里有位什么都可以搞定的全栈工程师，你非常羡慕这样的人，用对标管理法对他做了分析，发现他的知识图谱包括HTML、JavaScript、CSS、AngularJS、Node.js、MySQL、Redis、C++等，那么，接下来，你要把他的技能树作为你的目标吗？

假如你也想成为一个全栈工程师，那 Ok ，你跟着他学习 JavaScript 前后端开发没有问题；假如你的目标是成为 WebRTC 领域的专家，那么，他的技术栈，对你几乎没什么帮助，参考意义不大。

我们在运用个人对标管理法时，一定要理性，结合自己的长远目标，否则就会今天想学这个明天想学那个，久而久之什么也没学透。

如何完成目标

当你选定了与你相关的某个目标，如何完成？两个关键点：

• 目标必须是有效的。

• 找到下一步行动。

有效目标

首先你要确保你选择的目标是有效的，符合SMART原则：

• S（Specific）：目标必须是具体的，要对标特定的工作指标，不能笼统。比如我要学会前端开发就不具体，而“我要学会 HTML5 、Angular 4、Bootstrap 3，用它们做Web管理界面”就相对具体。

• M（Measurable）：目标必须是可衡量的，衡量的指标是数量化或者行为化的，验证这些指标的数据或者信息是可以获取的；比如“ Bug 率控制在千分之三以内”就是可衡量的，而软件没问题就是非常模糊的说法。

• A（Attainable）：目标必须是可实现的，在付出努力的情况下可以实现；比如“在两周内学会 HTML5 、Angular 4、Bootstrap 3”就是不太现实的。

• R（Relevant）：与其他目标有一定的相关性，比如你把代码规范化作为你的提升目标，就和你日常的开发工作有很强的关联性。

• T（Time-bound）：目标必须有明确的截止期限。必须的！没有期限，就没有目标！

一个有效目标示例：

在三个月内学会 HTML5 、Angular 4、Bootstrap 3，然后用一个月时间，采用 SPA（Single Page Application） 方式，开发清单 App 的 Web 版本，支持登陆登出、任务增删改、分组增删改功能，Bug 率控制在千分之三。

下一步行动

单单拥有有效目标，还不够，我们还要找到可以立即开始的下一步行动！

所谓“下一步行动”，就是某一件事情的下一个可以直接去做的步骤。

《小强升职记》中介绍了撰写下一步行动的四个秘诀：

• 动词开头。一个好的行动应该是以动词开头的，比如“打电话给某某”、“准备会议资料”、“回复E-mail”等，以动词开头才能保证它具备可执行性。

• 内容清晰。比如“准备会议资料”，虽然是动词开头，但是描述得不是很清晰，“需要准备哪些资料”、“几点开会”、“会议上要提出什么问题”，这些都需要进一步落实。所以说这样的下一步行动是失败的。

• 描述结果。在任务开始之前对想要的结果进行描述，描述得越清晰，产生的能量就越大。比如你这样：“早晨9点带着做好的计划书在1号会议室讨论营销计划，说服与会者认同我的营销方案。”

• 设定开始时间、周期、最后期限。在设定了这三个和时间有关的属性之后，就可以更合理地安排自己的时间，把握行动的进度，照顾别人的时间。

如果你能够按照上述四个秘诀来拟定“下一步行动”，就有 90% 的可能找到“可执行的下一步”。所谓“可执行的下一步”，往往是简单到你只需要迈出右脚就行了。假如你还要考虑到底是迈右脚还是迈左脚，就说明你的下一步存在未决因素，不能立刻开始。

下面是几个下一步行动：

1. 找到 AngularJS 的官网

2. 买一本讲 AngularJS 开发的书籍

3. 买一本 JavaScript 的书

4. 2 个小时完成 Node.js 下载与安装

当你能从目标分解出能够立刻开始的下一步行动序列（最少3个），就可以做起来。做完一个，分解一个新的下一步行动，加入到行动序列中，然后开始新的下一步行动。这样跑起来，你的目标就会稳步实现。

精进的四个习惯

习惯是很强大的力量，要把精进落实到日常习惯中。我个人有这四个习惯，供参考：

• 对标管理

• 三个问题

• 刻意练习

• 复盘

对标管理

前面我们仔细介绍了个人对标管理法的运用，它应该成为我们的习惯，成为习惯后，我们就可以自发地运用它，随时找到前进方向。

三个问题

参考《Scrum实战——敏捷软件项目管理与开发》

在 SCRUM 开发模型中，有个每日站会。每日站会一般早上开，站着开（坐下来会让会议变长），10 到 15 分钟。在每日站会上，每个人都要回答三个问题：

1. 我昨天完成了什么

2. 我遇到了哪些问题

3. 我今天做什么

回答完这三个问题，就可以更新看板上的任务状态，别人也都能了解到你的状态，如果有需要配合的，也都可以即时做出决定。

这三个问题，不仅仅可用于开发过程，还可以演化成个人的工作习惯，指导我们每天的工作。

我是这么用的：

1. 每天晚上下班时记录完成了什么、遇到了什么问题、明天准备做什么。记录在纸质的笔记本上。

2. 每天早上正式开始工作前，审视昨天记录的内容，决定今天要做哪几件事（最好不要超过三件），今天就聚焦在这些事情上。

非常简单的，但是好用。坚持这么做，你的工作就会越来越高效、轻松。最重要的是，你会知道你每天都有成就，不会焦虑和恐慌。