技术进步的逻辑

要想成为技术大牛，
首先还是 要明白“主要靠自己”这个道理，不要期望有个像武功师傅一样的大牛手把手一步一步地教你。适当的时候可以通过请教大牛或者和大牛探讨来提升自己，但大部分时间 还是自己系统性、有针对性的提升

业务代码一样可以很牛逼

有人认为写业务代码一样可以很牛逼，理由是业务代码一样可以有各种技巧，例如可以使用封装和抽象使得业务代码更具可扩展性，可以通过和产品多交流以便更好的理解和实现业务，日志记录好了问题定位效率可以提升 10 倍等等。业务代码一样有技术含量，这点是肯定的，业务代码中的技术是每个程序员的基础，但只是掌握了这些技巧，并不能成为技术大牛，就像游戏中升级打怪一样，开始打小怪，经验值很高，越到后面经验值越少，打小怪已经不能提升经验值了，这个时候就需要打一些更高级的怪，刷一些有挑战的副本了，没看到哪个游戏只要一直打小怪就能升到顶级的。成为技术大牛的路也是类似的，你要不断的提升自己的水平，然后面临更大的挑战，通过应对这些挑战从而使自己水平更上一级，然后如此往复，最终达到技术大牛甚至业界大牛的境界，写业务代码只是这个打怪升级路上的一个挑战而已，而且我认为是比较初级的一个挑战。

所以我认为：业务代码都写不好的程序员肯定无法成为技术大牛，但只把业务代码写好的程序员也还不能成为技术大牛。

最大的误区：上班太忙没时间自己学习
很多人认为自己没有成为技术大牛并不是自己不聪明，也不是自己不努力，而是中国的这个环境下，技术人员加班都太多了，导致自己没有额外的时间进行学习。这个理由有一定的客观性，毕竟和欧美相比，我们的加班确实要多一些，但这个因素只是一个需要克服的问题，并不是不可逾越的鸿沟，毕竟我们身边还是有那么多的大牛也是在中国这个环境成长起来的。

我认为有几个误区导致了这种看法的形成：

1. 1）上班做的都是重复工作，要想提升必须自己额外去学习 形成这个误区的
2. 主要原因还是在于认为“写业务代码是没有技术含量的”，而我学习需要大段的连续时间 很多人以为要学习就要像学校上课一样，给你一整天时间来上课才算学习，而我 们平时加班又比较多，周末累的只想睡懒觉，或者只想去看看电影打打游戏来放松， 所以就没有时间学习了。

实际上的做法正好相反：

**首先我们应该在工作中学习和提升，因为学以致用或者有实例参考，学习的效果是最好的； 其次工作后学习不需要大段时间，而是要挤出时 间，利用时间碎片来学习**。

正确的做法

Do more
做的更多，做的比你主管安排给你的任务更多。
我在 HW 的时候，负责一个版本的开发，这个版本的工作量大约是 2000 行左右，但是我除了做完这个功能，还将关联的功能全部掌握清楚了，代码（大约 10000行）也全部看了一遍，做完这个版本后，我对这个版本相关的整套业务全部很熟悉了。经过一两次会议后，大家发现我对这块掌握最熟了，接下来就有趣了：产品讨论需求找我、测试有问题也找我、老大对外支撑也找我；后来，不是我负责的功能他们也找我，即使我当时不知道，我也会看代码或者找文档帮他们回答。最后我就成了我这个系统的“专家”了。虽然这个时候我还是做业务的，还是写业务代码，但是我已经对整个业务都很熟悉了。
以上只是一个简单的例子，

其实就是想说：要想有机会，首先你得从人群中冒出 来，要想冒出来，
你就必须做到与众不同，要做到与众不同，你就要做得更多！
怎么做得更多呢？

可以从以下几个方面着手：
1）熟悉更多业务，
不管是不是你负责的；熟悉更多代码，不管是不是你写的这样做有很多好处，
举几个简单的例子：
● 需求分析的时候更加准确，能够在需求阶段就识别风险、影响、难点
● 问题处理的时候更加快速，因为相关的业务和代码都熟悉，能够快速的判断问
题可能的原因并进行排查处理
● 方案设计的时候考虑更加周全，由于有对全局业务的理解，能够设计出更好的方案

2）熟悉端到端

比如说你负责 web 后台开发，但实际上用户发起一个 http 请求，要经过很多中间步骤才到你的服务器（例如浏览器缓存、DNS、nginx 等），服务器一般又会经过很多处理才到你写的那部分代码（路由、权限等）这整个流程中的很多系统或者步骤，绝大部分人是不可能去参与写代码的，但掌握了这些知识对你的综合水平有很大作用，例如方案设计、线上故障处理这些更加有含金量的技术工作都需要综合技术水平。

“系统性”、“全局性”、“综合性”这些字眼看起来比较虚，但其实都是技术大牛的必备的素质，要达到这样的境界，必须去熟悉更多系统、业务、代码。

3）自学

一般在比较成熟的团队，由于框架或者组件已经进行了大量的封装，写业务代码所用到的技术确实也比较少，但我们要明白“唯一不变的只有变化”，框架有可能要改进，组件可能要替换，或者你换了一家公司，新公司既没有组件也没有框架，要你从头开始来做。这些都是机会，也是挑战，而机会和挑战只会分配给有准备的人， 所以这种情况下我们更加需要自学更多东西，因为真正等到要用的时候再来学已经没有时间了。

自学什么呢？以 java 为例

大部分业务代码就是 if-else 加个数据库操作，但我们完全可以 自己学些更多 java的知识，例如垃圾回收，调优，网络编程等，这些可能暂时没用， 但真要用的时候，不是 google一下就可以了，这个时候谁已经掌握了相关知识和技 能，机会就是谁的。以垃圾回收为例，我自己平时就抽时间学习了这些知识，学了 1年都没用上，但后来用上了几次，每次都解决了卡死的大问题，而有的同学，写了几年的 java 代码， 对于 stop-the-world 是什么概念都不知道，更不用说去优化了

Do better

要知道这个世界上没有完美的东西，你负责的系统和业务，总有不合理和可以改进的地方，这些“不合理”和“可改进”的地方，都是更高级别的怪物，打完后能够增加更多的经验值。识别出这些地方，并且给出解决方案，然后向主管提出，一次不行两次，多提几次，只要有一次落地了，这就是你的机会。

例如：

1. 重复代码太多，是否可以引入设计模式？
2. 系统性能一般，可否进行优化？
3. 目前是单机，如果做成双机是否更好？
4. 目前的系统太庞大，是否可以通过重构和解耦改为 3 个系统？
5. 只要你去想，其实总能发现可以改进的地方的；
6. 如果你觉得系统哪里都没有改进的地方，那就说明你的水平还不够，可以多学习相关技术；
7. 多看看业界其它优秀公司怎么做。

我 2013 年调配到九游，刚开始接手了一个简单的后台系统，每天就是配合前台做数据增删改查，看起来完全没意思，是吧？如果只做这些确实没意思，但我们接手后做了很多事情：
● 解耦，将一个后台拆分为 2 个后台，提升可扩展性和稳定性；
● 双机，将单机改为双机系统，提高可靠性；
● 优化，将原来一个耗时 5 小时的接口优化为耗时 5 分钟
还有其它很多优化，后来我们这个组承担了更多的系统，后来这个小组 5 个人，负责了 6 个系统。

重点：Do exercise 这个很重要，也是最难去执行的

在做职业等级沟通的时候，发现有很多同学确实也在尝试 Do more、Do better，但在执行的过程中，几乎每个人都遇到同一个问题：光看不用效果很差，怎么办？

例如：
● 学习了 jvm 的垃圾回收，但是线上比较少出现 FGC 导致的卡顿问题，就算出
现了，恢复业务也是第一位的，不太可能线上出现问题然后让每个同学都去练
一下手，那怎么去实践这些 jvm 的知识和技能呢？
● Netty 我也看了，也了解了 Reactor 的原理，但是我不可能参与 Netty 开发，
怎么去让自己真正掌握 Reactor 异步模式呢？
● 看了《高性能 MySQL》，但是线上的数据库都是 DBA 管理的，测试环境的数
据库感觉又是随便配置的，我怎么去验证这些技术呢？
● 框架封装了 DAL 层，数据库的访问我们都不需要操心，我们怎么去了解分库
分表实现？

诸如此类问题还有很多，我这里分享一下个人的经验，其实就是 3 个词： learning、trying、teaching ！

1）Learning

这个是第一阶段，看书、google、看视频、看别人的博客都可以，但要注意一点是“系统化”，特别是一些基础性的东西，例如 JVM 原理、Java 编程、网络编程，HTTP 协议等等，这些基础技术不能只通过 google 或者博客学习，我的做法一般是先完整的看完一本书或者一套视频全面的了解，然后再通过 google、视频、博客去有针对性的查找一些有疑问的地方，或者一些技巧。

2）Trying

这个步骤就是解答前面提到的很多同学的疑惑的关键点，形象来说就是“自己动
手丰衣足食”，也就是自己去尝试搭建一些模拟环境，自己写一些测试程序。例如：
● Jvm 垃圾回收：可以自己写一个简单的测试程序，分配内存不释放，然后调整
各种 jvm 启动参数，再运行的过程中使用 jstack、jstat 等命令查看 jvm 的堆
内存分布和垃圾回收情况。这样的程序写起来很简单，简单一点的就几行，复
杂一点的也就几十行。
● Reactor 原理：自己真正去尝试写一个 Reactor 模式的 Demo，不要以为这
个很难，最简单的 Reactor 模式代码量（包括注释）不超过 200 行（可以参考Doug Lee 的 PPT）。自己写完后，再去看看 netty 怎么做，一对比理解就更加深刻了。

● MySQL：既然有线上的配置可以参考，那可以直接让 DBA 将线上配置发给我
们（注意去掉敏感信息），直接学习；然后自己搭建一个 MySQL 环境，用线上
的配置启动；要知道很多同学用了很多年 MySQL，但是连个简单的 MySQL
环境都搭不起来。

● 框架封装了 DAL 层：可以自己用 JDBC 尝试去写一个分库分表的简单实现，
然后与框架的实现进行对比，看看差异在哪里。

● 用浏览器的工具查看 HTTP 缓存实现，看看不同种类的网站，不同类型的资
源，具体是如何控制缓存的；也可以自己用 Python 写一个简单的 HTTP 服务
器，模拟返回各种 HTTP Headers 来观察浏览器的反应。

还有很多方法，这里就不一一列举，简单来说，就是要将学到的东西真正试 试，才能理解更加深刻，而且“试试”其实可以比较简单，很多时候 我们都可以自己动手做。

当然，如果能够在实际工作中使用，效果会更好，毕竟实际的线上环境和业务复
杂度不是我们写个模拟程序就能够模拟的，但这样的机会可遇不可求，大部分情况我
们还真的只能靠自己模拟，然后等到真正业务要用的时候，能够信手拈来。

3）Teaching

一般来说，经过 Learning 和 Trying，能掌握 70% 左右，但要真正掌握，我觉
得一定要做到能够跟别人讲清楚。因为在讲的时候，我们既需要将一个知识点系统
化，也需要考虑各种细节，这会促使我们进一步思考和学习。同时，讲出来后看或者听
的人可以有不同的理解，或者有新的补充，这相当于继续完善了整个知识技能体系。

这样的例子很多，包括我自己写博客的时候经常遇到，本来我觉得自己已经掌
握很全面了，但一写就发现很多点没考虑到；组内培训的时候也经常看到，有的同学
写了 PPT，但是讲的时候，大家一问，或者一讨论，就会发现很多点还没有讲清楚，
或者有的点其实是理解错了。写 PPT、讲 PPT、讨论 PPT，这个流程全部走一遍，
基本上对一个知识点掌握就比较全面了。

后记

成为技术大牛梦想虽然很美好，但是要付出很多，不管是 Do more 还是 Do better 还是 Doexercise，都需要花费时间和精力，这个过程中可能很苦逼，也可能 很枯燥，

这里我想特别强调一下：前面我讲的都是一些方法论的东西，但真正起决定作用的，

其实还是我们对技术的热情和兴趣！

总结： 平时碰到问题 要深入研究 ，然后 反复反复反复 总结 ，找到问题的本质。

Linux下查看/管理当前登录用户及用户操作历史记录
http://www.cnblogs.com/gaojun/p/3385885.html

通用知识 一定要掌握好

为什么你的知识积累不了？

有些知识看过就忘、忘了再看，实际碰到问题还是联系不上这个知识点。这其实是知识的积累出了问题，没有深入理解好，自然就不能灵活运用，也就谈不上解决问题。大家一起看相同的高考教科书但是高考结果不一样，问题出在了理解上。每个人的理解能力不一样（智商），绝大多数人对知识的理解要靠不断地实践（做题）来巩固。

为什么同样实践，效果不一样？

同样工作一年碰到了 10 个问题（或者说做了 10 套高考模拟试卷），但是结果不一样，那是因为在实践过程中方法不够好。或者说你对你为什么做对了，为什么做错了，没有去复盘。

假如碰到一个问题，身边的同事解决了，而我解决不了。那么我就去想这个问题他是怎么解决的，他看到这个问题后的逻辑和思考是怎么样的？有哪些知识指导了他这么逻辑推理，这些知识哪些是我也知道但是我没有想到这么去运用推理的（说明我对这个知识理解得不到位导致缺乏灵活运用）；这些知识中又有哪些是我不知道的 （知识缺乏，没什么好说的，快去搜索学习下——有场景案例和目的加持，学习理解起来更快）。

等你基本把这个问题按照你同事掌握的知识和逻辑推理想明白后，需要再去琢磨一下他的逻辑推理、解题思路中有没有不对的，有没有啰嗦的地方，有没有更直接的方式（对知识更好地运用）。

我相信每个问题都这么去实践的话就不会再有抱怨。灵活运用、举一反三，同时知识也积累下来了，这种场景下积累到的知识是不会那么容易忘记的。这就是向身边的牛人学习，同时很快超过他的办法。这就是为什么高考前你做了10 套模拟题还不如其他人做一套的效果好。

知识 + 逻辑就基本等于你的能力

知识让你知道那个东西，逻辑让你把东西和问题联系起来。这里的问题你可以理解成方案、架构、设计等。

系统化的知识哪里来？

知识之间是可以联系起来的并且像一颗大树一样自我生长，但是当你都没理解透彻，自然没法产生联系，也就不能够自我生长了。当我们讲到入门了某块知识的时候，一般是指对关键问题的点理解清晰，并且能够自我生长，也就如滚雪球一样可以滚起来了。

那么，好的逻辑又怎么来？ 有两个很好的方法，一是不断实践，然后再加以复盘

● 实践
● 复盘

讲个前同事的故事

我有一个前同事，所有解决不了的问题都找他。这位同学让我最佩服的是解决问题的能力，好多问题其实他也不一定擅长，但是他就是有本事通过 Help、Google 不停地验证、尝试就把一个不熟悉的问题给解决了，这是我最羡慕的能力，在后面的职业生涯中一直不停地往这个方面尝试。

应用刚启动连接到数据库的时候比较慢，但又不是慢查询

1. 这位同学的解决办法是通过 tcpdump 来分析网络通讯包，看具体卡在哪里把 这个问题硬生生地给找到了。
2. 如果是专业的 DBA 可能会通过 show processlist 看具体连接在做什么？比 如看到这些连接状态是authentication 状态，然后再通过 Google 或者对这 个状态的理解知道创建连接的时候 MySQL 需要反查
   IP、域名，这里比较耗 时，通过配置参数 skip-name-resolve 跳过去就好了。

3 如果是 MySQL 的老司机，一上来就知道 skip-name-resolve 这个参数要 改改默认值。

在我眼里这三种方式都解决了问题，最后一种最快但是纯靠积累和经验，换个问题也许就不灵了；第一种方式是最牛逼和通用，只需要最少的业务知识。

我当时跟着他从 sudo、ls 等 linux 命令开始学起。当然我不会轻易去打搅他、问他，每次碰到问题我尽量让他在我的电脑上来操作，解决后我再自己复盘， 通过history 调出他的所有操作记录，看他在我的电脑上用 Google 搜啥了，然后一个个去学习分析他每个动作，去想他为什么搜这个关键字，复盘完还有不懂的再到他面前，跟他面对面地讨论他为什么要这么做，知道他这么做的知识和逻辑又是什么。

空洞的口号
很多文章都会教大家：举一反三、灵活运用、活学活用、多做多练。但是只有这些口号是没法落地的，落地的基本原则就是前面提到的，却总是被忽视了。

什么是工程效率，什么是知识效率

有些人纯看理论就能掌握好一门技能，还能举一反三，这是知识效率，这种人非常少。

大多数普通人都是看点知识，然后结合实践来强化理论，要经过反反复复才能比较好地掌握一个知识，这就是工程效率，讲究技巧、工具来达到目的。

肯定是知识效率最牛逼，但是拥有这种技能的人毕竟非常少（天生的高智商吧）。从小我们周边那种不怎么学的学霸型基本都是这类，这种学霸都还能触类旁通非常快地掌握一个新知识，非常气人。剩下的绝大部分只能拼时间 + 方法 + 总结等，也能掌握一些知识。

非常遗憾我就是工程效率型，只能羡慕那些知识效率型的学霸。但是这事又不能独立看待，有些人在某些方向上是工程效率型，有些方向就又是知识效率型（有一种知识效率型是你掌握的实在太多，也就比较容易触类旁通了，这算灰色知识效率型。）

使劲挖掘自己在知识效率型方面的能力吧，两者之间当然没有明显的界限，知识积累多了，逻辑训练好了，在别人看来你的智商就高了。

知识分两种

一种是通用知识（不是说对所有人通用，而是说在一个专业领域去到哪个公司都能通用），另外一种是跟业务公司绑定的特定知识。

通用知识没有任何疑问，碰到后要非常饥渴地扑上去掌握他们（受益终生，这还有什么疑问吗？）。对于特定知识就要看你对业务需要掌握的深度了，肯定也是需要掌握一些的，特定知识掌握得好的，一般在公司里混得也会比较好。

因此，我也问了一些问题：

● 你希望技术能进一步积累，那你积累的方向和期望达到的结果分别是啥？
● 你希望能有技术决策，希望有影响力，你觉得应该如何做到？是希望通过岗位任命的方式吗？
● 你觉得是否成功的标志，就是今年或明年得到晋升吗？
● 等等

大部分同学在面对这些问题时，其实是比较迷茫的，也缺少真正可度量的衡量标准。是否能在短期内获得晋升成了大部分人作为“组织是否认可、自己是否认可”的衡量标准了。

当然，这个话题仁者见仁、智者见智，这里我简单地谈谈我的看法。我以相对比较口水化的方式，

将职业发展分两个阶段来进行阐述：

1）第一阶段：大学毕业 3 到 5 年
2）第二阶段：大学毕业 5 到 10 年

第一阶段：大学毕业 3 到 5 年

对于从事 Java 软件开发的技术同学，在毕业后的 3 到 5 年内主要都是以学习、积累为主。这个阶段的工作几乎每天都有惊喜，都有收获。从一开始啥都不懂的校园“新鲜人”向“职业人”转变。在这个阶段，你会学习：

● 基础的 Java 知识：你会开始看《Java 编程思想》、《Effective Java》。
● 高质量代码进阶知识：你会开始看《重构：改善既有代码的设计》、《代码大全》、《编程珠玑》。
● 常用的主流框架：比如 SSH 相关的《Spring 实战》、《Spring Boot 实战》、《Hibernate 实战 ( 第 2 版)》。

当然，这些书已经不够了，你会通过 Google、Baidu 大量地浏览在线的资源：Apache 官网、Spring 官网、Hibernate 官网。你会去 StackOverflow 问问题或找答案。

● 系统设计与算法知识：《系统分析与设计方法》、《设计模式》、《需求分析与系统设计》、《面向对象分析与设计》、《UML 用户指南》、《算法导论》

● 其他知识：比如数据库调优、缓存框架、NoSQL 数据库、日志框架等等

在这 5 年间，快速地完成这些基础知识的学习，并能在项目中快速地学以致用。不仅自身能获得比较高的成就感，而且实际的用人单位、猎头也会非常喜欢这类熟练工。

从大部分人的实际发展轨迹看，这个阶段发展快的人和正常发展速度的人，差别还不是很大。比如，发展非常快的人，从毕业就入职阿里的 P5 到 P7（注：阿里内部职称评级），可能三年就可以做到。发展速度正常的人，可能需要 5-6 年也可以到 P7。也就是说，这个阶段正常发展速度的同学也仅仅比发展速度快的人慢 2-3 年而已。这 2 到 3 年的差距，是可以通过有针对性的学习、重大项目的历练等完成这些知识的学习。无非是，有的同学会严格要求自己，有严格的学习计划；**有的同学赶早参加了一些重点的、痛苦的项目得到了锻炼。**只要是做技术的，其实迟早都会经历过，都会成长起来。

发现没有？这个阶段，我们能协调好的资源其实就是自己，更多的是一个“个人贡献者”。只要把自己管好了，学习计划执行好了，工作高质量做好了就能得到认可。

第二阶段：大学毕业 5 到 10 年

很多本科同学，特别是研究生同学。在毕业 10 年后，就已经到了 34、35 岁左右了。也是前段时间网上广泛讨论的所谓 34+ 岁现象。其实，年龄并不是问题的真正原因。真正的原因还是在于自身“竞争力”是否符合这个年龄所应该具备的。到了这个年龄的人，往往已经不是“个人贡献者”了，而是“团队贡献者”。团队贡献者可能是带团队的 TL，也可能是个架构师，在技术决策上具有团队影响力和话语权。

那么，为什么这些人能管理团队或者有影响力呢？ TL 是 TeamLeader的缩写

从公司的经营视角看，一个管理团队的人，他必须为业务的成功负责。说个大白话，一个 TL 管了 N 个人，他至少要能保证大家输出所产生的价值，至少要高于这个团队的工资、奖金、五险一金、OPEX、CAPEX 等等吧。这个 TL 为了大家输出得有价值，他是不是需要能：

● 能对所负责领域的业务特点、发展趋势、友商竞争分析有很好的洞察？能知道这个业务领域的客户是谁？他们的需求是什么？他们的痛点是什么？所以，这个 TL 应该需要学习《咨询的奥秘》、《探索需求》、《系统化思维导论》。对于技术型的 TL，还应该了解《成为技术领导者：掌握全面解决问题的方法》。

● 服务于特定领域的客户，我们需要能了解我们的客户企业架构、业务知识。要了解清楚规划的产品、服务，什么才是客户所需要的。那么，从理论上，我们是否应该学习一些 TOGAF、NGOSS、ITIL 等业务理论以及业务知识？

● 作为 TL， 是否有必要能将自己对于市场的洞察转换成业务规划，并能向自己的老板（或者投资人）说清楚、讲明白？并争取到老板的同意，包括资金、人力资源等。对于，能否把事情讲明白，我们可能需要学习《**金字塔原理》，并能非常清晰、有逻辑性地进行表达与沟通。**当然，有些业务发展的事不一定特别有逻辑，是需要摸索、尝试，那么你是否能将一个不确定的领域说服老板并获得支持，我们又需要什么？《博弈论》、《影响力》等。

● 获得老板支持后，就需要开始带着兄弟们干活了。作为带头人，你看我们是否需要能将业务趋势、客户痛点进行业务建模好让团队的 PD、技术都能理解？在做业务进一步深入分析，可能就需要学习《领域驱动设计 : 软件核心复杂性应对之道》、《实现领域驱动设计》、《企业应用架构模式》、《恰如其分的软件架构》等等。

● 做完业务设计后，开始要带着团队做技术方案设计、接口设计以及编码实现等。这个过程，TL 又需要具备软件项目管理的能力。无论是《PMBOK 指南》，还是《敏捷软件开发》、《人月神话》、《程序开发心理学》，相信总归还是会有点帮助的。

● 对于一些有国际化要求的公司，还需要再学习英语吧！
● 嗯，还需要有个好的身体，还需要经常锻炼，学习科学的健身吧（说起来自己脸红）。至少我明白了一个道理，以前我都是跟自己说，等这段时间过了，闲下来去锻炼一下。其实，我发现，越是忙的时候，越需要锻炼身体！

● 另外，在这 10 年内，比较关键的是——你还经历过什么有挑战的业务、技术、产品、平台等方面的成功与失败经验？在这些经历里，你可能会遇到这些困难与挑战：团队磨合的挑战、技术方案上的争执、平台优先 or 业务优先的博弈、低落的团队氛围、个人的低谷等等。这些困难与挑战，你是退缩了？还是有成长？在带团队时，再次面临这些挑战时，这时你是否有解决或者有勇气了.

发现没有？毕业 10 年后，作为一个团队贡献者，你可能需要具备这些能力，并且还远远不止。而且，更可悲的时，当毕业 10 年后，突然发现自己不具备这个能力时（比如晋升失败时发现了），这些能力 GAP 就不再是 2 到 3 年就能追得上的了。我见过一些有准备的同学，他们给自己的目标是在毕业第 7 年就要具备这些能力，他有严格的学习计划、实践计划、甚至是冒险的创业经历。当他到第 10 年这个点时，这些高阶技能很可能已经有 3 年的实践经验了。如果我们没有做好准备，10 年后，如何和这批人竞争？这些软、硬知识，从十年这个时间刻度倒排，学习计划、实践计划的执行还是很紧张的。所以，从现在开始给自己制定一个严格的学习计划、严格执行，多实践吧.