技术的执念|TW洞见

只需稍加留意,我们就会发现自己被各种技术、工具包围。ThoughtWorks的技术雷达差不多每半年就会更新一次,在项目中更会遇到很多已经从技术雷达上消失的技术,项目上的旧技术/旧框架还在服役,新的技术/工具/语言/框架又在迅速的出现,有些昙花一现、迅速被新的后来者所取代。有的留下来了,不过也都在不断的演化、改变(不兼容的API,不同的版本等随处可见)。

1

知识漩涡

如果你不幸是一个前端工程师,那么这个更新速度还要更加迅速。三年前Backbone是主流,两年前是Angular.JS,去年是React,紧接着Flux、Reflux等作为React的扩展而成为了新的主流;Grunt流行过一段时间,很快被Gulp替代,而新的Webpack又依稀有大一统的趋势。

几乎每周都能看到新的框架涌现,双向绑定、虚拟DOM、事件代理、同构、后端渲染、更友好的语法糖、更快的执行速度等等,几乎任何一个方向都有无穷无尽的变化。

而后端也好不到哪里去,容器技术、Web框架、ORM、构建脚本、自动化测试工具、依赖管理、应用服务器等等,你总有很多的选项,却又无法在事先区分到底哪个技术/工具更靠谱、更适合项目。

置身其中,往往有眼花缭乱、应接不暇的感觉。知识工作者当然需要终身不断的学习,但是像目前这种节奏,我很怀疑这是否是一种健康的状态。

周围经常有人抱怨,好不容易上手了一个前端的MVC框架,一看周围的项目,大家已经在spike另外的框架/工具了(这意味着你在项目上无法使用该框架了……)。仅仅从学习的速度上来讲,我们已经远远无法跟上科技演化的节奏了,这是人类自身的一种限制。

知识的陷阱

假设你在一个Ruby项目上,学习了Rails/ActiveRecord/RSpec/MySQL。如果下一个项目还是Ruby,同样的技术站,你会觉得这是一种重复,因为除了业务逻辑、业务对象变化了之外,并没有新的内容,还是同样的技术。如果下一个项目是Python,技术栈变成了Django/nose/PostgreSQL,你可能会觉得有所提升,因为学到了不同的技术、框架、共建工具、测试工具等等,其实仔细观察,这还是一种重复,古人云:“换汤不换药”者,是也。

在目前我们所处的时代,信息以远远超过人们能接受的速度不断的被创造出来,一方面信息传播的速度大大提升了,另一方面是信息传播的渠道也极具多样化。

我们无时无刻不被过载的信息包围着,即使你不主动的去尝试获取新的信息,手机App里的微信、微博、Flipboard、Pocket、知乎、开发者头条、Feedly、果壳、丁香园等等的推送已经足以提供给你足够的信息(大部分甚至都来不及消费就变成了历史信息而被忽略)。

以我自己为例,从2015年10月到2016年2月,我学习了很多东西,看一下下面这张图:

图中灰色方框中的内容是项目要求的知识,另外的则是我根据自己的兴趣学习的,两者基本上各占一半。事实上有很多内容(尤其是根据自己兴趣学习的)在真正要使用时,可能还需要学一遍。这些内容可能让我产生了我学到了好多东西的错觉。其实这个在另一个角度显现了技术人员的一个误区:以为自己可以掌握所有软件开发相关的知识(或者说太过于纵容自己的好奇心和兴趣)。

2

过载的信息

身处这样的信息过载环境,我们很难不为自己对信息的缺乏而感到不安,担心自己错过了什么重要的信息,这种担心和焦虑会促使我们进一步将时间消耗在对信息的获取上,从而更无暇思考什么是真正重要的。

《如何阅读一本书》将书分为两类:一种是提供资讯/信息(known)的,一种是帮助你理解(understand)信息的。相对于理解来讲,资讯本身其实并不那么重要。

我们大部分人目前采用的碎片化的阅读方式无法提供给我们足够的“理解力”。我们都有这样的体验,有些书特别耗费脑力,读起来很累,而另一些书则非常轻松,易于消费。碎片化的阅读方式易于消费,只需要很少的思考就可以读懂,但是危害严重,它们并不会帮助你提升理解力。

但是直觉上我们会选择容易的事情来做,虽然这种浅层次的阅读只对扩展信息/资讯有帮助,对提升理解力则几乎无用。而我们在处理日常工作中的问题时,能真正帮助的,只有理解了的那部分知识。

我在2014年,曾经有几个月屏蔽了所有微信、微博等内容聚合类的应用,也尽量少的去技术论坛,每天就是写代码,读纸质书,除了最初几天的忐忑之外,整个过程的收获非常大(而且也没有漏掉任何重要的信息)。

知识框架

技术人员有时候会有一种想要把所有技术都掌握的「执念」,这在局外人来看是一种荒诞不经的想法,但是置身其中,你很难看出这一点。毕竟,有意思的东西实在太多了,各种范式的编程语言、编译器技术、人工智能、数据可视化、地理信息系统、嵌入式设备、软硬件结合、大数据、自动化测试等等,每一个方向都有无穷无尽的有意思的东西。

但是在知识规模如此巨大的今天,一个人是无法掌握所有技术的,更不用说新的技术还在不断的涌现出来!这就要求我们有节制的来聚焦在某些技术上,而视其他技术如无物。当然这需要很大的勇气和魄力,不过唯有如此,技术人员才可能有真正的长进和成就。

我基于自己的经验,绘制了一个「Web开发」方面的知识框架,这个框架上包含了一个比较全的技能/知识集合,也是我认为一个「Web开发」人员应该掌握的一些知识点。

在成为一个专家之前,你需要先对要学习的领域有一个全面的认识。也就是说,做Web开发,需要尽可能覆盖到这个框架上的所有点。一旦完成了这棵树上的所有节点,就不用再去做第二次了,这时候你可以尝试找到树上的某一个分支,深入下去。

这个听起来好像和我之前文章中的观点有所矛盾,其实不然。我在《我们真的缺前端工程师吗?》一文中提到过,"工程师不应该将自己束缚在前端开发上,要了解整个软件开发的全生命周期。"这里的观点其实是一致的,即首先要了解软件开发全生命周期中的所有节点,然后再有所侧重的去找自己的兴趣点来发展,即:先建立广度,再建立深度。

3

应对方法

对于知识的陷阱

当因自己的兴趣(而不是项目驱动,也就是没有实际的土壤来验证)而想要学习一个新的知识时,对照知识框架,如果发现自己已经在历史上学过它了,那就强迫自己放弃这个念头。比如你很熟悉用rspec来编写测试,忽然有一天心血来潮,想要学习JUnit,正确的做法就是泡杯茶,等这种冲动自己过去。

相信我,一旦有了Java项目,你可以非常快速的掌握JUnit,而且很快会找到对应的feature,就像一个长期工作在Java技术栈上的同事那样!

对于过载的信息

实践中,首先要令自己相信:你无法掌握所有的知识,即使仅仅在软件开发领域。有了这个大前提之后,你只需要采取先建立广度,再建立深度的原则即可:

  • 做减法(在建立了知识框架之后,有针对性的学习)
  • 主动、深度阅读经典
  • 为那些有趣但非自己关注方向的知识赋予较低的优先级

另外,还可以尝试将微信、微博关闭一段时间,或者至少可以不去点那些朋友圈里的《老X聊微服务》或者《12个你不知道的Sublime技巧》文章,保持专注,保持简单。

原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2016-09-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏AI科技大本营的专栏

AI行业实践精选:创建聊天机器人各大平台的优势与局限性分析

【AI100 导读】虽然聊天机器人行业目前仍然处在起步阶段,但是其发展速度却非常快,现在也变得越来越重要。假如这些聊天机器人可以为广大用户带来便利,满足他们的期...

3578
来自专栏DevOps时代的专栏

什么是 DevOps 三步工作法?

本文将介绍《DevOps Handbook》全书的核心:三步工作法。《DevOps Handbook》全书就是从三步工作法的思路出发,进行知识体系的组织和实践的...

1.1K8
来自专栏程序人生

在多维数据分析模型的路上越走越远

数据分析和可视化一直是大数据时代的热门话题。如今这一个数据为王的时代,当你使用某个产品,划划手指,动动鼠标,甚至一颦一笑都会被记录下来,送至服务器。然而,大量的...

4966
来自专栏大宽宽的碎碎念

如何看待编写业务代码

2896
来自专栏养码场

10个年薪50万+的90后程序员,他们都经历了什么?

如果说薪资是检验一家公司对程序员认可的标准,那么年纪轻轻就能达到年薪 50 万+,一定程度上说明了公司对他创造的价值的认可。

1702
来自专栏资深Tester

如何去面试软件测试工程师

4434
来自专栏无原型不设计

优质产品需求文档(PRD)写作三大原则

在上一篇文章中有介绍,产品经理的两项主要职责包括:对产品机会进行评估,以及对开发的产品进行评估。而定义即将开发上线的产品,则需要借助产品需求文档,来进行产品的...

6315
来自专栏编程

对于程序员来说写代码并不是最难的事情!

大多数非程序员认为软件开发是非常困难的,确实如此,但这种困难不像那些外行人理解的那样。最近在 Quora 上的一次讨论,程序员分享了他们认为工作中的最大困难,在...

1920
来自专栏程序你好

用户友好的微服务替换单体架构

891
来自专栏JAVA高级架构

如何成为架构师?7 个关键的思考、习惯和经验

工作了挺久,发现有个挺有意思的现象,从程序员、高级程序员,到现在挂着架构师、专家之类的头衔,伴随着技术和能力的提高,想不明白的事情反而越来越多了。这些疑问有些来...

3389

扫码关注云+社区

领取腾讯云代金券