即将三十,我不敢说我精通任何一项技术
到底要不要转管理呢?

超级奶爸 图片来源:http://www.imdb.com/title/tt0395699/

回顾自己的技术成长之路,具体技术真心没有一样敢说精通,对于一个像我这样工作6、7年的人来说,实在有些难以启齿。

现在中国整个的技术环境看重的是技术深度,而我从一开始就认为应该先广度再深度,自然在同行中被认为是异类。我没记错的话,大神左耳朵耗子的观点就是深度优先。

为什么要广度优先,而不是深度优先。我有自己理由:

  • 技术变化太快,当你还没有深挖到某一个框架的本质,这个框架就可能已经过时了,特别是JS框架
  • 容易只见树木、不见森林:比如你花很多时间去研究如何分布式存储你业务应用中的文件,但是你可能不知道世界上还有AWS S3这样的东西
  • 手里有把锤子,全世界都是钉子:精通写bash脚本的人,所有的运维工作都倾向于写bash来解决运维问题,不知道世界上还有Ansible这样方便的东西,也不知道有时候根本问题不在运维,而在开发

我说出这些理由,并不是说我们就不需要深入研究某个框架和技术,只是想说明我们的选择的优先级会决定,至少会影响我们的思维方式。

这几年,我开始输出一些体现我思维方式的文章,比如:

很少人发现这些文章的真正价值,因为看起来和他们的实际工作没有任何关系,这些文章不会告诉你怎么快速搭建好https环境,也不告诉你怎么用Ansible copy一个文件到所有的目标机器上。

在一次面试时一位老架构师两次问我:《耦合的本质》真的是你自己写的?显然他不相信写这篇文章的人30不到。确认之后,他说他不完全认同“耦合的本质是假设”,但是他欣赏这样的思维方式。

我头一回感觉到有人看懂这篇文章。

总的来说,这些文章体现出来思维方式是:

利用概念推导、还原事物的形成过程、找共性这3个手段来找到事物的本质,再从这个本质推导基于此事物的上层建筑。

比如我根据我们实际运维过程所要做的事情,推导出要实现自动化所要解决的问题,然后再通过“找共性”的方法,最终找到了这Puppet,Chef,Ansible 三款工具之间的共性。

但是有什么用呢?其实,找到共性后,当遇到第四种自动化运维工具Salt时,我们就很容易提问了:

  1. Salt如何与受控机器通信
  2. 如何组织机器的?
  3. 使用什么DSL来描述这些机器的配置

最后根据这些问题进行深入地学习,这样我们就可以从被动学习变成主动学习,有方法论的学习方式。甚至找到这些工具的知识边界。

然而这只是我的个人学习方式,不一定适用于所有人。也不代表我的学习方式就是好的。

我只想说明:深度优先和广度优先的选择会改变我们的思维方式。

按道理,使用这样的思维方式(有点像方法论),任何一门技术都可以做到精通,但是我目前就是没做到精通。

因为我排斥用脑袋记东西。我认为记不了的东西或者能不记的东西,它就不值得记忆。比如如何将字符串ip转成一个整型数字、Ansible里某个module的具体用法。

而现实中,我对比其他的运维人员,我发现我用Ansible用得已经非常好了,Ansible里的概念我基本已经理解透了。但是我仍然不敢说精通Ansible。我实在记不了unarchive这个module的所有参数。

所以,即将三十了,我仍然不敢说我精通任何一项技术。这成为我的困境。

这时,很多人就会说了,你应该考虑转管理了。

但是,我要问了:为什么要转管理呢?

不少人的回答:

因为你老了,你没有精力去学习更多的新语言、新框架了,你拼不过小鲜肉了。

这个观点里有,有两个假设:第一,到三十后,你学不会,或学得慢新语言、新框架是因为没有精力;第二,小鲜肉没有能力做管理;

第一点假设不成立,因为那只是借口——不想做的人,会找理由,想做的人,会找办法。第二点假设只是概率性问题,小鲜肉也可以做管理。

转不转管理,决定于你是否真的Ready好了,是否真的喜欢做管理。和你年龄没有任何关系。

说到底,写不写代码,做不做管理,都是个非常私人的问题。我们没必要那么在意别人怎么看。

最后,我深爱着写代码。这不会因为我目前或将来是否精通某项技术而改变。


Last modified on 2017-05-10