关于职业的一点忧虑和思考

很久以前在知乎上看过一个问答,对比几十年前,有哪些消失的职业

当时看了几个答案就挺感慨,今天在路上又想起来一个。在大约20多年前的时候,收水费和查电表绝对是个好职业,挨家挨户去转着看一眼多少字了,收收钱。基本不会特别辛苦。

但今天早上的时候才意识到这个职业真的要快消失了,现在电卡都已经是远程上网的,水卡的改造据说也在进行中。将来所有人都可以在支付宝或网上直接购电购水,那既不需要上门查表也不需要上门收费。

现在想想其实职业变迁还是非常频繁的,如何才能识别哪些是会被淘汰,哪些不会呢?

1. 从事一些毫无技术含量的职业。例如上面说的查水表,电表,与此对比的是水电的修理工这个职业是不会消失的,但也随着现在水电设备的质量越来越好工作量会降低。

2. 依赖于某些体制的职业,在这个体制被打破之后这个职业会被迅速消亡。例如原来的国有粮店职工,原来绝对是金饭碗。但所依赖的供给制被打破后,这个职业迅速消亡。

3. 从事一些技术类工作,但这个工作有可能被大规模工业化所代替。在一旦大规模工业化之后也会被迅速代替,例如原来的纺织女工,在一旦大规模工业化的设备投入生产,她们基本只有下岗一个途径。

我的预计是未来的20年后,现在的各类专职司机,出租车,公交车司机都可能完全下岗。在自动化驾驶商用之后,这个职业的可替代性实在太强了。未来路径自动规划,自动驾驶,出租车(专车)客人上车后自动调整到喜欢的温度,音乐,蓝牙自动连接,可以在车里打电话,办公,休息。不用还要想着和司机搭话,不用担心司机熬夜开车,不用担心绕路。只要这样的技术成熟,司机下岗绝对是势如破竹。

其实反过头来想想,那作为码农呢,码农会不会被代替?我的直觉是“会”,而且一旦发生可能会更猛烈一些。一旦人工智能更深入一些,那写所谓的边界条件的测试用例,进行压力测试岂不是很简单?写简单的get/set,写一个service然后加一个impl,可能简单的事情完全可以代替,更深层次的也一样有可能。

所以没有其他办法,保持学习,不让自己在一个可替代的位置长期待着。

时间: 2024-10-10 23:47:33

关于职业的一点忧虑和思考的相关文章

关于MultiDex方案的一点研究与思考

背景 产生65535问题的原因 LinearAlloc问题的原因 Google提出的MultiDex方案 MultiDex实现原理 缺点 美团的多Dex分包动态异步加载方案 多Dex分包 异步加载方案 参考资料 关于我 背景 目前来说,对于使用Android Studio的朋友来说,MultiDex应该不陌生,就是Google为了解决『65535天花板』问题而给出的官方解决方案,但是这个方案并不完美,所以美团又给出了异步加载Dex文件的方案.今天这篇文章是我最近研究MultiDex方案的一点收获

设计模式的一点总结和思考(一)创建型

面向接口编程 对于当前不知道或无法确定的东西,我们就抽象它,只对其接口操作,即现在不知道具体的涉及对象,但我知道如何使用它,先用其接口,待以后知道了具体的对象之后,再绑定上即可,这就是所谓的封装变化. 虽然不确定目标是谁,但可以确定如何使用目标. 多种多样的设计模式其实做的就是 封装变化 ,面对不同的情景,分析什么是变化的,什么是不变的,封装变化,使上层代码能够"以不变应万变". 简单工厂 [严格来说其并不算是一种设计模式,其就是把一堆判断创建的语句放在了一个函数中,通过传入的参数决定

一点困惑和思考

在学习c++中,a+=b,那么就同等于a=a+b 但是在python中是否如此呢. 所以就有了 a=[100] a=a+a #此时a=[100,100],但不妨思考一下,地址还是最开始a的地址吗 于是有了我尝试的以下代码 1 a=[100] 2 print(id(a)) 3 4 a=a+a 5 print(id(a)) 6 7 b=[100] 8 print(id(b)) 9 10 b+=[100] 11 print(id(b)) 然而得到的结果却是 3071558316 3071558444

程序开发与需求分析的一点疑问与思考

静静的坐在出差归往西安的火车上,想着工作以来程序开发过程中的磕磕绊绊,总觉得不入其法. 并不是编程技能得不到提升,而是程序开发出来与甲方领导的想要的相差甚远.虽然做了很多工作,可领导关心的往往却没有做或者没有达到领导想的那样.在冥思略想之下,这也许就是沟通不到位,需求不到位的恶果.有人可能说,那你去沟通啊,去做好需求啊!哥,我也想啊,可人家领导忙的很呀,只能通过领导讲的大概,自己去琢磨.也许该读读项目管理方面的书,技术在牛逼,连需求都不清楚,做出来是什么鬼??. 第二个就是专业性.通过几次给甲方

一点BPXA的思考

懂的人自然懂... BPXA功能配置 这个概念现在还有印象,记录下来: 一,BPXA是用于BP使用第三方资源的.如使用ORACLE数据库,就是在XA里配置.它的特征是以<xa>开头 二,BPXA有自己的KCXP队列.这个队列是自己的,还是寄生在已有的KCXP队列中,无影响. 三,BPXA在配置KCBP之间的交换资源时,是将一个BP里的队列转发到另一个队列里去. 四,所以,源BP队列里是要配置TRANSFER队列,且收发和DISPATCH配置相反.(SEND,REQ,RECEIVE,ANS).

进一步对泛型集合的思考

一.前言: 经常听师哥师姐们说底层这个底层那个,从没见过这个"底层".后来师姐就在项目中应用了这个底层类库,从听说它到自己亲自用它,才发现它还真是强大的不得了啊!经常跟着师哥师姐们的课听,就是想跟这个底层混个"脸熟".我也经常是不懂装懂,其实真正听懂的也没多少啊..不仅脸熟了,还脸皮厚呢.. 言归正传为什么又提起泛型集合了呢?第一次接触是在机房重构的时候,Data Table转换成泛型集合.后来敲这个系统的时候,看到封装的类库中绝大多数的返回结果都是泛型集合.委托和

关于Java并发编程的总结和思考

编写优质的并发代码是一件难度极高的事情.Java语言从第一版本开始内置了对多线程的支持,这一点在当年是非常了不起的,但是当我们对并发编程有了更深刻的认识和更多的实践后,实现并发编程就有了更多的方案和更好的选择.本文是对并发编程的一点总结和思考,同时也分享了Java5以后的版本中如何编写并发代码的一点点经验. 为什么需要并发 ??并发其实是一种解耦合的策略,它帮助我们把做什么(目标)和什么时候做(时机)分开.这样做可以明显改进应用程序的吞吐量(获得更多的CPU调度时间)和结构(程序有多个部分在协同

关于个推的一点想法

最近项目中用到了个推做推送,关于个推的接入步骤官网有很详细的步骤,这里不说,不过正是由于使用个推,引起了一点其他的思考,那就是个推是怎么做到即便把app应用进程在后台杀掉,也能接受到消息. 说到这个问题,先说一个我日常时候android app的一个体会,我们经常打开某一个不常用的应用,打开的同时会弹出很多这个app和其他不常用app的推送消息(注意是其他且不常用的app).为什么呢?因为好多推送平台都使用了一个叫"看护联盟"的东西. 个推官网上说,个推的sdk可以在后台常驻且不会耗费

小规模软件开发团队现存问题思考若干

小规模软件开发团队现存问题思考若干 这里指的是创业初期的软件开发团队,由于面临较大的财政压力,不得不接一些外包来养活自己,然后再抽时间做自己的软件或平台的小规模创业团队.本文系自己的一点浅显的思考,观点较为浅薄,如果存在错误的地方,还望有经验的大神们指正. 一.创业初期的软件开发团队,大多存在以下几点问题: 1.没有产品经理: 没有产品经理,导致软件系统架构设计过于随意,而且项目人员搭配不均衡,最终导致存在以下几个详细的问题(1)设计思路不一致(2)软件流程不一致(3)各终端与后台字段命名不一致