想要考虑所有情况而焦虑该怎么办?

自从我变成重度的笔记用户后,我学习一门知识,会试图把所有的可能性都学一遍,但是知识细节总是那么多,而我学的东西又很碎片化,这使我非常焦虑,我感觉自己会的东西非常少。

比如之前学链表时,想把静态链表动态链表,单链表双链表,它们的所有操作都学一遍,而我学这些都是一个个画图慢慢来得,我学了很久,但是才过了一半,后来我发现就是一个普通的语法,要把他所有的可能性都列出来,也是非常复杂的一件事,比如我曾试着把 channel 所有阻塞通过情况列出来,后来我发现哪怕是一个简单的 switch 语法,也有很多种情况,有没有变量,变量声明否,多 case,加不加 default,用不用 fallthrough,break 等等,所有的情况都是指数级的,我开始意识到自己这种学习方式出了问题。

我为什么要试图这么做?我是一个完美主义者,以前有过严重的焦虑症和强迫症,而对于这个学习方式,我是出于这个考虑:

编程知识是非常多而碎片的,我们的大脑的空间又非常有限,因此我们不应该试图去记忆这些知识,我们要达到这个目的:看到某个知识,我们知道他是什么;我们能够自行查询解决这个问题。

那我们大脑中应该有些什么知识呢?我认为是知识的索引,那问题就是怎么建立这个知识的索引。

我试图这样做:

1.遍历所有知识,建立缓存,我们的大脑会自动忘记那些不常用的知识。

2.建立知识体系,深入而又通俗易懂的理解知识,知道知识的所属结构。

试图遍历所有知识,就是为了建立知识缓存。

但是因为知识的锁碎,很多时候我们会陷入知识细节本身中,会变成这样:只是罗列知识,只是对只术语进行解释。而这会导致知识无法建立体系,我们很多时候不知道自己在说些什么。

我会怎么做:

  1. 建立知识体系

2.学习知识时,知道自己学的是什么知识,知道它是哪一层次的知识。

3.列出重点,难点,常用知识,重点学这些知识。

相关文章

28 thoughts on “想要考虑所有情况而焦虑该怎么办?

  1. 本来是问答的,写着写着就自己解决问题了,博客写多了,有点像博客了。

    的确很多时候我们问问题是为了抒发情绪,而不是解决问题本身。

  2. 同意
    @kuangwinnie
    的看法。楼主你是过度陷入到细节里了。心中要有大画面,要建立直觉。然后真的有必要时,再去扣细节。不要本末倒置。

  3. @user8341 陷入细节之后甚至会发现一些细节本身就是自相矛盾的。。。
    总结出来几个套路然后面试之前学学细节就行了。。。我是这么觉得的

  4. 我现在看啥都想记下来…结果就是 需要再读一遍甚至反复,然而没那么多时间,久而久之就堆在一坨了…

  5. 你完全不需要焦虑,因为你考虑的东西涵盖了非常多的东西,你一个人不可能有那么多时间来把这么多的问题全部做好。

    不然,你以为微软 20 万工程师,2 年才做一个 Windows,是怎么来的?

    很多事情并不难,只是复杂,只是麻烦,只是很消耗时间。假设你的寿命是无限的,你完全可以自己做一个操作系统。

  6. 很像我经常看见的某些“心得博主”写的高大上的知识点总结树状图,一个知识点后面跟着一个又一个知识点,像是会无限延伸一般,很多新人看到这种东西第一感觉其实是恐惧,恐惧于繁杂的细节,但是编程最终还是实践为王,亲自解决一个问题的记忆往往比了解完美解决该问题的所有方法更加深刻
    纸上得来终觉浅,绝知此事要躬行

  7. 没关系。先保持这样的焦虑,并尝试顺着自己的焦虑去多看多实践多想,时间长了,你就知道哪些细节是不重要的,哪些细节是需要记下来的,哪些细节已经成为了你的直觉。那时自然不焦虑了。我更多觉得这样的焦虑是学习的必经过程,也许不必上来就否定。

  8. 完美主义者需要解决的主要问题是时间管理和按优先级安排任务,不建议带着这样的态度到工作中。

  9. 我觉得把 你是没经历过难得东西
    先把简单的 LEETCODE 刷 500 道 再来说你学 Go 的问题吧
    你遇到的这些问题 说真的是工程上比较简单的问题了
    其实好多技术性博客 已经给你讲透了
    比如 channel 那编译时候 底层调用什么函数 你去看过源码么

  10. “哪怕是一个简单的 switch 语法,也有很多种情况,有没有变量,变量声明否,多 case,加不加 default,用不用 fallthrough,break 等等”
    这说明 switch 语法并不简单 … 或者说就是前人挖的大坑,后人都要去摔一跤

    楼主自认为想要考虑所有情况,但是没有考虑的是导致这种问题的原因,除了前人挖了这个坑以外,后人非要瞎了眼去踩也是很重要的。

  11. 个人认为,学习一门语言或者大的框架,需要制定学习路线或者按照教程等系统性学习,其他的比较零碎的知识点的话,获取最高性价比收益是在你达到熟练掌握使用的时候就可以了,细节或者源码可以针对面试题等专项去看,这些基本也都有网上人家梳理好的。
    毕竟你的时间有限,精力有限,智力也是有限的,不要过分强求自己,而且我认为零碎的知识点记下来的零碎的笔记回头再看的可能性也不大

  12. 掌握体系结构,掌握内在的规律就够了,不要关心细节,任何细节都是内在规律的体现。你没有必要去观察所有的雪花,因为这个世界上不存在两片相同的雪花,但任何一片雪花都是六棱型的冰晶的组合。

  13. 选择最重要的事情去做,对于每个人来说,放在自己面前最重要的事情都不一样。

    对于学生,这么研究没什么错误。
    但是对于工作党,这么学习可能就不一定对了。

    针对自己的情况,选择。所以,选择比努力更重要。

  14. 所以我不赞同记笔记的学习方式。
    像你这样如此机械化地学习知识,完全就是舍本逐末。

  15. 人的精力很有限,人的寿命更有限。

    人的一生为什么需要做选择,因为你的生命和精力都很有限,你只能有所舍弃。

  16. 学习不是知识的堆砌. 而是需要在脑中构建出一个概念.

    比如链表, 当你脑中有了链表这个概念时, 就算你从来没有了解过双链表, 但是你只需要搜索一下双链表是个什么东西, 几分钟后, 你就已经理解了双链表了, 甚至脑中已经能想出他是怎么实现的了

    人脑适合运算,而不适合存储.

  17. @kuangwinnie #2 还是本科计算机,的确没学过更后面的数学了

    @chocovon #6 要实践,这个的确,经常用到那些的就算不特意总结,也能写个大概

    @laminux29 #10 的确是很全面的,我日常和别人交流,或者实际应用到的都是很小的一点,这我也能体会到,不过我也不是一直都是这样,有时候事情多了,一焦虑就管理不过来,就想面面俱到。

    @laqow #12 这些知识的问题本来就是一直存在的,哪怕我们不去接触,也存在,总不可能全都掌握吧。

    @cassyfar #13 我最近在写 go 的简单课件,我其实是在更多的在文字上,从符合人脑认知的方式来讲的,也不想单纯罗列知识,但是有时一看感觉自己写的又太少了,因为我过去学都是一来就把这些情况过一遍代码,感觉有点脱离代码,又考虑到有些的确是平时会用的,一加又是一大堆,有些冲突。

    @ljpCN #14 的确不是时刻都这样,有时候学这些,学得比较深入了我就会有些焦虑,适度的焦虑也有好处,能给我们压力,回头看有些知识我掌握得也挺全面。

    @marat1ren #15 的确是这样,完成任务和学到知识,我有时候无法忍受知识断层,所以我想要的是学懂知识,但是很多时候别人要的只是能跑起来,怎么管理这两者我也在学,

    @beidounanxizi #16 也不能这么说,lc 我也一直在学,但是这是思维上的问题,语法本身的确没啥技术性,但是也要过一遍吧,多放时间在重点上,这我有点想法。 有些东西不罗列知识,而从原理上看,这的确是个着手点。

    @secondwtq #17
    的确是个左手点,为什么有这个东西,自然而然引出这个东西,知道这个考虑的方向,具体的细节反而可以忘记。

    @rodrick #18 按知识体系去学是挺好,但是这有点难以做到。

    @XiLemon #22 嗯

    @wutiantong #24 这我就不赞同你的观点了,我并不是完全这么单纯罗列知识,我学这些也是从顶向下学的,知道自己学的是哪一层词的知识,只是到了这一层细节比较多而已,而记笔记的方式就不说了,只有记过的人才能体会它的好处。

    @InkAndBanner #27 我看过源码,有时也经常出现那种 a->b->c 这种知识的缺漏,感觉有些舍本逐末了,也在改。

  18. 逐渐积累吧,你要明白的是你最终是为了解决问题的,而不是单纯的学习知识,学习用知识解决问题的能力。

发表评论

电子邮件地址不会被公开。 必填项已用*标注