原文刊于：https://elderengineer.github.io/book-sillicon-valley/52.html
# 工程师年龄歧视的真象
大龄工程师面对的技术挑战，是我最近碰上的一堵高墙，真的等撞上后才知道，并不
是那么容易跨过，且愿意去跨过的。
以我为例，我的工程师生涯是随着 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用了几个简而易了的图片清楚的形容了博士的工作到底是在做什么。
http://matt.might.net/articles/phd-school-in-pictures/
* 把人类的所有知识想像是一个大圆
* 当你小学必业后，你有一些理解
* 高中之后，你又多学了一些
* 到了大学，你开始学习专业领域
* 到了硕士，你又多精深了一些
* 到了博士班，开始读论文后，开始达到某个领域的最前线
* 放大
* 经过几年的努力，一直推进
* 总算，某一天，你有个小突破
* 这个就叫博士学位
* 但是别太自满，从巨观看来是这样的
# 新程式语言
为什么过去 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 ，
花个三年时间把他里里外外都摸个透彻，未来要做一个新产品，那么在技术方面
的时程估算，将会较简单就估算出一个时程表，而且因为你对细节清楚，就更不
容易因为细节出包，而影响到专案的时程。
至于对于新鲜人该走那一条路，是要追求新科技，还是摸熟某一套技术，我在下
一章会有讨论。