|
|
|
|
|
# 春节特别放送（二）| 聊聊能力陷阱和终身学习
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是胜辉。今天正好是除夕夜，先在这里祝你虎年春节快乐。趁着过年这个轻松的节日气氛，这次我就不讲那些技术知识了，咱们来“务虚”地聊一聊。
|
|
|
|
|
|
|
|
|
|
|
|
## 规避“能力陷阱”
|
|
|
|
|
|
|
|
|
|
|
|
当你在某个领域工作了几年后，特别是到了5年乃至10年的时候，你已经在这个领域有了比较深厚的积累。那么恭喜你，此时的你可以说真的是“有所专长”了。
|
|
|
|
|
|
|
|
|
|
|
|
通过这么多年的积累，你不仅在技术上有颇为独到的见解，也对在这个领域里如何做事情，应该有了自己的沉淀和思路。一方面有技术能力，一方面有做事方法的指导原则，你在这个领域做成事情的概率似乎变得越来越大。
|
|
|
|
|
|
|
|
|
|
|
|
但是，有时候事情不会总是朝着一个方向走。比如，技术栈本身也经常发生迭代，组织的业务重心也可能发生变动，新的语言和框架不断涌现……这个时候，我们的经验会是推动我们迎接变革的沉着底气，还是反而会成为制约我们的沉重抱负？
|
|
|
|
|
|
|
|
|
|
|
|
甚至还有这样一种“可怕”的场景，你依赖多年的技术栈忽然有一天被公司告知：这个栈要下去，新的栈要上来。你要不要跟着往前走？
|
|
|
|
|
|
|
|
|
|
|
|
这其实是已经发生过很多次的事实。从“去IOE”，到“上云”，从授权软件模式到开源软件模式，技术和商业的形式一直在演变。这催生了很多新的技术热点，也悄悄地让不少岗位的光芒逐渐黯淡。
|
|
|
|
|
|
|
|
|
|
|
|
凡此种种，都提醒我们一个重要的事实：技术工作本身就一直在迭代演进，而且其迭代的速度可能远远超过其他行业，在互联网企业这一现象尤为明显。
|
|
|
|
|
|
|
|
|
|
|
|
当然，我也不是在鼓励内卷，贩卖焦虑。其实，在技术变迁的表象面前，我们内心可以沉静一些，不用过于担心。这是因为：**技术的底层都是相通的**，不同的包装出来的概念和产品，常常是“新瓶装旧酒”，或者是老理论的新实践。
|
|
|
|
|
|
|
|
|
|
|
|
这是战略上我们可以有用的底气：**只要计算机基础知识掌握得越牢靠，我们就越有希望在技术潮流的动荡中立于不败之地。**
|
|
|
|
|
|
|
|
|
|
|
|
有没有战略，一时半会儿看不出区别，但长远的效果非常明显。在战略的指导下，我们可以看清楚迷雾，认定我们坚持的方向，一步步走向我们的目标。一时的风潮或者人言，也难以扰乱我们的脚步。
|
|
|
|
|
|
|
|
|
|
|
|
在战术上呢？我觉得还是要重视，特别是要避免前面说的“能力陷阱”。我们通过多年的沉淀，逐步在某个领域建立起来的能力十分宝贵，但同时也不能沉湎其中，要适时地观察周边的技术趋势，结合自己的技术底蕴作出正确的判断，也就是正确的战略。
|
|
|
|
|
|
|
|
|
|
|
|
## 重视“终身学习”
|
|
|
|
|
|
|
|
|
|
|
|
但是，想要跳脱出自己的舒适区其实是不容易的，这需要这样一个能力：**终身学习的能力**。其实，与其说是“能力”，不如说是“意识”，是“认知”。不知道你有没有想过，为什么你知道了很多道理，但还是过不好这一生呢？是不是因为：你不去做，或者自认为要做也无法做好，其实本质原因是你并没有真的认同？
|
|
|
|
|
|
|
|
|
|
|
|
我相信**人人可以终身学习，只要我们从内心认同这个观点**。在技术领域，我觉得这一点尤其重要。
|
|
|
|
|
|
|
|
|
|
|
|
说说我自己吧，最初工作是在央企做运维，在那个时代的运维，主要靠对操作系统和业务系统的了解来工作，基本很少用到自动化体系。之后很快迎来了虚拟化、云计算、DevOps，我就发现得学习Linux；然后为了让运维工作简便有效率，又去学习Python，写自动化代码；为了把流量管得更好，学习TCP/IP，学习抓包分析；等网络的问题能解决大半的时候，我发现自己对内核的网络行为是一个很大的盲区，于是学习内核网络的知识……
|
|
|
|
|
|
|
|
|
|
|
|
至今，我还时常惶恐自己的知识掌握还远远不够，正应对了那句话：知道得越多，知道自己不会得也越多。好在，每当我读完一本厚厚的技术著作，或者解决完一个比较棘手的技术问题，内心就平静一些，丰盈一些。这应该就是知识带给我的力量感吧。
|
|
|
|
|
|
|
|
|
|
|
|
### 强化技术思考力，而不是技术能力
|
|
|
|
|
|
|
|
|
|
|
|
那是不是我们见到新的技术就扑上去学习，就可以了呢？最近几年的思考，让我觉得**技术思考力，比具体的技术能力更重要**。我记得在一个论坛上看到一名工程师发帖说：“某某大公司来的人，连Docker也不会！”当时就有别的工程师指出：“Docker有什么会不会的呢，如果是怎么用，一两天就熟悉了；如果是熟悉Docker底层代码，那是另说。”
|
|
|
|
|
|
|
|
|
|
|
|
前一个工程师就是把技术知识误当作技术能力的典型例子。这个问题容易出现在初级工程师身上。其实，对待具体的技术，我们在战略上可以“藐视”，也就是“我们只要想学，总可以学会”。我就算笨一点，别人学一天就会的东西，我就花两天。前提是，我真的认为这个东西值得我花两天。
|
|
|
|
|
|
|
|
|
|
|
|
那要达到这个认知，就需要你真的想得很清楚，你认同你要学的东西是在你的规划路线上的，是会对你产生价值的，你甚至甘愿在这段时间里**忍受寂寞**。这句话的反面就是，你如果想时时刻刻得到认可，那大概率是会局限在自己擅长的事情上，很难去更广阔的领域为你的下一次升级做储备。
|
|
|
|
|
|
|
|
|
|
|
|
### 打造自己的能力“焦点”
|
|
|
|
|
|
|
|
|
|
|
|
我另外一个建议是：**要有焦点，也就是你的核心竞争力**。这个焦点不是说你只去掌握非常细分的领域，而是说，你有一个核心可以提炼的能力特征。
|
|
|
|
|
|
|
|
|
|
|
|
比如我现在对自己的认知是：我可能在开发上比不过我团队里专门做开发的同学，我可能在思辨上也逊于其他更资深的同事，但我在**网络分析和流量管理**这个主题上，是有非常强的信心的。那么围绕这个核心，我要做的，就是把周边的技术拼图块给完整拼起来。
|
|
|
|
|
|
|
|
|
|
|
|
为了持续地构造这方面的能力，需要开发的时候就做开发，需要做产品的时候就做产品，需要加强领导力的时候也去学习怎么做到这一点，无论是什么，我们想清楚这件事情在自己规划的职业路线上的价值，那么就会少一些摇摆不定，多几分沉着坚定了。
|
|
|
|
|
|
|
|
|
|
|
|
如果你是做业务开发的，那么可以想一想，你的核心竞争力是不是这一块业务相关的开发，比如你对业务非常熟悉，开发能力对业务需求来说足够用，那么你大概率会有比较强的竞争力。
|
|
|
|
|
|
|
|
|
|
|
|
如果你是做运维开发的，那么应该想一想你对系统和网络的掌握，能否明显超过其他工程师，然后思考如何把运维体系做到更高的可用性和更高的效率，甚至是有能力打造出一个自动化运维平台，那么你在这方面的竞争力也会很强。
|
|
|
|
|
|
|
|
|
|
|
|
我也见过一些不太好的例子。有个别同学对新技术的热情很高，这一点很值得肯定，但问题是见什么都学一点，只学到皮毛，比如学到一些命令、怎么搭建等等，而没有真正理解这个技术或者产品的构建原理是什么，基于什么样的技术设计、为什么要这么设计。
|
|
|
|
|
|
|
|
|
|
|
|
“见山是山，见水是水”，你觉得每个产品都不一样，那可能是你还没看透它们。在很多地方浅浅地打一口井，甚至都因为太浅而算不上是井，那么说得残忍一点，你投入的时间，并没有获取到对应的该有的能力。**这一点一定要注意。**
|
|
|
|
|
|
|
|
|
|
|
|
当然也有非常正面的例子。有个新同学加入团队，刚开始半年就自己提出，愿意多做一些业务相关的工作，而不是着急着先做开发。这样做了半年，他已经对具体业务摸得很透了，之后开始做业务开发，可以说是顺风顺水，就完全没有别人那种“虽然在做开发，但不知道自己开发的东西是什么用途”的窘况，而是各种项目做一个成一个。
|
|
|
|
|
|
|
|
|
|
|
|
在这个过程中，这位同学也很快想清楚了自己要打造的核心竞争力是什么，做事情的时候不光自己很聚焦，别人也愿意在各方面给予帮助，因为别人都已经明白他的路线是什么，能给团队带来的帮助是什么。
|
|
|
|
|
|
|
|
|
|
|
|
好了，今天主要跟你聊的就是这些，也希望你能够不断学习、不断进步。另外，你在技术变迁的过程中，有没有也经历过这种困惑或者选择呢？你自己对终身学习又是怎么看的呢？欢迎在留言区分享出你的观点和看法，我们一同成长。
|
|
|
|
|
|
|
