• 程序员该如何有效的阅读?
  • 发布于 2个月前
  • 340 热度
    0 评论
  • 那场梦
  • 18 粉丝 41 篇博客
  •   
之前写过文章讲工程师应该怎么学习,讲的最多的就是要多读体系化的技术书籍。最近碰到一些朋友说读书读不进去,读的太慢,或者读完就忘该怎么办。

这篇文章解答一下这几个问题:
1.读书读不进去
2.如何加快阅读技术类书籍的速度

3.读过的书会忘记怎么办


读书读不进去
读技术书主要有两个目的,一是和工作内容结合寻找能够落地的方案,二是了解不太熟悉的领域的宏观大图,帮助自己建立知识体系,拓宽视野。

能直接和工作内容结合的书是最好的,如果我们在做流式计算领域,那把市面上常见的几本英文书:《stream processing with flink/spark》 和 《streaming systems》读完自然是应该的,书的内容和我们的工作密切相关,这种类型的书不太可能看不进去,如果看不进去,就看看自己的银行卡余额。

若是想拓宽视野,阅读的内容大多就和我们的日常工作脱离了,如果书里的一些生僻内容,恰好触达了我们某根脆弱的躺平神经,可能直接就弃了。这需要我们对自己的意志力有一些要求,阅读时定一个简单的目标,比如这个月要读完,并且要写出一篇读书笔记。有办法来跟踪自己的进度(比如有 deadline 的 todo list)。

某些公司的环境会让大家过度焦虑看不进书,这也是可以理解的。适度的焦虑能够促使我们思考、创新和进步,过度的焦虑对精神和身体都是摧残。如果在公司内长期无法缓解焦虑的话,建议还是转岗或换工作对自己更好一些。

简单说,就是与工作结合,对自己的意志力有一些基本要求,远离那些让自己无法沉下心读书的环境。

加快读书速度
这里仅指技术类的书,也分两种,一种是实战类,一种是理论类。

实战类的书内容有很多代码片段,我们跟着书的进度把书里的 demo 都敲一遍,可以把书里的内容吸收大部分了,不太看得懂的 demo 才需要去阅读代码附着的文字说明。敲完的 demo 可以直接放在自己的工具箱里,可以在 Github 上为自己开一个 learning 的仓库来做这件事。

理论类的书一般都是在向读者兜售方法论,质量比较高的理论书都有丰富详实的配图。这种类型的书,我们只要能够读懂书里的所有图就好。相比理解文字,人们在理解图片上有天然的优势:

Research at 3M Corporation concluded that we process visuals 60,000 times faster than text. Further studies find that the human brain deciphers image elements simultaneously, while language is decoded in a linear, sequential manner taking more time to process.
举个例子,《microservices patterns》这本书就写的特别好,书内所有内容基本都配有具体的流程、交互、架构图,所以阅读起来体验也非常好,可以在 1-3 天之内顺利地读完,不太注意图形表达的作者写出来的书往往就很糟糕。

重视内容结构的书,会按总分总的结构来编写,每一章一定要有一个大图,图里会把章节内的关键点都放进去,让人能很方便的在读完文章之后根据图片去记忆一些关键知识。没有汇总的章节阅读就很费劲了,这一点在做内容输出的时候也应该注意。

简单来说嘛,就是抄代码+读图。

读过就忘
拓宽自己视野的书读了忘正常的。。。。

这里我们要讲费曼学习法了,你需要用思维导图把书里的内容给总结下来,不想画图也行,写一篇读书笔记也是可以的。输出是最好的促进输入的工具,不需要多讲了,写文章、做演讲也是工程师重要的能力。

如果未来某天忘记了某本书的内容,把之前自己总结的图和笔记翻出来就行,很快就可以回忆起来了。我见到过很多牛人你问他某个领域的东西也想不起来,但掏出他的导图马上就可以滔滔不绝地讲起来。

日常工作可能会碰到某些公司里高级别的老板宣扬读书无用论,这些人大多是被时代的红利冲昏了头,对于互联网的后来人来说,很难像前人那样凭借运气实现人生的逆转。

作为技术领域的从业者,面对日新月异的技术领域,只有知识与个人能力才不会让我们沉沦。


用户评论