4

前端工程师,你是否感觉到焦虑?

 8 months ago
source link: https://www.fly63.com/article/detial/12616
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
658256974300e.jpg

有几个讨论前,我先来说结论。

  1. 你所在的公司环境!== 产业环境,如果觉得不理想,准备好换公司即可。
  2. 工程师都是在解决问题,可能是客户的问题,可能是应用的问题,可能是资料的问题,选一个你所在行的解决问题方向。
  3. 选好方向,自然要掌握好工具,工具的掌握比例,取决于你要专精的方向,在很多时候,他都是一个组合,在业界和众多前辈的经验中,我们都知道,不可能只掌握一个技能,就真的能「很好」的解决客户的问题。
  4. 所以多面向的知识基础,那是必须的,但倘若要做到很好,选一个领域专精,再和其他优秀的人合作,成为一个T型人才。

以上,就是一个很安全,基本上往这个方向走,都不会出错的发展路径。

说完之后,是否觉得有一种在说废话的感觉,道理我都懂,我就是做不到啊,让我们来拆解。

专案做完了,你得到最宝贵的是「经验」

年轻,最不值钱的就是时间,请用它去换取「经验」,我敢肯定只要你付出绝对多的时间,你就能得到比同龄人更多的「经验」

经验,是多么抽象浪漫的感概,很多年前我就常说的一句话「你是有10年的经验,还是一个经验用10年」

怎么验证这句话,等下看我第二点论述。

每次在专案开始前,很常和同事说的一句话就是,多想想这个要怎么做,因为只要你想通了,这个方法就是你的,这就是你的经验,不管到了哪里,他都会跟随你。

经验不是执行的过程,而是思考、思辨、执行时遇到的问题、解决思路等等体验综合,光是执行,这经验不值一提。

因为你无法对这个「回忆」做出任何的解释。

曾经有那么一个故事,我遇到前公司的成员来面试,因为都是认识的,所以对于内部的细节,大概都知道,所以当他在描述一些「经验」的时候,我更在意的是:

  1. 为什么要选择这样做?而不是那样做?
  2. 这样做之后,效果如何?如果再来一次,你会怎么做?原因又是为什么?
  3. 如果现在请你建议我做一样的事,你会怎么说。

如果你的答案是「我也不清楚,我主管交代的」、「我也不知道也」

那么不妨下次在做每一件事之前,问一下自己,问一下身边的人,为什么你要做这件事。

你和一年前,有什么不同

应该曾经被我带过的同事,都会被我问过同样的话。

如果你无法确实说出些什么,那么要小心,你可能就是那位「一个经验,用了10年」的人。

当然这些不同,不仅仅是说,你学会了用next js 13,你知道了什么前端监控,更多的事,你看事情的面向和深度上,有什么不一样的见解。

因为也只有这些思维,你才能理解甚至设计出更厉害的工具,解决更复杂或困难的问题。

很多时候,因为我们的认知有限,我们接触的事物也很有限,很容易误以为一些事物的进步,解释为「内卷」

因为或许当下的你根本无法理解,为何这些技术需要存在。

但过度的「知识焦虑」是非常不健康的,所以我们只需要量力而为,和自己比较即可,若你想要的进步多一些,你就努力一些,若你想要有些不一样即可,那你就放多点时间在其他兴趣上,这没有一定的标准。

但「强迫」自己改变,并非一件什么十恶不赦的事,不妨尝试看看,若你不满意现在的自己,那就改变自己。

学习思考问题,而不是好好的写Code

「我只想好好写Code」 member发自内心的说道

我说「当然可以」,之后,我也没再说什么。

不知道什么时候,有几本书我都会推荐同事有空必须阅读的,包括著名的《clean code》

然后见山不是山,所谓执行一些最佳实践,并非是真的为了「工程」,而是为了解决问题。

我们想想,为什么我们要那么在乎这些实作方式,因为实际上,我们每天都要维护和改动我们的程式,如果你乱写,可想而知之后要怎么改?

很常有人开欢笑,看自己三个月前的code,根本不知道自己在写什么。

所以有些前辈总结了自己的经验,「建议」你这样做,会更好,所以精髓并非是「用了」什么了不起的架构,而是你进行了不一样的改变,这种改变,不需要被肯定,这种改变,将会在你日后的工作中,渐渐体现出他的价值。

其他方法、框架、技术、其实也是如此,当你真的想要好好写code,其实背后含义是真,你如何优雅的解决问题.

如果你不去理解问题,你怎么能好好写code呢,因为你所谓的「好Code」造成公司大混乱,团队之间新旧交替无法平衡,业务功能无法交付,那么这时候,你坚持的「好架构,好方法」是不是真的「好」呢?这一点很值得我们反思。

不切实际的技术改动和盲目崇拜,往往会带领团队走向毁灭之路。

最后的建议,耐心

好的东西,都不是立竿见影,因为如果那么轻松就可以获得,那么它就无法表现出稀有性,既然不稀有,那就到处都是,既然到处都是,你就会知道。

工程师的价值体现就是资讯差异和技术差异。

你能带走的,就是这些差异所体现出来的价值,你给你自己和组织的价值,不然你想想,人家为何要花钱雇用你呢?

我也发现,有些工程师光是追求「认知」而不实事求是,那也是不行的,所有的技术都是必须,而且是基础,当然每个人都有技术缺口,都有不知道事,那不是什么丢人的事,不知道就不知道,基础好,举一反三,学一下就会了,重点是问题本身,而不是技术。

再次强调,技术还是很重要的,但那不是唯一要重视的事。

我很常给同事一些「难题」请他们回去思考,例如以下都是我问过他们的事情。

  1. 我有一个编辑器,怎么做同步编辑?
  2. 我有一个多语系网站,怎么设计一个系统让客户自己填语系,又可以很快整合到专案?
  3. 如何不上版,把网站转导到维护页。
  4. 如何做一个开放平台?
  5. 如何做一个售票后台?
  6. 只有一周,如何快速的把专案完成?
  7. 设计师一直改设计图(客户拿不定主意)怎么办?
  8. 如果不能用GA,自己怎么做前端资讯收集?
  9. 文案一直改个不停,有什么办法不让他影响开发流程?

不管单位小至只有10个人,到现在在台积电,这个习惯依然每天的围绕我,每天都列了许多待解决,但还没解决的问题,只要一有空,我就会弄脏手开始写解决方案,他可能是一个流程,也可能是一个工具,甚至是一个平台。

给自己一些耐心,坚持做对的事情,好的事情自然会发生。

来源:https://kimtoday.medium.com/前端工程師,你是否感覺到焦慮-7b313f8009a

链接: https://www.fly63.com/article/detial/12616


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK