这篇文章我很早就想写了, 工作至今 (10 年) 我对于技术这个东西的体会也越来越多. 今天触发我动键盘敲字的是一个事情: 我在准备做一个 golang 内存模型的 ppt, 准备节后给组内同学分享. 但是过程中遇到问题, 就谷歌了一下, 搜出了我自己 16 年写的一篇文章... 我才记起来, 16 年我看雨痕大神的书的时候, 研究过一阵子的内存模型. 我越阅读文章越尴尬, 倒不是因为文章有错误, 而是因为我对这段知识点没有任何印象. 于是, 我和小白读者一样, 重新和 16 年当时的我进行了知识的沟通.
于是我发了这么一篇微博:
对于这个事情, 我首先是很庆幸, 庆幸自己当时还留下了自己阅读的心得和文字. 但是转念一想, 更多的是恐惧, 恐惧的是, 我不知道我现在头脑里面的技术知识, 在几年之后, 又会在哪里? 唯一所幸我文笔还未辍, 几年之后的文章估摸大都还在我的博客中. 但是我头脑里面的东西呢? 我还会记得多少呢? 如果几年后这些知识注定忘记, 我现在还有必要学习么?
技术焦虑
现在的技术圈子很火热, 任何技术点, 任何知识, 只要你肯搜索, 都能找到资料. 但是现在技术圈确实有一个不好的地方, 就是贩卖焦虑. 这种贩卖焦虑的点并不在于形式, 而是一种普遍的心态. 特别是对于那种知识点比拼的心态:"xx 知道的东西好多, 好厉害! 我要向 xx 学习". 我一直宣扬, 这种心态千万不要有. xx 比你知识点多很多, 但是不代表他比你强, 比你厉害. 程序员如何比拼强弱? 要比拼的绝不是知识点的多寡, 而是使用知识点的能力强弱. 即如何使用你掌握的知识改变行业.
关于晨读, 各种账号确实现在很经常发晨读, 晨读这件事情, 我自己也坚持了三年, 现在开的群也在和几个人坚持发. 其实我自己也知道, 晨读这些内容恐怕没有几个人会看, 大多数人恐怕就是浏览了下标题. 晨读这个事情, 本质是好的, 它对收集和发送的人来说是最有利的, 基本上收集和发布的人至少需要大致看过这些文章, 这对发布的人是一种坚持学习的东西. 而但是对于看的人, 我自己也知道见仁见智. 如果这些晨读标题引起了自身的恐慌和焦虑, 我觉得绝对是得不偿失的.
前沿技术
聊聊前沿技术. 不管你现在是学习什么前沿的技术, 大致一句话应该是没有错的, 你所掌握的技术, 在你有生之年, 是会过时的. 这种过时的生命周期是从后端向前端逐渐缩短的. 我这里的后端和前端的方向是以靠近真实用户的距离计算的. 比如数据库, 操作系统这种技术, 距离用户最远, 用户基本不会感知, 他们可能几十年都不会过时, 从 MySQL,Linux 大致就能看出来. 再往前, 中间件技术, 缓存等技术, 大致十几年把. 再往前, 后端服务技术, 我认为生命周期应该是 10 年之内. 再往前, 前端技术, 我觉得迭代周期应该是 5 年之内了. 如果有工作超过 10 年的朋友, 应该对我这个时间估计也会有所赞同的. 迭代更新是伴随着技术红利的, 这里的技术红利指的是新技术的培训, 人员更新, 市场需求等. 越是更新换代快的, 越容易抢占这个技术红利. 在这个技术红利中, 会有一波人才缺口流出, 会有一波技术很强的人出现. 但是, 残酷的是, 这波人才缺口, 很多情况下是通过淘汰只掌握过时的技术的人员空出来的. 所以越靠近用户侧的技术人员越需要跟紧技术迭代的脚步, 否则一不小心就会被淘汰. 当然也不是说越往后端越舒服, 技术迭代慢同时也代表坑位固定, 因为在同技术领域沉淀很久的老人会把及格线带的很高, 所以基本需要沉淀比较久才能成为比较合格的人才. 而且靠近后端的人才一旦遇到技术迭代, 那么可能是毁灭性的, 究其原因, 恐怕一个是深入后端技术比较慢, 一个是新的后端技术坑更少.
是不是所有的技术迭代都是好的呢? 我的观点是肯定的. 新技术的出现一定是为了解决某种痛点, 或者填补某种空缺才会出现的. 但是, 大家往往忘记了, 技术是为了解决问题的, 有很多公司由于体量, 技术人员储备等条件, 根本不存在所谓的痛点, 但是也莫名其妙引入了各种时髦新技术. 技术都不是银弹, 使用新技术, 一定要承担新技术带来的成本和新痛点. 衡量一个新技术引入公司的决策是否正确的标准, 恐怕应该是业务是否得到提升. 这里说的业务提升, 两个方面, 一个成本侧减少, 一个收益侧增加. 在我看来的很多公司, 对于新的技术往往是为了革新而革新, 所带来对公司业务上的伤害, 恐怕更多于旧的技术. 所以架构师的价值, 特别是业务架构师的价值我认为体现在这里, 对整个公司或者部门的业务, 人员水平有一定判断, 选择合适的技术, 有时候, 甚至于拒绝新技术的引入也是一个成功的决定.
技术人员的发展路线
可以再聊聊技术人员的发展路线. 我认为技术人员的发展路线有两条, 一条是改变技术行业, 一条是改变业务行业.
改变技术行业的人, 这类人我认为现在在中国应该是比较少数的. 改变技术行业的人基本上恐怕究其一生, 最多只能改变一个, 至多两个技术行业. 这种人, 我认为可能必须有热衷于某个技术行业的觉悟. 基本上我觉得各个语言的创造者, 追随者算是这类人, 各种数据库, 大型开源项目的创造者, 追随者算是这类人. 这类人比如 MySQL 的精深专家, 基本需要在 MySQL 这个领域没有什么解决不了的问题, 而且对这个领域有持续的贡献能力. 但是我这十年所见, 确实遇到的非常少(可能是我的有限的个人经历所致).
成为改变业务行业的人, 我觉得应该是现在大多数的接触程序员所应该追求的. 我们之所以有工作, 是公司在某个行业希望有所建树, 有所作为, 所以雇佣你来做这份工作. 如果你不能让公司在这个行业有所发展, 那么恐怕, 你很快会被公司淘汰. 所以, 这点是我对所遇到的工作几年之后有职业迷茫的年轻人说的, 千万不要为了追求新技术而轻易换行业. 任何业务, 都有技术可以改变的地方, 只是你没找到而已, 没找到的原因, 恐怕就在于你的浮躁. 并不是人人都有机会追求各种高并发的 CURD, 但是人人都有机会踏踏实实写一些 CURD, 只要这些 CURD 在某个行业, 某个领域确实是起到了作用, 对公司起到了正面收益, 那么你的工作就是值得的. 代码无分贵贱, 能让代码起价值的, 就是你怎么使用这个代码改变你所在的业务行业.
所以, 对于大多数业务行业的程序员来说, 在几年期间, 选择一个你喜欢的 (或者你很看好的) 行业, 用各种技术来尝试, 改变它, 对自己也并不需要设限. 就和实验室里面做实验的科学家一样. 或许最后可能失败, 但是所积累下来失败的经验, 才是你真正的财富. 而且据我观察, 如果在某个行业真的长期沉浸思考的人, 最后它自己就会变成这个行业的稀缺资源. 各个公司所谓的技术总监, 大都需要有这种特质. 技术总监做的管理工作, 在这个视角看来, 是组织一批技术人员用技术改变行业.
总结
希望这篇文章能对刚工作几年, 觉得工作无聊的, 稍有焦虑的朋友们有点作用. 总之, 我的出发点是对于年轻的程序员来说, 年轻就是资本. 但是把年轻放在追逐各种新技术上而乐此不彼, 真是很大的浪费. 况且很多都是几年后就注定会淘汰的技术, 先明确自己的发展方向, 如果是业务型技术人员, 你的主线, 应该是多思考分析自己的业务, 自己的知识结构, 甚至于团队, 再决定自己的时间投入.
所以, 不要羡慕知道很多知识点的人, 而是要羡慕用这些知识点改变了世界的人.
来源: https://www.cnblogs.com/yjf512/p/11630606.html