原文地址
大家好久不见,虽然变成了年更博客,但是我还是有坚持在用文字来记录我的学习和生活的。
首先给大家安利 Notion 这款笔记应用,这一年它确实给我的生活带来很多改变,举一些应用例子:
- 博客。以前我习惯用 Markdown + Github 来维护我的博客
- 日常学习笔记、文档。之前习惯用 MindNode 思维导图
- 任务管理,不管是个人时间管理还是团队项目协作。
- 写日记、周报、总结。之前用 Day One
- 记账等等
除了 VSCode,Notion 是我第二个重度依赖的工具。
功能强大倒是其次,重要的是我可以随时随地去写东西,只要打开一个网页就可以了,我可以丢弃掉其他杂七杂八的工具。这种便捷性,让你找不到借口不去写点东西。
它就像一张白纸,会让人有一种提笔去写写画画的欲望。
实际上我现在很多生产工作只要一个浏览器就可以完成了。比如我最近就在使用 Code-Server,实现了在家无缝加班。再配合 Docker,将开发环境制作成镜像,也可以快速地构建一个开发环境。
回到正题
今天为什么又想起要写文章呢? 主要是早上看到一篇公众号推送:Deno 冲上榜首,Vue.js 首次屈居第二,JavaScript 2020 年度“新起之秀”都有谁?
Vite、ESBuild、SWC、TailWind、Snowpack、Vue3.0、Recoil、Deno、Lowcode…
不管是前端领域、还是技术领域、还是娱乐圈、每年都有涌现出一大堆的新玩意、每年都有新的鲜肉火了。
以往一年一届的技术大会,现在早早聊 一年要办十几次。
朋友圈转发的各种课程海报…
这是多角度、全方位攻击啊。我是不是落伍了? 我拿什么跟别人竞争?命吗?
如何看待新的技术?
我在面试时看到简历上说精通 jQuery、熟练掌握 Vue、React。我通常会问这样一个问题:
jQuery 当年那么火,为什么现在被 取代了? 解决了什么问题?
从历史上看,所有的技术翻新和淘汰都是必然的,包括我们自己,首先我们应该有一个开放的心态去看待新技术。
其次现在是一个网红时代,技术圈也是。很多技术可能也经过了过度的包装和营销,让人眼花缭乱,容易盲目随从。
这值得警惕,不是所有技术我们都值得我们花大量时间去琢磨,乱点技能树的。随波逐流,容易让人舍本求末,疲于奔命,流失核心竞争能力。
所以说,怎么看待新技术,先问自己这些问题:
-
这是啥玩意?
-
解决什么问题?
-
要回答这个问题,你需要对相关技术的历史有所了解。以史为鉴,可以知兴替。如果你是一个有经验的开发者,对历史的了解是你的优势,至少你更容易看到问题的本质。
说到这里,再推荐一本书 doodlewind 翻译的 JavaScript 20 年
-
能不能解决你现在面临的问题? 如果不能解决你现在的问题,大概率你也用不上它,如果你精力有限,姑且可以放一边,以后你需要它的时候,如果它真正有用,自然会出现在你眼前。
因为从实用主义角度,你没有机会实践它,你很快也会忘记它。
-
-
如果你很有兴趣,那么你可以深入去看一下怎么解决的?
- 架构是怎样的,思想是什么?最重要的还是思想呀
- 再深一点,整体流程是怎么走的?
- 如果你要成为这方面的专家那就得深入去学习源码了
如果没搞明白上述问题,就很容易落入陷阱、走冤枉路。这种例子比比皆是,比如微服务、中台比较火,大家都纷纷模仿,不搞这套就不牛逼了,搞到最后填不完的坑…
一方面可能是技术本身不成熟,另一方面是某些技术一旦离开了自己土壤,就很难存活。
哪些东西值得学习?
-
计算机科学基础。越核心的东西、更新的频率越低,这是每个技术人的内功。像张无忌一样,内功越强,杂七杂八的武功可不都是信手拈来?
-
沉淀下来的东西。
不管什么时候,新技术往往是成群出现的、屡见不鲜。比如之前各种各样的 CSS-in-js 库、各种状态管理库、各种跨平台小程序框架、视图框架…
真的是你需要的吗?如果不是要解决你的燃眉之急,尚且先慢下来等待他们自行洗牌,最后能活下来的才是你应该学习的。
更进一步的是形成属于自己知识体系,对知识进行归纳和内化、找出知识之间的关联。当分散的点联系成了网络,等待下一步质变。
深度还是广度?
知乎上面有很多类似的问题:
对于年轻的程序员,知识的深度还是广度比较重要?
知识的广度和深度哪个更重要?
深度重要还是广度重要?
…
显然这是很多人的疑问
相较于纠结深度还是广度,一个更重要的原则是:不要给自己设置边界。这也是很多人容易陷进去的误区,举一些生活中常见的例子:
- 我安安静静敲我的代码就行了,业务需求问题我不关心
- 我就按照原型实现了页面,用户怎么使用我不管
- 任务没完成是后端问题,后端接口还没提供,前端没办法干活
- 老是加班,项目还是逾期了,是 TeamLeader 的事情,我已经做了我该做的。
- 需求评审会议、技术评审会议像是后端和产品的相声专场,跟我关系不大,好浪费时间
- …
这应该是新时代的井底之蛙吧。给自己设置边界,只会让自己处于一种被动的状态,这不仅限制自己的发展、限制自己的眼界,遇到事情也会互相推诿;抗风险能力也会比较差,更容易被取代。
研发效率破局之道 中一个重要的关键词就是 “打破竖井”,旨在我们要打破自己的边界,站在更高的视角、或者全局的角度看待问题。你会发现现在很多流行的技术和实践都在体现这一点,比如:
- 全栈工程师。全栈开发就是让工程师不再只是对某一个单一职能负责,而是对最终产品负责。全栈开发是一个很好的抓手,逐步提高全栈开发的程度,大家的目标自然就会对齐,从而主动去提高,那其他方面的提高就容易得多了。
- DevOps、SRE
- 开发左移、开发右移、测试左移、测试右移
在打破竖井后,上面那些问题可能会这样子发展:
-
我安安静静敲我的代码就行了,业务需求问题我不关心
你会去参与项目研发的整个过程,包括需求评审、领域建模、设计、开发、测试、部署上线等等。
一来你对需求信息更加清楚,避免信息在层层传递的过程中出现误差,导致闭门造车;
二来可以发现流程中的各种瓶颈,做出针对性的优化和建议;
三是,了解这些信息有利于后续的开发计划、优先级划分
四是,紧密的沟通和协作,可以提高研发的运作效率,学习各自的优点。比如产品面向用户的思维、后端业务抽象能力、测试的缜密细致…
最后,这显然也可以锻炼业务能力
-
我就按照原型实现了页面,用户怎么使用我不管
Eating your own dog food, 把自己当成用户,从用户角度分析需求是否合理?用户体验是否友好?
关注需求背后要解决的业务问题,而不是产品经理的需求。如果你想摆脱被产品经理支配的恐惧,那么你就需要在往上游走,找出原始的业务需求,尝试自己去理解和分析,再配合技术的视角判断产品给出的方案合不合理,是不是产品自己YY拍脑袋的?尝试在产品需求上提出自己的看法,改进甚至拒绝不合理的需求。
-
任务没完成是后端问题,后端接口还没提供,前端没办法干活
前后端协作出现了哪些问题?能否要制定一些协作规范?例如文档先行、API Mock、接口自动化测试
-
老是加班,项目还是逾期了,是 TeamLeader 的事情,我已经做了我该做的。
项目在流程上出现了什么问题?研发的瓶颈是什么?怎么提高各个环节的研发效率?反馈机制是否完善?沟通是否存在问题?问题为什么不能提前暴露? 哪些可以自动化、提高流程效率?
-
需求评审会议、技术评审会议像是后端和产品的相声专场,跟我关系不大,好浪费时间
不给自己设置职能边界,尝试左移和右移,去参与上游和下游的流程。
业务能力很重要,技术人本来不就是用技术去实现业务自动化的?
很多公司的后端很重视在编码前需求分析、设计和评审。在前面的环节把该考虑的都考虑了,后面可以少走点弯路。将业务流程梳理清楚了、建立合理的业务模型、再映射到表结构、后面的实现基本就是照葫芦画瓢了。
这些都是值得我们学习的。
-
…
在打破自己的竖井之后再去谈深度和广度问题。
很显然,两者是不冲突的,我们需要广度、这不仅是指技术上面的广度、还有生活、沟通协作、管理、理财等软技能上面的广度。我们也需要深度,这提现了你的专业水平,是你的核心竞争能力。
当然,像 Morgan 说的更理想的是 M 型人才,在多个领域都有深度,这种可遇不可求。
也许这里的问题在于大部分人并不清楚自己要往哪个方向发展,眉毛胡子一把抓什么都学,祖国需要我去哪里我就去哪里。你也是这样吗?
就前端的细分领域就有跨平台、Iot、数据可视化、NodeJS…
这些领域也不断在扩展、以及和其他领域进行交汇,比如AI、Serverless、大数据…
怎么选择还是看自己的喜好,以及是否有平台进行实践。说到底还是那句话,不要给自己设置边界。
除了避免主动性的边界设置,也要提防被动的信息茧房。这是后话了
核心竞争能力是什么?
对于技术人,技术是立身之本。但是想想自己掌握的技术门槛并没有那么高啊?你会JS、HTML、Vue、React,别人无基础培训几个月出来的也可以‘一把梭’。再说你老了,拿什么跟年轻人去争福报?
这也是我经常问自己的问题。尤其是在日复一日,每日重复拧螺丝的日子里。
对于核心竞争能力,我觉得可以分为两个部分:
首先是硬的。即上文说的,你的技术广度和深度,这体现了你的专业水平和横移能力。这些技术深度和广度是不断学习和累积,不是几个月培训就能实现的。
其次是软的,这个涉及很多方面,比较抽象。早早聊这个面试专题不错(二次GG、早早聊记得给我打she),通过大厂招聘给我们描绘了一个优秀技术人的画像。加上我的理解,整理了下:
-
基础能力
- 逻辑思维。
- 学习能力
- 沟通、协作、组织能力
-
扎实的专业知识、包括理论和工程
-
有独特的亮点
- 深度。
- 对某一领域、某些技术有深入了解
- 业务能力。这也算一个领域
- 说小点 – 项目
- 清楚自己在公司的业务价值,并尝试提升自己的业务价值。
- 能全流程参与项目业务建设(包括调研、建模、设计等);
- 清楚自己做的项目的业务目标,用户是谁?目标是啥? 你在其中有哪些贡献,项目的结果是什么,能否用数据说明?
- 说大点 – 公司
- 对公司的业务发展甚至战略有独立见解、能够解决业务痛点、带领或影响业务发展
- 说远点 – 行业
- 对产品技术全局有清晰了解,能发现业务及商业模式的短板,并提出解决方案
- 说小点 – 项目
- 广度。比如后端、运维、测试、跨平台、AI等等
- 体系化。更进阶的是形成一套体系化的知识网络,从点、线、到面
- 深度。
-
认知
- 对自己认知。明确自己的定位和业务价值,有清晰的目标和职业规划。
- 对专业认知。是看对技术维度、深度的理解和格局。站在点上、线上还是面上、结构化模型思维,能够在一定的体系认知上看事情。
- 对职业的认知。对职业、职员、团队的认识。这些会影响人的职业规划、工作态度、责任心、团队合作力。
- 思辨力,即洞察事实真相和思考分析的能力,能够看到事情的本质。
- 避免二元论认知。即非黑即白。
- 能够举一反三。对于同类问题能从多个角度看待,有不同的解决方案。对于同类方案,可以延伸解决其他类型问题。
-
自我管理、自我驱动、自我优化能力。主动的力量
- 有明确的目标,并有可执行计划
- 有时间管理的意识
- 终生学习的意识
-
要性
- 我看阿里系招聘都很讲究要性。 要性是指个体主动想去参与推动、主导改变的一种过程态度、对追求落地和拿到结果的持续行为。说白了要有追求,积极向上、主动探索、主动推动改变,而不是被动执行。
- 不局限在自己的专业分工,也要对上下游、全局有理解和思考
- 技术热情。好奇心、 爱折腾,爱学习,爱总结。
- 自我驱动能力。自我学习、自我管理、自我优化。
- 不甘平庸、能自我证明。不满足于把事情做完,追求将事情做好、甚至是极致
- 总结能力。对自己、对项目、对团队、对公司、对行业有一定的总结能力,并能够推动进一步优化
-
有输出、有结果、有影响力。
- 这实际上也属于自我证明,除了管理好自己、还要去影响团队、影响业务、影响社区。
- 还有项目成果、个人产出
我有时候会在面试时问一些我自己也比较疑惑的问题,看他们有没有不一样的答案。
虽然我负责的是技术面,但我也知道,很多时候我们考察的一些基础技术问题,并不能完全体现一个人的真正水平。因此我会尝试多给机会让他们表达自己,花一些时间考察他们的软实力(或者说潜力吧)
大家身边应该也有挺多 一年、半年内,成长非常迅速的人,他们可能起步比较晚,后面能实现超越,大部分凭借着自己的要性。
我最近面试也问过这个问题,你的核心竞争能力是什么?你能做的事情可能别人毕业一两年,培训几个月可能也可以做?你怎么确保自己不被取代呢?
我得到的回答大部分是学习能力强、愿意吃苦、能独立完成…
能拿结果说明吗?
业务能力这个在本文提过好多次了,这个单独拎出来讲,是因为业务能力对技术人来说真的非常重要,也是很多前端开发者容易忽视的点。毕竟大部分人是做业务开发的,技术最终也是服务于业务,能不重要吗?
我之前也轻视业务能力的培养,也就是我给自己设置了边界,觉得业务是项目经理、产品、后端是事情,前端关注页面,关注上游给你的输入就行了。
这其实跟流水线工人有什么区别呢?
直到我换到另一个公司,他们全员都会参与产品评审、技术评审,开始我的状态是这样的:
会议中关键的几个人,产品、项目负责人、后端进入心流状态 ,各种业务术语满天飞, 有来有往,反应迅速,争论不休。
我发现自己跟不上(尽管我发现挺多人跟我一样),只是旁听、甚至走神的…
一开始我是比较抵触的,这种会议有的一开就是几个小时,对于进入心流状态的人,乐此不疲, 忘记了时间的概念。而我们这些对业务不熟悉或者关注程度不高的人会觉得浪费时间。
事后我也反省了下,主要是在自己的舒适区待久了,片面追求技术,忽略了对业务能力的培养。
产品自不必说, 后端是业务的主要实现方,他们对业务流程的梳理、业务建模玩得很溜,自然很容易参与进去。
至于怎么提高自己的业务能力,废话就是多去参与,站在用户、公司、实现等多角度进行思考。有兴趣同学可以参考文末扩展阅读。我自知业务能力薄弱,这方面比较强的也可以提点提点。
如果非得说一下自己的核心竞争能力,我只能说是自我驱动的反省和总结、优化能力吧。不甘现状,可以让你去发现和反省问题,总结和洞察问题的本因、最后再针对性地进行优化,螺旋式地上升
生命不息、步履不停
最近的一些感想,非喜勿喷
扩展阅读
本文提到的一些引用以及扩展阅读
普通的程序员和大神级的程序员有什么区别?
程序员业务能力
研发效率破局之道
10x程序员工作法
前端工程师是否有成为CTO的可能?
后端同学是不是比前端同学理解业务更快?
技术人员怎样提升对业务的理解
中台“搞砸”简史:成功的中台都是相似的,失败的中台各有各的失败!
技术选型指南
捕蛇者说:个人知识管理体系系列
JavaScript 20 年
心流理论
信息茧房这个概念如何理解呢?
PDCA 循环工作法/戴明环
软技能
程序员修炼之道
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/8890.html