加餐四 | 学习基础技术:你对“基础”的理解准确吗?
该思维导图由 AI 生成,仅供参考
典型的错误观点
- 深入了解
- 翻译
- 解释
- 总结
学习基础技术并非简单地掌握底层、源码或不变的知识,而是应该与工作任务相关。文章提出了三种错误观点:基础等于底层、源码或不变的知识。作者认为基础能力应该与工作相关,提出了技能图谱的概念,将基础能力细化为工具、生态、容器和原理四个维度。通过举例说明,阐述了不同工作领域的基础能力差异。最后,提出了提升技术的技巧,强调学习基础技术应该避免一刀切,而是根据技能图谱有针对性地学习。文章内容深入浅出,为读者提供了清晰的学习基础技术的指导思路。文章强调了基础能力与工作任务相关,提出了技能图谱的概念,将基础能力细化为工具、生态、容器和原理四个维度。通过举例说明不同工作领域的基础能力差异,强调学习基础技术应该避免一刀切,而是根据技能图谱有针对性地学习。
《大厂晋升指南》,新⼈⾸单¥68
全部留言(28)
- 最新
- 精选
- sugar说一下自己的感受: 总有种感觉:做业务会导致自己的技术在整个计算机科学的技能树上停留在浅层次浅尝辄止,无法深入,做了2-3年基本可以把同一个岗位 做业务所需的技能点全部点亮了,再进一步去点亮更深的技能点都会存在老师在本为中说的:“因为用不到,所以学也没什么用,硬着头皮学收益也会很小”。因此 一直做业务,无法建立自己的不可替代性; 而做基础类技术研发,更像是做科研,有非常多的东西需要去学习,随着时间的积累,可以把技能树一直往深入点亮下去,建立起自己的技术壁垒。技术壁垒有啥用呢?我认为最务实的就是去应对996和35岁焦虑,因为这本质上是国内劳动力过剩导致的一种病态职场现象,做科研的方式去做基础技术而非业务开发,这能让自己无法轻易被年轻人替代,是一个应对上述职业焦虑的办法。 如果一直做业务,似乎必须在管理方面建立自己的“不可替代性”,但是这里存在一个我个人觉得很不爽的地方,就是技术经理普遍面临的尴尬问题:在业务团队每当你面临与pm在产品思路上争论时,技术人的话语权有限,而做基础技术,能有更多工作上的自由,因为在这个领域没有pm,一切东西该怎么做、做成什么样、做得好不好都是技术岗的leader或高工去定义的,pm根本不懂,公司高层也不会轻易干涉,往往会让cto自己养一批技术过硬的人 放手去干就是了。 不知华仔老师怎么看呢?
作者回复: 其实你的理解存在一些误解。 首先,做业务2~3年就能把技能树点亮,原因不是做业务本身简单,而是业务没有发展,如果你的业务从10万增长到100万,从100万增长到千万,不同阶段需要的技能是不一样的。 其次,你认为做基础技术可以做的很深并因此可以建立自己的技术壁垒,这也是一个错误的认知。 目前国内有团队做基础技术的公司并不多,而且事实上大部分也都是基于开源方案二次开发。 除非你能负责基础技术的架构和设计,否则大部分的时候其实也是开发各种和业务功能类似的功能,并不会让你的技术越来越深。 第三,基础技术做的好不好并不是自己说了算,而是由基础技术的使用方也就是业务团队来评价的,正因为做的好不好没有明确标准,很多时候就看使用方的口碑, 有人的地方就有江湖,一般来说,除非你的做的特别好,否则基础技术团队永远都是被吐槽的对象。 其实,无论是做业务还是做基础技术,要想技术有提升,必须要面对越来越大的挑战,对于业务来说,就是业务规模在增长;对于基础技术来说,就是基础技术更强大; 而基础技术最后要体现价值,还是要依托业务来展现,你可能会认为自己的基础技术很牛逼,但是如果业务无法验证、市场无法验证,最后还是作用不大的。
2021-01-241363 - humor虽然道理是这样,但是如果没有学过某项基础技术,比如操作系统和网络,我怎么知道我学到什么深度才算合适呢?或者我后来的工作遇到了难题,要解决这个难题需要用到比较深的基础技术,但是我又没去学这么深,我怎么能想到要去学这项技术,然后应用呢?
作者回复: 第一个问题: 如果你完全都没学过某个技术,连它包含什么内容,涉及哪些概念,有什么应用场景都完全不清楚,是不可能看一眼就知道应该学到什么深度的。 要想自己不学就知道其深度,只有让别人来告诉你,即使别人来告诉你,你也只是知道了结果,不知道为什么有的是要深度学习,有的是要大概了解。 所以说学习不是一次性的,而是要逐步迭代深入的。以计算机网络为例,第一次学习你至少要系统的找本书或者资料系统学习一下,你就能够知道其内容涵盖DNS、TCP、IP、BGP、ARP、RARP、RIP、OSPF……这一大串技术,此时你已经知道每个技术点的大概含义和适应范围了,你再结合自己的工作来判断哪些是大概了解,那些是要深入学习的。 例如,你是做Java后台业务开发的,那DNS、TCP、IP是需要深入了解的,但是ARP、OSPF、BGP就不需要深入了解;但如果你是运维,这些基本都要深入理解。 第二个问题: 要么别人告诉你,要么自己带着问题去探索,然后找到对应的技术点,再深入学习。 例如,false sharing这个案例,一开始我也不知道,我是去查"multi-thread high performance"这个关键字,然后无意中发现的,发现后我就深入的去学习了一下,又了解了MESI等关联知识。
2021-01-1516 - MondayJava服务器开发: 1、工具 1)语言-java,SQL,VUE 2)IDE:Ideal 3)版本管理工具:Git 4)依赖管理:Maven 2、生态 1)中间件:RabbitMQ、Kafak 2)存储:Redis(Codis集群)、Mongodb、MySQL、Postgres、ES 3)依赖组件/系统:Tomcat、SpringCloud、Springboot、CAT、ZK、Promethus、Dubbo、Activiti、Skywalking、Guava 3、容器:Window、Linux、华为云、Docker、K8S 4、原理:生态中和各项的原理(待分解) 感觉很多的东西,但是得分个轻重缓急,本人现在负责冷数据的查询系统,优先学习Postgres
作者回复: 分析的非常好,尤其是最后的“轻重缓急”,说明你已经充分理解了晋升原则中的“价值原则”。
2021-02-0815 - 黄立毕竟不是做科研,还是以应用为主,学到用到最好
作者回复: 可以这么说,毕竟时间和精力有限,要考虑投入产出比
2021-01-1512 - 畅畅这点我自己太有感触了,回顾工作这几年,我其实没有把工作中用到的技术和自己感兴趣的技术区分开,导致我工作中看了很多和工作关联不是很大的“基础知识”。 而且自己也没有梳理出图谱,感觉自己瞎折腾几年,折腾的东西零零散散,感觉自己没学到什么。 接下来应该还是先梳理图谱,然后通过20h理论去先补充自己短腿的地方,然后在用更多的时间去突破重点技术领域。
作者回复: 优先整理和工作相关的基础技术图谱,然后在此基础上找一些重点方向突破
2021-04-098 - 遇见小时候👣Java后端开发 工具:idea,git,maven,visual paradigm/omini graph/ppt/process on/starUML,vscode,markdown 生态:Spring,SpringMVC,SpringBoot,graphQL,MyBatis,HSF,Tair,MetaQ,Diamond,Switch,ScheduleX,MySQL,react,ant-d 容器:Tomcat,Linux,阿里云ECS等 原理:JVM(垃圾回收器及垃圾回收算法等)、线程模型、I/O模型、各种锁及线程工具类的原理和机制等、面向对象设计原则、架构设计原则、CAP理论等、数据库索引实现原理等、设计模式、企业级应用架构模式等
作者回复: 总结的很全面
2021-05-017 - 秃然的自我~说的没错,但是其中有个度很难衡量,就是现在工作中用不到,但是后续突然用到了,如果当时不会,可能就会错失一些机会。
作者回复: 先把常用的,流行的,成熟的学会了,基本不用担心突然要用,因为可以说每个技术都有多个选择,即使突然要用,你积累多了,学起来也很快
2021-01-1826 - 威龙“打好基础很重要,打准基础更重要”总结的非常到位,虽然自己不是做技术的同学,但是从这篇加餐中get到学以致用的思想。结合日常做产品工作来思考,就是要找准产品和项目的核心价值,找准业务方核心需求,保持Less is more的设计思想。
作者回复: 很有见地 :) 主要是我们的时间和精力有限,如果什么都想学很深,是不现实的,而且投入产出比低。
2021-01-176 - humor基础技术就算暂时用不到,学习深入一点也会有好处吧,比如可以学习前人的设计思想,将优秀的设计思想引入自己的业务中,或者为以后应用的机会做准备😁
作者回复: 都可以引入自己的业务了,为啥还说用不到呢?
2021-01-156 - 我来也老师真敢说😄 上次只说了编译原理,这次说了一大堆。
作者回复: 你觉得说的有道理不?😂
2021-01-1526