Open ppambler opened 3 years ago
我们看到的书,不能直接反映作者的思维网络,而只是一种经过「编译」之后的结果。
就像是 xxx 软件是在 Mac 里边跑的,而你把它放在 Windows 里边跑, 就跑不起来了!
总之,别人写成的书,这种线性编译的结果,即便你每个字都认识,也未必能够理解和体悟。除非你拥有了符合要求的思维运行环境。
你要拿的是「源码」,可不是编译后的结果!有了源码,你可以基于这个源码做一些你想做的事儿!
史蒂芬平克《风格感觉》中的话:
写作之难,在于把网状的思考,用树状的语法结构,转换成线性字符串。("The Web, the Tree, and the String")。
我们看到的书,不能直接反映作者的思维网络,而只是一种经过「编译」之后的结果。
如果你平时在不同平台上使用软件的话。应该有这样的体会:一个只给 Windows 平台开发的应用,你即便把它拷贝到了其他桌面端或者移动端,也是用不了的。因为没有运行环境。
同样,别人写成的书,这种线性编译的结果,即便你每个字都认识,也未必能够理解和体悟。除非你拥有了符合要求的思维运行环境。
我们今天读古人的文章,会常有这种感觉。他当时的历史环境,他阅读过的内容,他参与过的辩论……因为年代久远,在我们读者这里,都消失了。
我们必须借助辅助者,例如教师或者讲述者,才能更好理解。
而且,即便你拥有了背景知识甚至是专业知识。阅读别人的线性编译结果(书或者文章),也不一定是轻松愉快的事儿。许多人做的「拆书」,其实就是我们所说的「逆向工程」。这些活动包括但不限于高亮文字、圈画重点、组织知识点,构建思维导图等。
这种工作,即便付出了劳动,也真的不是每个人都能做好的。特别是初始阶段。
你没有足够的知识点,就没法读得足够快。你没有足够快的阅读速度,就不会读得足够多,以便掌握足够的上下文。那就会被局限在某个阶段,无法有效提升。
更有甚者,如果你身处信息闭塞的地方,缺乏足够多的见识,也无法理解别人「秒懂的常识」。你有学习的愿望,但是却连最基本的门槛都难以跨越。上网提出这些问题,还会遭到嘲笑,甚至有人还直接把《提问的艺术》甩到你脸上……
这或许就能解释,为什么某些地方,尽管有了图书馆,有了基础通讯设施(例如网络和公用机房等),却依然会产生「信息贫困」与「数字鸿沟」。
人们因为长久生活在这种环境中,对学习的困难与失败司空见惯,觉得学习本该就是这么一件困苦的事儿。
真的吗?
我们必须接受这个事实吗?
Conor 不信这个邪。
他的目标,是让人们都能直接获得别人的思维之网,而不是最后编译出来的线性文字。这样,那些大卸八块的批注、划重点和重组结构,就不必在每一个人那儿,都重复一次了。
你拿到的,是思维的源代码,而不是编译结果。你所做的,是基于别人的源代码,做自己好奇、想做的事儿。
「站在巨人的肩膀上」这句话,终于可以变得离我们普通人更接近了。
我一向倡导的学习方式就是阅读官方文档,好的技术一定有好的文档。而阅读官方文档分成三个阶段:
1)刚开始接触的时候,通篇阅读。对要学的东西有一个宏观认识和理解。
理解,就是要明白一项技术的设计初衷、背后的哲学。学习任何一项技术、语言、框架之初,都要问自己几个问题:
带着上面的问题去阅读文档。有不理解的部分不用怕,因为不可能第一遍读文档就理解全部。不理解的部分要记下来,便于今后返回来查阅。
很多人都不注意上面这些问题,而是上来就应用,人家用我就用,或者公司要求用,或者追时髦用。按照自己以前的经验和想法用别人按不同思想开发出来的技术,越用越难受,然后就得出结论:这个东西不成熟,坑很多。
2)开始实践。只有实践才出真知。也只有实践才能对之前以为自己理解的部分又更深入的认识,也只有实践才能把之前不理解的部分想明白。有些概念必须在实际问题环境中才能看明白想清楚。这时候,遇到问题要返回去查阅文档相对应的部分。因为你在第一阶段已经对文档结构有了了解。
3)在用了一段时间后,认为自己已经算是“熟悉”了。在不忙的时候,回过头重新把文档再通读一遍。这时候你会发现自己站在了一个新的高度,也会发现文档中的一些观点是自己以前没有注意的,这种感觉就对了。
目标:以完成项目功能为主要目标,不要去追求细节,细节是后面来完善的。
自己的知识漏洞在项目完成后去写博客来进行查漏补缺,切记
工资这个事情本身不是由自己决定的,而是由其他从业人员(你的竞争对手)决定的,你超出你竞争对手的部分就是你工资高于他们的部分(也是内卷的一种),本质也就是从业人员太多,而项目却在萎缩(好像还挺押韵)。 -> 人人都劝退建筑学,为什么建筑学平均薪资在各搜索网站上还是位居高地?
编程是需要团队合作的,需要自我降低,中等水平或者稍微偏下即可。 智商过高的人不适合团队合作,只有别人看的懂的代码才是好代码。
1
和l
是不同的,0
和o
是不同的,;
和;
是不同的)看视频学习时:每节课应该多看几遍, 一遍通览,记笔记。 一遍带着问题看。
发财没希望,小康没问题
在电影《教父》的原著中,作者马里奥·普佐有一句经典的旁白:在一秒钟内看到本质的人,和花半辈子也看不清一件事本质的人,自然是不一样的命运。
分析问题的基本框架:透析三棱镜
我们太喜欢给建议,却往往还没弄清楚问题到底是什么。问题的本质是「期望」与「现实」的落差,因此,如果要解决问题,首先得弄清楚期望是什么,目前现状又是如何,这样才能精准定义问题所在。
明确的问题,才能得到正确的答案,这是第一步。
B'
现状 -> B
期望值
B'
)只是症状,而导致这个症状出现的是ABC
这三个因素,他们才是更本质的问题。要解决这个问题,不能盯着(B' -> B
)看,而是要透过(B'
)去看ABC
,而这就是「透析三棱镜」SMART
原则
当你遇到一个问题的时候,第一步应该先检查一下的,你的目标是否符合 SMART
原则?你是否把手段本身当成了目标?
目标不对,什么都不对!
注意:你还得区分目标和手段
比如读书这件事,你定了一个目标,一年要读 50 本
读完后,依旧一脸迷茫
为啥会这样? -> 因为「读书是手段,并不是目的」
你为啥需要去读书?
这样的读书,才能有效果
读书,是让你达成某个目标的手段,但我们却常常把它当成了目标本身。
再比如:
在图书馆里边,一人要开窗,因为很热很闷,另一人则要关窗,因为外边噪音太大,影响我专心看书
A(方法) -> B'(现状) -> B(期望值)
比如:
洋务运动(不改变内,只改变外,中体西用,无法实现军事强国这个期望) Vs 明治维新(从内到外都改了,实现了军事强国)
想要大幅度改变现状,或者达成全新的目标,就得把原来的(A)一起改了,而不是在(B')点上转弯
中国之后的崛起就是把原有的 A 给彻底摧毁了,虽然代价惨痛,但从本质上解决问题,那就不得不这样做了,不然,你就是在白用功
重复原有的方法,只能得到同样的结果;想要有不同的结果,就需要用不同的方法。
💡:当发现问题后,如何调整(A)?
A、B 都咩有问题,而B'
还是存在,那么就一定出现了变量(C)
💡:如何找到C
?
5
只是一个象征性的数字,意在提醒你,别拿到第一个答案后就认为是全部,而要继续往下深挖 只是一个象征性的数字,意在提醒你,别拿到第一个答案后就认为是全部,而要继续往下深挖)
C语言的两个函数:
现实中你看到面,在计算机里边会将其数据化成具体的,也就是量化了
我们写的代码决定了显示屏该显示什么,我们对显示屏的交互,决定了显示屏接下来要显示什么……