3

前端这几年--13.关于技术开发的职业发展

 2 years ago
source link: https://godbasin.github.io/2021/11/28/about-front-end-13/
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

日经贴:程序员的 35 岁是天花板吗?35 岁以上的程序员都在做些什么?技术开发的职业路线要怎么规划?

技术开发的职业发展道路到底该怎么走?

现在的互联网团队虽然很多,但也有很多人在不断涌入这个行业,导致竞争日益激烈。对于很多企业来说,钱少能熬的年轻人似乎是更好的选择,因此程序员群体中也流传着“35 岁就会被淘汰”的说法。

曾经有一段时间,我遇到了一些比较难过的坎,于是认真学习了一些关于心理健康的知识,尝试好好调整自己。那时候便想,如今的社会发展和变化的速度太快,大多数事情都被要求“快速”、“高效”,未来很多人会选择进入企业打工而不是自己创业,各种精神上的压力都不小,焦虑和抑郁的情绪也逐渐变多,或许心理健康也会越来越受到重视,且被未来的社会高度依赖了。

焦虑和压力,如今成了当代快餐文化的赠品,技术开发也是如此。或许国外不少的程序员可以一直作为前线开发,而国内情况则不同,很多时候大家对于工作经验更多的技术开发的要求,不再满足于完成一线开发的工作,而是要求他给企业和团队带来更大的价值,比如做技术架构、技术管理、技术输出、影响力建设等等。

那么,面临这样的大背景,作为走在路上都会被人群淹没的普通开发,留给我们的机会又有哪些呢?

技术开发的深度和广度

很多技术开发在谈到职业规划的时候,都会考虑到一个点:技术的广度和深度到底哪个更重要更适合自己?

过去的我觉得,走深度还是广度,和一个人的喜好与规划有关系,比如,如果以后想当独立开发显然各种技术都要有所涉猎,如果想在某个技术领域扎根则应该要深挖。

我在之前的团队有接触过一些全栈开发,实际上不同领域的知识体系有差异,但大多数在工作中也做各自领域中比较普遍的事情(比如前端写页面调样式,后台写 CURD 逻辑),而全栈开发更是难有精力和心思去解决深入的问题。我也因为技术深度的原因来到了现在的团队,现在的业务场景的确已经是前端领域中复杂性排名很前的,慢慢发现其实再复杂问题,也都可以将其梳理并一一拆解,然后再逐个击破去解决。

追求技术广度,在工作中接触的技术领域会很多很杂,其挑战点在于是否可以对不同领域的技术知识进行足够的思考和归纳,找出不同技术的共通点以及各自的特点,并能选择合适的技术去解决不同的问题。追求技术深度,则需要在某个足够复杂的领域中,将其逐一拆解,逐一解决后,还能将新获得的知识再次归纳整合,优化在该领域的技术网络。

所以,我们常说开发的技术能力,其实更多时候是由各自的开发经验和项目经历决定,不管是广度还是深度,都有其可以出彩的地方,也有或许会让人觉得无趣的时候。而作为技术开发,唯一要避免的是 1 年的工作经验当 10 年用,这样即使工作了 10 年,也只是原地踏步。

上一篇我有讲到关于开发的技术门槛,其实在大多数开发的工作中,往往被低估的能力不是技术能力,而是工作能力(如沟通能力、理解能力、复盘能力、表达能力等等),不管技术能力如何,工作能力会更加直接地影响到我们的工作效果。

大公司的生存策略

我有时候会思考,像如今所谓 BAT、TMDJ 这些比较大的公司,到底喜欢怎样的员工呢?

一开始,我认为他们不喜欢特立独行的员工,实际上也大多如此。大公司里有很多部门和团队,但不管在怎样的团队,除了某些情况下会遇到技术突破的场景,大多数时候对技术开发的要求都是“快速”实现产品/老板需求,此时“听话”的员工会更“配合”和“响应”这样的快速变更。

但光“努力”和“听话”这样的品质显然是不够的。我遇到过好几个自己还挺喜欢的开发,他们认真负责、好学努力,也十分听从组织安排,却常常被甩锅和嫌弃不够“机灵”而被打低考核/开除。在我看来,他们只是缺乏一些职场经验,不够“油滑”,不懂得拒绝和保护自己而已,并不存在所谓“不够机灵”的情况。

我见过很多团队在招人的时候,都喜欢说要招“聪明”的开发。我不喜欢用是否“聪明”这样的词语去描述其他人,我也不认为我们有资格去给别人贴这样的标签。

这样算来,大公司的团队对开发的要求,不仅需要“努力”和“听话”,还需要足够“机灵”和“聪明”。这其中甚至没有多少是与“技术能力”有关系的,当然前面我也有讲过,对于开发来说,技术能力已经属于必备能力了。

除此之外,前面我也有提到过,大多数大公司内的技术开发,相比真正做好一个产品,更多时候会更优先考虑自身晋级/考核的情况,常常会事与愿违地做一些未必最适合业务场景,但更适合拿出去讲(吹水)的技术方案。

小团队的技术天花板

以前我觉得大团队很厉害,比如光前端开发就有一百多号人,肯定有不少的技术积累和沉淀,也能学到不少的东西。一般来说,复杂场景的业务才需要用到这么多某个领域的开发,实际上大团队对团队管理和氛围的要求更高,毕竟鸟儿大了什么林子都有。

我有时候也会想,是不是选一个好点的小团队问题就少一些了,不过大多数小团队在业务发展迅速的时候,最终都会演变成大团队,能将团队控制在小团队协作的情况不多。如果只想呆在小团队里,可能只有少量的垂直领域业务、发展平稳的业务,或者运气好的话,就不会被各种疯狂变动卷到。

小团队开发的好处,在于少了很多不必要的沟通和协作,工作效率会好很多。当然,其实这也跟团队和业务有密切的关系,比如团队人员是否频繁变更,业务方向是否来回反复,这些都和团队和业务管理方式有直接的关系。从职业发展方向来说,如果遇上团队快速发展,(如果你希望的话)小团队可以有更多的机会往技术管理方向走。

很多人都觉得小团队肯定有技术天花板,认为大团队的技术能力肯定更好,其实这没有必然的联系。

对于想往管理方向的开发来说,小团队可能的确只能管理较少的人(除非快速扩招),而大团队则可以继续往上升。对于一线开发来说,其实团队的大小对个人影响不是非常大,直接影响到个人体验的,大概除了工资待遇,便是工作氛围、加班情况、开发效率和节奏等等,而这些未必和团队的规模有直接的关系。

说了很多,不管是技术路线该往深度还是广度走,还是该去大团队还是小团队,似乎都没有最优解。实际上,做技术开发这一行的很多人都未必出于热爱,我们也经常见到有人辞职去创业、考公务员、做老师。

如果问我,我觉得不管是被行业淘汰了、或对行业失去热情了,还是浑浑噩噩地一直焦虑地工作着,或是有了新的方向。不管什么时候,都要摆正自己的心态,只要人还在,只要还愿意继续尝试,一切都可以重新开始。不用太在意当前的状况,也不用着急和其他人比较,我们的人生还有很长的路在走,还有无数的机会让它变得有趣而精彩。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK