一个草根前端人的焦虑

共 6118字,需浏览 13分钟

 ·

2021-02-05 12:19

大家好久不见,虽然变成了年更博客,但是我还是有坚持在用文字来记录我的学习和生活的。

首先给大家安利 Notion 这款笔记应用,这一年它确实给我的生活带来很多改变,举一些应用例子:

  • 博客。以前我习惯用 Markdown + Github 来维护我的博客
  • 日常学习笔记、文档。之前习惯用 MindNode 思维导图
  • 任务管理,不管是个人时间管理还是团队项目协作。
  • 写日记、周报、总结。之前用 Day One
  • 记账等等

除了 VSCode,Notion 是我第二个重度依赖的工具。

功能强大倒是其次,重要的是我可以随时随地去写东西,只要打开一个网页就可以了,我可以丢弃掉其他杂七杂八的工具。这种便捷性,让你找不到借口不去写点东西。

它就像一张白纸,会让人有一种提笔去写写画画的欲望。

5c4a2c9f40910a5e6bfb65c0c5a686fc.webp

实际上我现在很多生产工作只要一个浏览器就可以完成了。比如我最近就在使用 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 型人才,在多个领域都有深度,这种可遇不可求。

cbbd90de829fd07537231ff17ad862e3.webp

也许这里的问题在于大部分人并不清楚自己要往哪个方向发展,眉毛胡子一把抓什么都学,祖国需要我去哪里我就去哪里。你也是这样吗?

就前端的细分领域就有跨平台、Iot、数据可视化、NodeJS...

这些领域也不断在扩展、以及和其他领域进行交汇,比如AI、Serverless、大数据...

怎么选择还是看自己的喜好,以及是否有平台进行实践。说到底还是那句话,不要给自己设置边界。

除了避免主动性的边界设置,也要提防被动的信息茧房。这是后话了



核心竞争能力是什么?

对于技术人,技术是立身之本。但是想想自己掌握的技术门槛并没有那么高啊?你会JS、HTML、Vue、React,别人无基础培训几个月出来的也可以‘一把梭’。再说你老了,拿什么跟年轻人去争福报?

这也是我经常问自己的问题。尤其是在日复一日,每日重复拧螺丝的日子里。


对于核心竞争能力,我觉得可以分为两个部分:

首先是硬的。即上文说的,你的技术广度和深度,这体现了你的专业水平和横移能力。这些技术深度和广度是不断学习和累积,不是几个月培训就能实现的。

其次是软的,这个涉及很多方面,比较抽象。早早聊这个面试专题不错(二次GG、早早聊记得给我打she),通过大厂招聘给我们描绘了一个优秀技术人的画像。加上我的理解,整理了下:

  • 基础能力

    • 逻辑思维。
    • 学习能力
    • 沟通、协作、组织能力
  • 扎实的专业知识、包括理论和工程

  • 有独特的亮点

    • 对某一领域、某些技术有深入了解
    • 业务能力。这也算一个领域
    • 对产品技术全局有清晰了解,能发现业务及商业模式的短板,并提出解决方案
    • 对公司的业务发展甚至战略有独立见解、能够解决业务痛点、带领或影响业务发展
    • 清楚自己在公司的业务价值,并尝试提升自己的业务价值。
    • 能全流程参与项目业务建设(包括调研、建模、设计等);
    • 清楚自己做的项目的业务目标,用户是谁?目标是啥?你在其中有哪些贡献,项目的结果是什么,能否用数据说明?
    • 说小点 - 项目
    • 说大点 - 公司
    • 说远点 - 行业
    • 深度。
    • 广度。比如后端、运维、测试、跨平台、AI等等
    • 体系化。更进阶的是形成一套体系化的知识网络,从点、线、到面
  • 认知

    • 对自己认知。明确自己的定位和业务价值,有清晰的目标和职业规划。
    • 对专业认知。是看对技术维度、深度的理解和格局。站在点上、线上还是面上、结构化模型思维,能够在一定的体系认知上看事情。
    • 对职业的认知。对职业、职员、团队的认识。这些会影响人的职业规划、工作态度、责任心、团队合作力。
    • 思辨力,即洞察事实真相和思考分析的能力,能够看到事情的本质。
    • 避免二元论认知。即非黑即白。
    • 能够举一反三。对于同类问题能从多个角度看待,有不同的解决方案。对于同类方案,可以延伸解决其他类型问题。
  • 自我管理、自我驱动、自我优化能力。主动的力量

    • 有明确的目标,并有可执行计划
    • 有时间管理的意识
    • 终生学习的意识
  • 要性

    • 我看阿里系招聘都很讲究要性。要性是指个体主动想去参与推动、主导改变的一种过程态度、对追求落地和拿到结果的持续行为。说白了要有追求,积极向上、主动探索、主动推动改变,而不是被动执行。
    • 不局限在自己的专业分工,也要对上下游、全局有理解和思考
    • 技术热情。好奇心、 爱折腾,爱学习,爱总结。
    • 自我驱动能力。自我学习、自我管理、自我优化。
    • 不甘平庸、能自我证明。不满足于把事情做完,追求将事情做好、甚至是极致
    • 总结能力。对自己、对项目、对团队、对公司、对行业有一定的总结能力,并能够推动进一步优化
  • 有输出、有结果、有影响力。

    • 这实际上也属于自我证明,除了管理好自己、还要去影响团队、影响业务、影响社区。
    • 还有项目成果、个人产出


我有时候会在面试时问一些我自己也比较疑惑的问题,看他们有没有不一样的答案。

虽然我负责的是技术面,但我也知道,很多时候我们考察的一些基础技术问题,并不能完全体现一个人的真正水平。因此我会尝试多给机会让他们表达自己,花一些时间考察他们的软实力(或者说潜力吧)

大家身边应该也有挺多 一年、半年内,成长非常迅速的人,他们可能起步比较晚,后面能实现超越,大部分凭借着自己的要性。

我最近面试也问过这个问题,你的核心竞争能力是什么?你能做的事情可能别人毕业一两年,培训几个月可能也可以做?你怎么确保自己不被取代呢?

我得到的回答大部分是学习能力强、愿意吃苦、能独立完成...

能拿结果说明吗?

业务能力这个在本文提过好多次了,这个单独拎出来讲,是因为业务能力对技术人来说真的非常重要,也是很多前端开发者容易忽视的点。毕竟大部分人是做业务开发的,技术最终也是服务于业务,能不重要吗?

我之前也轻视业务能力的培养,也就是我给自己设置了边界,觉得业务是项目经理、产品、后端是事情,前端关注页面,关注上游给你的输入就行了。

这其实跟流水线工人有什么区别呢?

直到我换到另一个公司,他们全员都会参与产品评审、技术评审,开始我的状态是这样的:

5c419acbba514c1f6101382d0491c154.webp

会议中关键的几个人,产品、项目负责人、后端进入心流状态 ,各种业务术语满天飞, 有来有往,反应迅速,争论不休。

我发现自己跟不上(尽管我发现挺多人跟我一样),只是旁听、甚至走神的...

一开始我是比较抵触的,这种会议有的一开就是几个小时,对于进入心流状态的人,乐此不疲,  忘记了时间的概念。而我们这些对业务不熟悉或者关注程度不高的人会觉得浪费时间。

事后我也反省了下,主要是在自己的舒适区待久了,片面追求技术,忽略了对业务能力的培养。

产品自不必说, 后端是业务的主要实现方,他们对业务流程的梳理、业务建模玩得很溜,自然很容易参与进去。

至于怎么提高自己的业务能力,废话就是多去参与,站在用户、公司、实现等多角度进行思考。有兴趣同学可以参考文末扩展阅读。我自知业务能力薄弱,这方面比较强的也可以提点提点。

如果非得说一下自己的核心竞争能力,我只能说是自我驱动的反省和总结、优化能力吧。不甘现状,可以让你去发现和反省问题,总结和洞察问题的本因、最后再针对性地进行优化,螺旋式地上升

生命不息、步履不停

最近的一些感想,非喜勿喷



扩展阅读

本文提到的一些引用以及扩展阅读

普通的程序员和大神级的程序员有什么区别?

程序员业务能力

研发效率破局之道

10x程序员工作法

前端工程师是否有成为CTO的可能?

后端同学是不是比前端同学理解业务更快?

技术人员怎样提升对业务的理解

中台“搞砸”简史:成功的中台都是相似的,失败的中台各有各的失败!

技术选型指南

捕蛇者说:个人知识管理体系系列

JavaScript 20 年

心流理论

信息茧房这个概念如何理解呢?

PDCA 循环工作法/戴明环

软技能

程序员修炼之道

最后




如果你觉得这篇内容对你挺有启发,我想邀请你帮我三个小忙:

  1. 点个「在看」,让更多的人也能看到这篇内容(喜欢不点在看,都是耍流氓 -_-)

  2. 欢迎加我微信「huab119」拉你进技术群,长期交流学习...

  3. 关注公众号「前端劝退师」,持续为你推送精选好文,也可以加我为好友,随时聊骚。


cf7c282a76b96d0950efe0bbbbb1b3fc.webp点个在看支持我吧,转发就更好了




浏览 37
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报