中国很多IT企业根本就不知道资深的含义!国内一个很著名企业老板曾经说过:在IT行业超过35岁的技术人员将被淘汰,所以不要35岁后的技术人员。导致整个业界尤其是在软件开发行业都在排斥年龄超过35岁的人员,也导致很多工程师为自己35岁以后的前途发愁而转行。因为很多人都认为IT行业是年轻人的行业,而软件开发就是吃青春饭,过了35岁就没用了。
很多企业也在自己的企业宣传中吹嘘:我们企业XX学历以上的占百分比的多少,平均年龄在25岁等。认为自己企业员工年轻了那才叫高科技企业,那才叫有创造性。其实我认为这一种很幼稚的想法。听了这些人的观念,我才明白为什么我们的IT企业很少有能成为IBM、MICROSOFT等国际大企业的原因了。
因为很多中国IT企业根本不理解资深的含义!
我曾经接受过INTEL公司的培训,他们来的工程师都40多岁了,一个行业搞了20多年,那是什么样的一个理解程度呢?有些人头发都白了,你根本问不倒他们。我曾经问他,你最喜欢的是什么呢,他回答说是技术,我问他长期做技术难道你不厌烦吗?他笑着说NO。我才理解什么叫资深的含义,我也才理解为什么他们能把技术做得那样好。
我们中国的公司为什么很难在短期内超越他们呢?因为他们的公司是依靠大量的这样资深的工程师的支撑才持续发展到今天。
我也曾经在日本公司工作过,才理解什么叫工作狂。很多日本人30多岁就白发斑斑了。如果你见了那些穿着整洁的西服,扎着鲜艳的领带,胡子刮得很干净,走路笔直,看起来年龄不大,但是头发却花白的人,多数是日本人。日本企业一般不轻易辞退员工,员工流动率也很低。一个人在一个行业或者专业一干就是几十年,甚至一辈子服务一个企业。在日本公司,就是写一个WORD文档甚至要写7、8遍。要求一个标点也不能错,格式要完全达到要求。你甚至都认为后面的修改都是在浪费时间,因为我们中国人认为能表达清楚,差不多就可以了,但是在日本人那里根本就不能过关。经过多次这样的训练,你就会理解什么叫日本的精工操作。我们的工业和日本差距大的原因,尤其在精工行业,我认为很重要的原因就是他们每件事上都做得很精细,一个行业内研究很深。而我们却很浮躁,长期已往就形成了差距。正是胡适先生所说的中国人差不多先生太多了,这就是差距。
从IT行业人才使用看,我们国家普遍存在年轻化和短期化。做技术开发的多数是年轻人,并且很多人今天学这个,明天学哪个,哪个上手快就学哪个,哪个行业工资高就学哪个。并且频繁跳槽,到了另外的企业后就可能做新的工作了,学新的技术了。这种不断的切换其实是一种资源浪费,就很难把一个技术钻研地很透彻,对于整个IT行业来说也是一种损失。许多企业也觉得现在的员工对企业的忠诚度不高,跳槽频繁。一方面因为个人的价值导向的问题,但是我认为最大的原因是企业追求短期效益、短视造成的。哪个人不希望稳定发展呢,但是很多企业就是用员工的青春,年龄稍微大了(仅仅超过35岁就认为大了)就认为不能干活了,员工就面临随时被辞退。开发哪个项目就招聘那方面的人,产品做完了就解聘很多人。好听些是战略裁员,不好听了就是卸磨杀驴。企业不养老,而社会养老前景不清晰,这样大家能不跳吗?所以整个社会都是处于浮躁阶段。浮躁的原因就是长久落后惯了,突然进入了快速发展期,看到了很多美国的财富神话,所以都普遍犯红眼病,浮躁病。这种行业的浮躁和短视能造就成大批的资深的专业人士吗?
从利益分配上看,我们国家很多IT企业也存在很大问题。有几个做技术的工程师最后能成为富翁呢?李彦宏那样很少,并且因为他做了老板才得到了价值体现。我们很多老板就很难和自己的员工尤其工程师共享企业发展的成果。在发展阶段,急需要人才的时候就很尊重你,等年龄大的时候就嫌弃,没有分配给长期利益。所以很多工程师年轻的时候就是牛马,就是工具,吃的就是青春饭。而在美国的很多企业,优秀的工程师们可以无后顾之忧,可以不为自己将来发愁,因为他们很多人都持有公司的股票,就是将来不工作了也是百万富翁。只要技术很强,一个工程师可以在他的专业领域一直钻研下去,不必为了养老而朝三暮四。这样不出成果都很难。
从价值取向看,我们官本位思想导致很多人都追求做管理,不去做技术。在很多美国企业,他们是分职能和技术两条线。一个高级技术人员职位可能不高,可以不是经理,但是可能收入比经理还要高,因为他是某个行业行业的专家。经理主要是协调资源,落实制度和计划的执行。而高级技术人员则负责技术实现,规避技术风险,并创新,开发出具有竞争力的产品。而在中国呢,如果你是一个技术人员,即使你很优秀,有几个人能在收入方面超过自己的上司经理呢,一个新来的年轻的MBA或者能讲几口英语的海归就能当上你的上司,收入就可比你高,支配资源的权利就可比你大。
如果在中国,30多岁了手下还不能领导一帮人,还在做技术,别人就觉得你很窝囊,就瞧不起你。如果你是经理了,则别人马上很尊重你,这样导致很分心,所以你不得不向上爬,做经理,高级经理,技术总监,CTO,才能收入高,地位高。但是等高升了,就不能做技术研究了。所以很多人做技术时间长了就去做管理了,有的去做销售了,总之转行的人很多。留下的如果没有一个头衔别人就认为是没出息。所以中国就缺少资深的技术人员。
在美国考高学历是为了做研究,在中国则是为了当官,为了能在职场上获得更高的职位。其实很多人也喜欢钻研技术,但是整个环境如此,价值观和个人喜好发生矛盾,最后价值观被扭曲,只能放弃自己喜欢的专业追求,去做管理了。管理的成就感就是地位高,技术的成就感就是对做出了对社会有用的产品。所以在中国能有几个官员被历史记住呢,但是袁隆平却将永远被后人和历史记住。
并且在我们企业,有些时候在上级看来,如果认为一个工程师技术很牛,就要提升你,但是被提升了,就离开了具体的技术岗位,管人了,不钻研技术了。所以这也是很大的人才浪费。并且很多人就不善于和人沟通交往,不擅长做管理。被提上去了却发现管理一团糟,就只得又下放,多数情况下这个优秀的技术人员最终选择了离开公司。所以我们很多公司为了表示对一个人的肯定,只能提升到管理岗位,而脱离了具体技术。所以都是受几千年来官本位思想影响很严重。这样导致我们的职业专业队伍被大大削弱。
从一个人的成长来说,想在两三年内出成绩,基本不可能的,是违背自然规律的。毕业后基本头2年是在混混沌沌中度过,头3年时间是学习阶段,5年时间是基本成熟阶段,8年时间后才是出成绩阶段。除非天才,多数的人都是按照这个阶段发展。假设按照大学毕业23岁计算,8年后就是31岁了。还没创造几年就35岁了。35岁就没人要了。这样能出资深的人员吗?当然超过35岁也有人要,但是你必须要么是名人,或者高级职称的,或者高学历的。但是现在有几人考职称呢?有几个默默做技术的工程师能成为名人呢?在传统行业35岁正是壮年和创造时期,正是担当技术骨干的时期,我就是奇怪了为什么在IT行业35岁就不能接受了?是那个著名企业家的误导,还是世人的偏见呢?
为什么有这样的观点呢,那是因为在前几年,IT刚兴盛,并且我们中国IT发展起步晚,年代短,所以基本上都是年轻人在技术开发,大学培养出了一批批的大学生加入了IT行业。好象很多年龄大一些的人跟不上时代了,所以那位企业家发出了那样的感慨。但是随着时代的发展,这种现象将发生改变。
从行业发展趋势来看,IT行业现在看来是高科技行业,不断有年轻人涌入,是一个不断创造财富神话的行业。但是IT行业其实也是一个大的服务行业,当IT硬件技术成熟起来后,将成为一个制造业。所以将来IT行业也将成为一个传统行业。一个新兴行业最后都必然成为传统行业,这是历史规律。现在很多人已经感觉到IT行业没有前几年那样好做了,钱难挣了。这其实是一种回归传统的自然现象。随着这种回归,则IT行业要长久发展,则也将出现传统行业的那种需求,需要资深的工程师们的支撑。
而我们要真正赶上发达国家,例如美国,日本,则需要改变观念。可喜的是,这种观点已经发生了改变。在华为那样的一些大公司,就很重视很有经验的工程师,里面拥有大量的超过30岁的比较资深的工程师。但是和美国那样的IT大国比较起来,我们的资深工程师就是他们的学生了。
我原来认为象自己这样做技术近乎十年的人,也算资深了。但是当为了解决难题,到一些美国的技术论坛上去,才发现那里才存在真正的牛人。很多都是美国人,他们很多人现在几乎40岁,还是在做技术,我到那里去就是请教问题的,是学生。在他们的个人介绍中,很多人在很小的时候,70,80年代就开始接触电脑了。我接触电脑比他们整整晚了20年,能相提并论吗?这就是差距。就如同游泳,一个人在一个行业沉浸了十年,甚至几十年,那种持续的用力,深厚的功底导致的解决问题的能力和熟练程度、创造性能和一个仅仅毕业才三年的人相比吗?
当然了IT技术发展日新月异,新技术不断推陈出新,令人眼花缭乱。今天JAVA,明天。点NET,J2EE,JSP;确实需要强的学习能力,年龄大了自然学习能力下降。年轻人当然脑子活,富有创意。但是聪明不能代替经验,并且多数情况下人的智商相差不大。所以不能仅仅依据此就认为否定了经验和思维能力。
当然了互联网行业有些例外,所以也就是有些人所说的,互联网行业是我们国家最有可能赶超美国的行业。以在美国纳市上市的中国企业的分布比例来看,也证明了这个观点。但是在软件开发和硬件设计行业,我们还有很多路要走。这些行业经验还是很重要的,还是需要资深工程师们的支撑的。而软件开发和硬件设计行业正是IT行业真正的核心和基础所在,是我们的软肋。所以将来必然需要大量的资深工程师。
所以大家千万别被别人误导了,要看清历史的发展规律。注重持久和执着地发展。
分享到:
相关推荐
CAD 技术发展历程概览_ 摘自 计算机世界报 CAD技术起步于50年代后期。进入60年代,随着在计算机屏幕上绘图变为可行而开始迅速发展。人们希望借助此项技术来摆脱繁琐、费时、绘制精度低的传统手工绘图。此时CAD技术的...
在深入讨论JVM(Java虚拟机)调优之前,我们有必要先了解一下虚拟机的基本概念和堆栈的区分。Java程序在运行时,所有的数据都存储在JVM的内存模型中。在内存模型中,有两大重要区域,即堆(Heap)和栈(Stack)。...
摘自:https://blog.csdn.net/qq_34218078/article/details/109591000
### 视频会议系统通用技术规范 #### 一、范围 本规范主要针对视频会议系统的通用技术要求进行了详细规定,适用于国内各类视频会议系统的设计、开发、安装与维护。其目的是确保不同品牌、不同型号的视频会议系统...
这篇源自北京大学研究生论文的文章主要探讨了网页技术和搜索引擎的工作原理,特别是网页消重和建立索引两个关键环节。网页技术在互联网信息检索中扮演着至关重要的角色,而搜索引擎则是获取信息的主要途径。 首先,...
迷你牛排配茄子,桃香油和白菜 从那个使可可饼干蛋糕配棉花糖奶酪奶油广受欢迎的女孩:一个新的奇妙食谱,会让您的舌头感觉像是一个处女公主,从未探索过她的口味! 您需要什么: 椰子油(应该是没有其他成分的液体...
不过,可以推测文档标题中的“csdn”可能是指中国的一个IT技术社区CSDN(China Software Developer Network),这是一处为软件开发者提供技术文档、知识分享、交流论坛的网站。但是,文档中并没有出现任何技术或IT...
本资源摘自一篇学位论文,主要介绍了基于 ASP.NET 技术开发的家政公司网站设计。论文首先介绍了家政行业的发展前景和市场需求,然后详细描述了家政公司网站的设计和实现过程。 需求分析 在论文的需求分析部分,...
互信息计算matlab代码基于密度的多尺度分析在密度变化的强噪声环境中的聚类 代码,数据,结果和补充材料 张天田博原 参考 Tian-Tian,Zhang和Bo,Yuan,“”, IEEE ACCESS ,2018年。 代码 注意:该代码是在Linux...
该资源只包含论文文档资料,电子设计论文运放的应用(摘自OHM丛书)提取方式是百度网盘分享地址
清洁代码开发人员清单 开发人员清单主要来自Robert C Martin的书Clean Code 目录 :bookmark_tabs: 命名事物 :Japanese_discount_button: 名称应显示意图 它应该告诉您它为什么存在,它做什么以及如何使用。...
**Ruby on Rails 101 知识点详解** Ruby on Rails(简称Rails)是一种基于Ruby编程语言的开源Web开发框架,它遵循“Don't Repeat Yourself”(DRY)原则和“Convention over Configuration”(CoC)理念,使得...
Anaconda指的是一个开源的Python发行版本,其包含了conda、Python等180多个科学包及其依赖项。 [1] 因为包含了大量的科学包,Anaconda 的下载文件比较大(约 531 MB),如果只需要某些包,...-------------摘自百度百科
” ----------摘自推特上的热门段子 社会工程学攻击伴随着APT攻击的持续走热,也变成了安全圈的热门词汇,而社会工程学个人认为并不是一门技术,大众所看到的玄之又玄的各种案例与奇技淫巧几乎是无法复制或者套用的...
使用Node / Express API设置TypeScript,然后从“ Node.js设计模式”(第二版)中添加一些注释。 资源: Node / Express + TypeScript的依赖项: sudo npm i -g typescript npm i express npm i -D typescript ts-...
单片机与运算放大器(运放)的结合在电子工程和自动化领域中扮演着重要角色。运放是一种集成电路,...《单片机-运放的应用(摘自OHM丛书)》这本书可能会涵盖这些基本概念以及更多高级应用,是深入学习和实践的好资源。
先进制造技术的发展背景、概念和战略 本资源摘自《先进制造技术.docx》,...本资源摘自《先进制造技术.docx》,涵盖了先进制造技术的发展背景、概念和战略,旨在帮助读者更好地理解先进制造技术的重要性和发展方向。
技术资料分享Stm32寄存器与库函数概览(摘自固件库使用手册)很好的技术资料.zip
标题《秋心_csdn》中提到的“秋心”可能是指秋天的情绪或秋天的意境,而“csdn”则可能是指一个平台或网络空间的名字,通常用作程序员、IT从业者技术交流的社区。由于内容部分并没有直接提供技术性的IT知识,而是以...
https://www.cnblogs.com/solitarywares/p/7629893.html require用于建立states之间的关系,这种依赖关系以<state name> : 的形式来定义 Requisites有两种形式,require和require_in,分别表示依赖和被依赖的关系