技术人员的成长与使命

发布于:2022-12-13 ⋅ 阅读:(415) ⋅ 点赞:(0)

迷茫的我

作为一名工龄六年的技术人员,回顾起技术成长之路,发现还真是一路坎坷,从努力学习各种技术知识、技术工具,再到工作时的面试造航母,入职拧螺丝,从事着根本无法提升自己技术水平的工作再到我到底为什么工作,工作的意义到底是什么的灵魂拷问,不断重复着迷茫、摸索及前进这三个阶段,跌跌撞撞的也走到了今天,也算了有了拨开云雾见青天之感,我想着应该有很多技术人员和我有着一样的迷茫,所以打算写下这篇文章,纯属个人经验之谈,不喜勿喷。

2012年的我考上了一普通大学,选的是软件工程专业,那个时候,我根本就不知道什么是软件工程,除了偶尔去网吧上网玩玩QQ和游戏,我生活中几乎从未接触过电脑。大学期间学习的第一门编程语言便是C语言,记得每当完成一个小程序的开发总是能给我带来无比满足的成就感,也就是那股成就感一直激励着我走到今天,也是到了后面我才明白,那股成就感的由来是源于我对编程的热爱,我喜欢敲代码,看着自己输入的一串串代码在电脑上运行起来,总是会让我心情愉悦。之后又学习了C++、Java、Python、Shell等一系列编程语言,我最喜欢的依旧是C语言,可能是接触的第一门语言,也可能是它的语言简洁,也可能是因为我用它完成了数不清的小程序和小游戏,直到后来我接触到Go,发现它语法更为简单直接,于是就开了我漫长的Go语言学习之旅。

大学的最后一年,学校鼓励大家出去实习,那个时候在考研和工作之间果断选择了去工作,毕竟读了这么多年书,可以说是够够的了,校招的时候就入职了一家六千人的金融软件公司,主要从事银行前置系统开发工作,这是人生的第一份工作,让我很兴奋,憧憬未来,我一定能成为一名很厉害的技术大佬,实习那一年碰到了很多工作经验丰富的前辈,接触了到了很多学校没有的知识,那时候可以说冲劲十足,但随着工作时间的增长,学到的东西越来越少了,后面可以说是一些相似的工作重复做,虽然有很多不同的业务项目,但是技术却始终停留在数据库的增删改查,我开始意识到这不是我想要的,我想成为的是一名技术大牛,而不是熟悉各种银行业务的业务人员,跟我之前的理想简直是背道而驰,大概工作了一年多我便离职了,跳槽去了一家游戏公司。

来到这家游戏公司后,对于一个从来没有游戏开发经验的菜鸟来说,可谓是很兴奋 ,什么都是新知识,新技术,于是又开始了我的埋头苦干,再加上公司游戏项目的奖励机制,让我不厌其烦的做出了一款又一款的新游戏,在薪资待遇上有了很好的提升,就这样又过了两年,我发现自己碰到职业瓶颈了,日复一日做这些游戏项目,技术根本提升不上去,长远来看根本不利于技术发展,于是我又再一次萌发了跳槽了念头,回顾上一家公司的离职经验,这次明显有了很多不一样的地方,我喜欢做游戏,它有各种各样游戏逻辑,看到自开发的游戏上线推广,用户量慢慢起来,让作为开发者的我很有满足感,再者我很喜欢公司的工作氛围,不像上一家公司,同事都冷冰冰的,这里大多数的同事都是同龄人,大家跟朋友一下朝夕相处,前辈们也很和善乐于提拔新人,所以除了我个人技术成长的问题,可以说其他方面我都很满意,所以我开始认真思考跳槽到底是不是最好的选择。

首先我的问题是技术无法提升,换了一家公司就能解决个人技术无法提升这个问题吗,为了想明白这个问题,我做了一个假设,如果我真的跳槽到一家新公司,那么我会接触到新的人、新的项目和新的技术,新东西的学习自然会让人成长,但是当新的事物渐渐变成日常事务,新的项目又变成日复一日重复的项目,我又会碰到和现在一模一样的问题,这个时候怎么办,再一次跳槽?相信很多程序员五年三跳恐怕占这个原因的恐怕不在少数,所以跳槽解决技术成长的这个方案实在治标不治本。这种情况没持续多久上级就来找我沟通表示我们团队需要一个技术负责人,问我是否愿意,这对我来说是一个新鲜职务,所以一口答应了,随后便开始了两年技术团队负责人的职业生涯,在这两年我接触到了很多东西,比如说你的关注点不再是单个项目的开发效率,而是所有项目的开发效率要如何提升,团队成员的技术成长如何规划,面对团队开发人员的流失有何应对策略,原来业务部门对技术升级或者用什么技术工具从来都不关心,他们只关心如何快速上线功能,更新的时候保证线上服务稳定,老板希望并鼓励有技术创新,但当我们提出使用新技术新工具的时候却总是被各种理由反驳,原来写材料的能力在某些时候比你技术能力还要重要,各个技术团队之间如何高效协同工作,项目的优先级安排、代码服务器的权限安全等等,技术leader全要考虑。在这段时间,我有时候也会迷茫我还算是一个技术吗,感觉每天都在为了各种琐事量费时间,开不完的会议和做不完的决策。但随着和各类不同的人打交道、处理各种各样工作事物中,经历过两年内忧外患的折磨后反倒让我对技术成长之路有了新的理解。

技术存在的意义

顿悟最重要的一点就是技术到底为什么存在,核心思想就是:技术是为业务服务的:

  1. 技术所做的一切出发点都应该以业务为主,撇开业务谈技术没有意义。最简单的例子,一段很优雅的排序算法代码,如果不能解决实际的排序问题,那它没有任何业务价值。

  2. 技术部门就是为业务部门服务的,属于服务部门,一切让业务部门头疼的问题才是技术部门应该优先解决的问题。

人们永远会优先站自己的角度看待问题,即你觉得这个是问题它才是问题,这种情况在很多资深程序员中也能常见,有些资深程序员确实做过很多项目,技术也很厉害,但是他们不会去结合实际情况考虑业务方到底需要什么,举个很典型的例子,部门小A接手了项目B,这个时候属于业务低峰期,小A有时间和精力,于是打算做些项目优化,项目B属于赶工项目,之前有很多功能配置设计的十分不合理,这一点让业务人员使用十分痛苦,稍有不慎就会出现配置错误项目异常的情况,这时小A提出了目前较流行的服务高可用观点,认为服务不支持高可用到时候服务异常就会引起业务停摆,给部门带来巨大的业务损失,于是花了大量的时间和精力来钻研及升级服务高可用功能,之后小A依旧不断的不断的给项目B各种技术升级,熔断、限流,跟上服务开发的各种潮流观点,久而久之,由于项目B使用成本极高,业务人员直接放弃了项目B的推广,项目B成功的从服务高可用变成了不可用。每当看到这类事件我总是会反复问自己为什么技术人员会这样维护项目。假设一下,如果一昧的追求酷炫的技术、最新的潮流观点而不考虑实际情况,会变成什么样,盲目地学习在一定程度上能提升自己的技术水平,可是对实际存在的项目来说没有任何帮助,反而使公司的人力资源无法投入到最重要的开发工作上,技术提升目的是为了更好的为业务服务,但现在明显本末倒置了,变成了我想提升和体验技术而去改造业务项目,所以最终项目走向失败是必然的。

以上是一种很典型的技术思维,永远是站在技术的角度去看这个项目需要升级哪些功能,当问到为什么要升级的时候答案就是因为大厂都是这么做的,这是最流行的技术等等,但很少有人会站在业务的角度评估使用某种技术工具或者策略是否真的能解决业务本质问题。这时候作为技术人员估计就要难受了,项目不使用前沿的技术,日复一日跟着业务需求做相似的项目,那么技术岂非永远提升不了了。想要解决这个问题还得回到技术的源头,即技术是为业务服务的。优秀的技术人员永远都会站在业务的角度思考问题,特别是技术管理者,业务人员提出的业务需求是属于显性需求,这类需求在很多程序员眼里属于没啥技术含量的需求,就是把需求转换成代码而已,而在另一波程序员眼里却不一样,他们会为项目设计代码架构,拆分代码模块,把代码变得易扩展,并且后续迭代中会持续用一种近乎变态的挑剔眼光不断优化重构自己的代码,保证自己的代码高质量优雅,光这一点恐怕就已经打败了一大半的开发人员了,当大家都在仰望和羡慕架构师的厉害和全能的时候,又有几个能把自己实际项目的代码迭代地赏心悦目,还是只是纯粹完成工作似得,在已经惨不忍睹的代码上面继续破罐破摔。然后就是业务的隐形需求,这类需求映射到的其实就是我们技术人员追求酷炫的新工具新观点,为什么现在流行云服务、微服务、容器化、服务治理,还有经久不衰的设计模式,因为它们本质就是为了解决业务稳定及扩展的问题提出的新概念,从而创新出新的技术工具和各种开源框架等等,这才是技术存在价值体现。所以大家可以仔细回想一下,作为技术人员的我们是否真的有站在业务角度为业务考虑而使用某种新技术,而不是使用一些所谓的高端技术解决一些并不重要问题。

既然已经找到了技术存在的价值和意义,我们技术成长的方向就很清晰了,如何利用自己的专业知识为公司业务添砖加瓦。说到这一点就让我想到了一句话,仰望天空与脚踏实际,天空就是那些酷炫潮流、高大上技术,地面就是我们正在建设的业务项目,如果我们一直仰望天空就会把自己的路走的乱七八糟的,如果一直紧盯着自己的地面,久而久之也会迷失方向,所以我们要做的就是要把控这两者之间的度,深入理解业务场景与技术使用场景,找出本质问题,再利用合适的技术优先解决有业务价值的技术问题,这才是专业的技术人员要做的事情,因地制宜才是王道 。就举一些工作常见的例子,如果你负责的项目都是偏业务项目的,那么一线业务项目通用诉求是什么,稳定,快速迭代,降低开发成本,作为技术人员就应该围绕这三点去攻克技术难点,怎样让项目稳定的低层本的快速迭代,常见方法有搭建业务项目框架、相似业务功能组件抽象化开发、业务流程和业务逻辑剥离、配置化开发等等;如果你负责的项目是偏底层的项目,常见的就是通用功能框架通用性设计、技术标准约定、数据与业务隔离、系统架构设计、各类技术工具的调研对比、通用技术方案制定等等,各司其职,各自攻坚技术难点,这样才能让业务走得更加长远。

技术本身是没有什么高低优劣之分,黑猫白猫抓到老鼠就是好猫,技术应用也是如此,解决问题才是技术存在的意义。在我看来目前的技术环境,根本不缺少专业能力扎实、努力学习前沿技术的技术人才,缺少的是愿意站在业务角度持续推动技术优化升级的专业人才,不是说前者不重要,而是说后者才能真真切切的推动业务的持续发展与创新,并且引领着前者对技术应用一步一步升级优化。

技术人员的使命感

前段时间碰到一位很优秀的技术负责人,在他临走前跟我们开了一次告别会,把公司近一年的技术规划以及他为什么要这么规划跟我们讲了一遍,结合了许多自身方法论和经验,最后的一段话让我印象深刻,就是谈到了技术的使命感,作为一名技术人员,我们用自己的技能工作挣钱养家确实没什么问题,但是如果自身的专业技能仅仅用来挣钱养家未免也太过可惜了,你们目前城市所处的互联网环境相比于那些一线城市,如深圳、上海等地方是处于一个非常落后的阶段,相比于我这个外来人员,你们这群土生土长的人对这座城市一定更加有感情,你们一定是希望这座城市越来越来好的,所以为什么不尝试一下,用自己的技能知识建设一下这座城市的互联网圈子,为他人或者这座城市做点什么。听完这段话我还是挺久不能平静的,这是利他心理,我一直都知道这一点,但是我从未想过如何去做,他这番话点醒了我,让我有了想做什么的动力与冲动。

穷则独善其身,达则兼济天下。作为一名普通的技术人员,我还不到达这个程度,但也不至于穷,所以在工作之余,有时间有精力的情况下还是想为其他人做点事情,大事小事都行,这也是我愿意花费时间码字写下这篇文章的原因,写下了我的迷茫与成长,一来是不辜负自己走来的一路,二来如果能对他人起到一点点帮助和启发也算是好事一件了。经历过六年的技术之路的摸索,勉强对于技术成长和前进有了个初步方向,未来还有很长的一段路要走,我也不确定目前的道路是否是最优的道路,但是可以确定这一定是最合适我自己的道路,因为是我自己一步一步走出来的,走得扎扎实实,同时我想对那些还在迷茫时期的小伙伴说,迷茫并不可怕,可怕是停止自己对这世界的好奇心与探索心,只要你坚持不断摸索,迷茫期渡过是迟早的事情,人生没有白走的路,每一步都算数。

好了,本文至此结尾了,以上均为一家经验之谈,如有雷同,纯属巧合,如有异议,十分正常,在此希望每个技术人员都能找到自己的修炼之道,不负韶光,砥砺前行。


网站公告

今日签到

点亮在社区的每一天
去签到