数据技术工程师成长之路

  最近或许有伙伴发现,写技术实现及细节的变少了,更多是经历以及思想、规范。莫非是道则道,非常道,你道我也道?然,并不是:)。

  当入行四五年时,个人经历中,从14年开始实习工作到15年转正,各电信项目现场跑,开发、测试、产品部署及支持运维。16年银行实时系统开发、测试、运维、部署,最后推进了MapReduce与spark引擎的变更。再到17年来阿里至今,从0到1 负责系统及未来发展的设计、开发、测试及运维 以及 开始推广运营。每一个项目都带来巨大的成长,有时候感觉这些年对自己的确挺狠的,心疼的保住不胖不瘦的自己,但是带来的成长也是巨大的,这里的成长并不只是技术或架构能力的成长。更多的是从一个小白胆怯到一个相信自己,能够把控项目、团队合作、把控风险、把控情绪的过程。这个过程很痛苦,很锻炼人,但是却能让自己更加的无惧未来。 就像我的博客中的个性签名,这个世界上,没有无缘无故的恨,也没有无缘无故的爱,更没有无缘无故的横空出世。这仍然是一个相信汗水和泪水的世界,所有的'被看到',所有的'能发光',都不过是在灰尘扑扑的日子里,不动声色,全力以赴的结果。那么在这里,分享一些自己的想法给大家:

  1、改变 
            简短的两个字,其实并不那么容易做到。我们都来自不同的家庭环境、不同的教育背景、不同的经历,会拥有着不同的价值观、不同的思想、不同的理想,为着马斯洛需求层次中的某一层而努力。  
         在每个通宵的夜晚,你是否也有过对人生的怀疑?是否有过,对未来的迷茫?又是否有过在种种迷茫、怀疑之下的坚持?又是否在坚持之后,能够带着前一次的自信,鼓起勇气,再次去挑战新的怀疑、新的迷茫以及困惑。举一个个人经历,在第一家公司时,更多的是产品研发部署实施为主。也许是年少轻狂,毕业不久为了女友裸辞,从北京到上海,新公司全部都是大数据技术,与曾经掌握的技能并不match。每天极为痛苦,因为你不再是应届毕业生,社招上来就要干活儿,对自己充斥着大量的怀疑,直到能够与小伙伴们承担整个数仓引擎改造。然而,到达一定时期后,觉得很舒服,拥有admin权限的你,拥有设计话语权的你,或许已经成为你的瓶颈。内心告诉我,要迎接挑战,要跳出舒适区,于是选择跳槽,简历投递时,点了阿里巴巴。(新人启示,不要觉得痛苦,觉得委屈,觉得压抑而放弃,每爬出来一个坑你就会看到更清晰的未来。任何的不舒服,不要直接认为自己不适合。换个态度去想,把它变舒服了,再去考虑你是不是更适合其他的。)

  
    2、先成为专家
    我们纵观软件行业,以我的认知来说,web技术,前端与后端开发,如果细分后端开发又分为客户端开发与服务端开发。 大数据技术,流处理(storm、flink、spark streaming....)、批处理(hadoop、spark batch....)、存储技术(mysql、oracle、hbase、分布式文件存储hdfs....)、消息中间件(floom、kafka....)。网络技术(socket、http、bio、nio、netty...),在各种技术应用开发的同时,也牵扯到各种数据结构、各种设计思想、数据字典设计、数据建模、数据架构等等等等。这里就牵扯到定位,就是未来你想要成为什么样的人。我记得曾经刚入行时,有一位微软的大牛曾经跟我说,不要什么都学,先成为专家,再成为百家。因为成为专家的历程中,必然会接触各种思想、理念,为触类旁通打好基础。那么无论系统开发也好、大数据开发也好、大数据技术也好、区块链、人工智能等等,专精于一个领域,必能小有所成。但下来,要说的是,技术也只是知识体系中的某一项。

 
  3、谦虚与合作
         我们搞技术的有一点,会非常崇拜技术牛逼的那个人,卧槽,你这都会,卧槽,这么牛逼,抱着大腿一起成长。但大家有没有仔细观察,大神的做事方法,大神的思维模式,同时会发现,技术大神一般都非常的谦虚,任由我们随意提出建议。而初出茅庐时,我们总担心身边的人觉得自己技术能力不行,担心人家笑话你。从而越来越不敢正视自己,推卸责任或是不敢承认是自己的问题,久而久之,我们的成长便会受限。 这里想说明一个观点便是,任何人说出的任何意见或观点,都一定有一定的理由在里面。不要一开始就反驳,或者一开始就否定,先思考是否是自己欠缺的,是的话,纳入自己的思路体系,不是的话,我们再就事论事的讨论。你的成长,与他人的看法无关。久而久之,你也会拥有谦虚的态度,也会拥有大神的思维模式。承认错误,这并不是懦弱,也不在于谁对谁错,而在于朝着同一目标前进。

 
    4、消除焦虑感
    行业有句话,35岁不转管理就会被替代。其实我一直有个疑问,35岁时,我相信软件工程师们都将成为某个领域或是某个业务线的架构师,那么架构师的定义是什么?系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展,为目标客户提供更为全面的需求清单(来自百度百科) 。我相信,一个架构师会具有管理的特质,也会具有很强的合作意识、风险意识、架构思想及处事不惊的态度。前十几年丰富的开发、设计、架构能力,能够游刃有余的把控任何风险。同时因为看透技术本质,对于新兴背景下产出的技术也会触类旁通。它就是我们眼中的大神。一个优秀的架构师,对于无论需求、设计、开发、测试、运维、项目风险、沟通合作、业务背景的理解丝毫不会亚于某一项专项的业务人员(不然做出来的是客户不要的?),架构师的价值不亚于任何管理者。

 
    5、体系总结 与 开放思维
         这两年跟着师傅取经,有一个非常有用的方法,就是将自己学到的,实践到的,领悟到的画成知识图谱,时常温故。记得早年最笨的方法,就把一整本书先硬啃下来,工作实践后,再去啃一遍,直到融会贯通。后来当体系建立,在看相关书籍时,基本一遍看下来不再那么吃力。这时候千万不要以为自己会了,依旧开始第二遍细读,第三遍总结与知识图谱。但是软件工程的特性,必须实践后才会真正的领悟,那么看了后,只是做了简单的习题方法会不会没用? 踏实下来,当你要用到的时候,你会发现,原来没那么难。
         与此同时,我们容易被技术思维禁锢,大家都觉得做技术是有瓶颈的,那么有没有仔细思考过,到底瓶颈是在哪里?个人感觉,技术角度是创造、想象 与 推动。现在对于工程师的要求越来越高了,已经不像传统IT,做好一块儿就够了,更多时候我们需要和客户打交道 和 业务打交道 和 需求 产品 ,甚至有时候自己都会上去设计产品。这个思维方式的跳跃是很痛苦的,因为越是某项技术专家,越是无法理解业务是干嘛的,毕竟人的精力是有限的,注定会是某项技术的光辉支柱。但是如果不是对某项技术痴迷,想要成为统观全局的架构师,就需要不断地扩展,对于技术而言,也许技术专家是5分,那么你能达到3分。对于业务而言,能够洞察市场的动态。但同时还在于个人的视野、想象、背景、情商、修养、与格局,从而推动事物的发展。

 
上一篇:如何在小程序中调用本地接口


下一篇:【Android基础】listview控件的使用(3)------Map与SimpleAdapter组成的多显示条目的Listview