楼主所说即是为什么程序员年龄大了之后换工作会比较尴尬的原因,虽然都是搞IT的,但使用的编程语言技术细节千差万别 那种动不动就触类旁通的大神理论,想必也是学习天赋和精力无比充沛之人,大都已经成为神谈之论,现实中所见,寥寥无几 重新学习一门语言的对老程序员来说虽然是很快的,很多基础知识和思想相通,但要真正掌握一门语言拿去做事,是需要很长时间锤炼才能有所得 毕竟每种语言的infrastructure lib生态相去甚远,至于能否运用且要用得融会贯通,大量的文档需要去啃,如果不幸没有好用的轮子,还得自己造,更痛苦 所以在一门语言里熬成专家,或许比多门语言不间断的切换学习要来得长远些 addtoo 发表于 2020-09-29 05:49
回复 1楼dingdingdddd的帖子 行啦,java生态系够你吃到退休了。是最statically-typed的语言了,也就是说最健壮的大型系统大多是java开发的。C++的工作都没有死绝,java的20年之内是不会有大问题的。 另外,如果水平不是停留在ICC车来的10+年经验的调包侠的程度,应该有一定开发framework的能力了。迁移都是缓慢的,自己懂原理上手是不慢的。不喜欢就自己动手写一个。 从java往scala/python的技术栈乱跳,很致命。追时髦,把自己的技术栈全都清空了,才是最可悲的。 Spring Inversion of Control是极其笨重的,现在都是Micro Service的开发,Spring MVC,Hibernate那些东西不受欢迎了。不过这也是可喜的变化,太笨重了,我都不喜欢用。 千渔千寻 发表于 2020-09-28 21:34
Published with GitBook 工程师年龄歧视的真象 大龄工程师面对的技术挑战,是我最近碰上的一堵高墙,真的等撞上后才知道,并不是那么容易跨过,且愿意去跨过的。
以我为例,我的工程师生涯是随着Java 生态系一起成长的,十五年来Java 生态系的东西我大多有碰过,十年来同时还用了Scala 生态系的一些东西。但是去年换到一间五岁左右的软体公司,公司用的技术是Scala, GRPC, Akka, Slick, Sangria, Json4s, Consul, Envoy, Python, Airflow 等,我就有点适应不良了。
原因是,我本来就有一整套运作良好的软体架构跟函式库在我脑袋里面,这些函式库经过Java 生态系十多年来的验证,大大小小的功能都有支援了,然后Bug 也在十多年来被清除干净,有许多的最佳实例(best practice)可以参考,不用重新摸索,可以很快的变即战力。
像是Json4s 完完全全比不上Jackson-Json 这套函式库,但是因为这是Scala 原生的函式库,所以得到我们团队的采用。其他更不用说IoC 的架构,有Spring 或Guice 的架框辅着,可以更有效率的使用,但是我的前团队宁愿重新造轮子,用cake pattern 加上IoC 的观念,来把软体元件串接起来。
我在这个新团队中,被迫要把熟悉的架构,一个个都抽换掉,重新再摸索一个不同的函式库,看他怎用不同的手法解决同一个问题。对我来说,既使一个新的函式库有比旧的函式库好上10% 好了,对我个人的总生产力只有增加1% ,若是扣掉学习的时间,算上机会成本,对我反而是没有帮助的,同样的时间,我可以花在学习新的领域上面,扩展我的知识范围。
在这段时间,我体会到「技术是熟的好」,不管是什么技术,用上手就好,反正到最后分高下的,大多是对工具的熟悉程度最重要。大多数人是把二十多岁前接触的世界当常态,然后用一辈子在这个时间冻结的世界内,最佳化自己的生活方式。
知识探索的过程 Matt Might用了几个简而易了的图片清楚的形容了博士的工作到底是在做什么。
把人类的所有知识想像是一个大圆 当你小学必业后,你有一些理解 高中之后,你又多学了一些 到了大学,你开始学习专业领域 到了硕士,你又多精深了一些 到了博士班,开始读论文后,开始达到某个领域的最前线 放大 经过几年的努力,一直推进 总算,某一天,你有个小突破 这个就叫博士学位 但是别太自满,从巨观看来是这样的 新程式语言 为什么过去20 年来,我们有这么多的新函式库新语言兴起,然后热门了几年后,最后大多数公司还是回归Java 生态系,为什么软体产业要花这么多的心力,重造轮子,探索不一样的可能呢?
因为没有了这些从新造轮子的知识探索过程,人类的科技不会进步,所以软体业在可见的将来,都会一直发明新的语言,用不同的实作方式,来解决同一样的问题。
在过去的二十年间,有许多的语言兴起,如PHP、Java、C#、Python、Ruby、Java Script / Node.JS、Typescript、Coffee Script、Groovy、Kotlin、Clojure、Go及Rust 等语言,各有优劣,有些变成主流语言,有些在风头过了之后,就渐渐平淡下去。
如果你是软体行业的新人,你是否该追求新技术,还是要学习稳定好用的技术呢?这影响到了你未来的职场生涯。
像是矽谷的大公司,一定是选用最新最热门的技术,因为最新最热门的技术,才能吸引到源源不决的新鲜人加入公司,新鲜人才是公司的未来,需要这些劳动力来推动公司的业务。如果一间公司选用了非热门技术,那么使用者的总量少,挑选到一流人材的机会更就少了,而且这有可能变成公司成长的限制,无法找到足够的人材来推动公司的新业务。
而对于新鲜人来说,选用新兴的语言技术,有除了市场需求以外的好处;罗马不是一天造成,软体的复杂度也不是一天造成的;我常听到有人报怨Spring 太过于复杂,但是对我来说Spring IoC 是很精巧的,只是因为大环境的改变, Spring IoC 从一开始的使用XML 来设定,演化到使用自己的Annotation 来设定,最后是到Java 标准化的JSR-330 来使用,对于新进用户,只需要学习其中的一种就好。
我能够理解这些,是因为我跟着这个框架一起成长的,理解它在过去因为什么理由而做出变更,跟什么历史遗留做出妥协,为什么一个功能会设计成这样。也因此我建议新鲜人,要学习市场上新兴热门的技术。你可以从头,当一个框架很精巧时,把它的程式码读完,当它每一次新增一个功能时,想想,如果是你会怎么做,为什么官方会做出这些取舍。
技术是熟的好 但是在追求新技术外,你也要考量到,现在多数的新技术,是设计给大公司用的,除非你要一直帮超大型网路公司上班,你学习的技术往往是过度复杂,甚至是不合用的。
例如现在许多的开源专案,使用Protocol Buffers & GRPC 来做序列化(Serialization),把记忆体中的状态写到磁碟上或透过网路传送到远方,但是PB 的许多设计是为了减少通讯时使用的空间的,像是PB 会省略掉栏位的名称,用index 来取代,在内容上也会用一些方法压缩空间。这些做法对谷歌来说都是合理的,因为谷哥的资料量太大,如果可以省下百分之一的空间,那么就可以帮公司省下数千万数亿美金的网路传输费用及储存费用,但是大多数公司不是谷歌不是脸书,你的公司的网路流量连谷歌的万分之一都不到,不需要去做这些最佳化,而且有修改是无法向前相容的,是要靠人脑去做的调整的,例如把一个栏位从int 改成long ,等你的资料有1TB 时,再来考虑最佳化吧,程式设计师的工资是很贵的。
我是建议大多数人用json 来做RPC protocol ,用json 来做资料库内的blob ,用json 来做hadoop / big data 的格式, json 最大的好处是好读,大家可以用人眼就可以读他的内容,不需要靠其它程式来转换,而且json 的支援很广,不管是什么大数据框架都支援json 。我上一份工作,有一部份的时间,因为不同系统吃不同的格式,就花在json / protobuf / parsec 的资料格式转换上面。
扯远了,如果你学习一套运作良好的全栈full-stack 框架,例如像是Rails ,花个三年时间把他里里外外都摸个透彻,未来要做一个新产品,那么在技术方面的时程估算,将会较简单就估算出一个时程表,而且因为你对细节清楚,就更不容易因为细节出包,而影响到专案的时程。
至于对于新鲜人该走那一条路,是要追求新科技,还是摸熟某一套技术,我在下一章会有讨论。
行啦,java生态系够你吃到退休了。是最statically-typed的语言了,也就是说最健壮的大型系统大多是java开发的。C++的工作都没有死绝,java的20年之内是不会有大问题的。
另外,如果水平不是停留在ICC车来的10+年经验的调包侠的程度,应该有一定开发framework的能力了。迁移都是缓慢的,自己懂原理上手是不慢的。不喜欢就自己动手写一个。
从java往scala/python的技术栈乱跳,很致命。追时髦,把自己的技术栈全都清空了,才是最可悲的。
Spring Inversion of Control是极其笨重的,现在都是Micro Service的开发,Spring MVC,Hibernate那些东西不受欢迎了。不过这也是可喜的变化,太笨重了,我都不喜欢用。
你已经很幸运了。用了15年Java。 很多人用了15年C++,换工作才痛苦。
这么多语言的组合,是你公司的问题,不是你的问题。但是Annotation 真是烦,能不用还是别用了。
因为现在工作市场很好,所以大多数工程师没经验。
一篇文章太少
寫本書吧
那种动不动就触类旁通的大神理论,想必也是学习天赋和精力无比充沛之人,大都已经成为神谈之论,现实中所见,寥寥无几
重新学习一门语言的对老程序员来说虽然是很快的,很多基础知识和思想相通,但要真正掌握一门语言拿去做事,是需要很长时间锤炼才能有所得
毕竟每种语言的infrastructure lib生态相去甚远,至于能否运用且要用得融会贯通,大量的文档需要去啃,如果不幸没有好用的轮子,还得自己造,更痛苦
所以在一门语言里熬成专家,或许比多门语言不间断的切换学习要来得长远些
So true!
我是不是理解错了。。。Spring IoC和Spring MVC,Hibernate的关系不是你说的那样?
就是为了解耦而解耦,结果搞得如此笨重,一点都不直观,annotations满天飞。
这是好事啊。自己写一个小轮子,可以向领导邀功来。 说明自己可以造轮子
"Spring MVC,Hibernate那些东西不受欢迎了" 真是好消息
同哭中。