针对工作几年的程序员工程师,经常会遇到瓶颈,这个瓶颈不一定技术上的,也可能是职业发展上的.一般技术的职业规划会有两个方向
技术方向:
架构师,系统分析师,CTO
这种往往是走纯技术路线, 发展到最后都是在公司中深入某一块技术,例如存储,MQ,通信,等等,后面发展路线也往往是架构师/系统分析师,技术专家,高级培训师,然后就是技术总监
业务方向:
产品经理,项目经理,部门经理,CEO
我觉得业务方向更多的是关注项目,针对当前业务,非常了解业务的整个流程,而如果有些业务因为特殊性,会遇到技术难点,要么让公司基础技术部提供解决方案,要么扔给手下人去做技术调研以及技术攻坚,如果自己部门针对这个技术做出了很多成绩,那么可以分享推广到全公司去使用,大家都来调用你的接口,都来参阅你的文档,可想你自己也是非常高兴的.
可是我一直觉得,如果技术不懂业务,不了解业务痛点,没有产品思维,那么也无法针对技术做出改进,改善,业务驱动技术, 根据不同的业务,会有特殊的技术要求,实时性高,稳定性强,多数据聚合计算,等等,都考验了程序员的技术储备,亦或者技术攻坚水准.
这两天读了本书<<我编程,我快乐>>一眼看书名,我以为是某个国内无良人士出了一本骗钱的书,但是后来看到是外国著作,国人翻译,且豆瓣评论还不错,因此就耐心的看了下去,整体还不错,下面针对本书写一些心得
做一个通才
顶尖的程序员都往往是某一个领域的专家,其他领域大部分都是兴趣所致,你可以理解他不如专精领域那么厉害,但是也比普通程序员要厉害的多.
我们在项目中,往往不可能只使用一门技术,往往都是多门技术并行前进,因此多会一门技术就代表着多一种解决方式,多一个思考方向,也许新的解决方式往往比你固有的思维更加有效,这也是为什么现在流行混合编程
记住,是我们选择编程语言和技术,而非它们选择我们,同样的项目下,我用ruby写出的web应用更加迅速,30天也许就能发布上线,而你使用java也许需要3个月,而如果你用ruby去写通信服务,业务你30天就能搞定,但是远远没有java来的稳定,真正的大牛是针对业务场景去选择技术,而不是在某个特定的技术框框下去完成任务,因此程序员需要做一名通才,当然这个通才指的是某个领域中的通才,切记不能好高骛远,什么都学,什么都只会皮毛,那不如不学.
跳出自己的舒适区
很多程序员都会下意识的标榜自己是一名c++程序员,java程序员,ios开发,安卓开发,php程序员等等,但是他们往往忽略了一个事实,就是你首先是一名程序员,有意无意的将自己绑定在某个领域或者某一个语言上是非常危险的事情.
众所周知,摩尔定律,每18个月硬件行业会有一次革新,而软件行业也一样,当你的机器性能已经非常好,不用在关注性能本身,不用苛求运维在多分配一些内存给你,多一些带宽给你的时候,往往性能就不是那么重要,也许你说你用c++开发的服务性能高,但是跟开发的人力成本来对比,这点提高也许并不是显而易见的.如果你用java开发服务,那我觉得这个选择很可能是正确的,但是如果你用java去开发一个web后台,那我只能说,傻逼.因此跳出自己的舒适区,去学习更多的新技术,或者不一样的技术,也许你会有不一样的收获,也许你已经厌恶了面向对象编程,面向接口编程,实现某个功能,必须先去定义一个类型,或者接口的时候,或许你也可以试试面向过程编程,或者函数式编程.这也是函数式编程近年来很火的原因,因为随着硬件的发展,函数式编程在以后性能不给力的缺点已经慢慢被忽略,转而提现了他高并发的优点.
如果你这个时候还一直强调函数式编程性能不行的固有思维,那么你也许该考虑自己是不是该充充电了.
举个例子:
之前公司业务扩张,招揽了很多java程序员,但是因为我们公司原先架构都是php的,让那些java程序员来写php,他们整天嗷嗷叫,痛苦不堪,我原先觉得奇怪,难道php开发比java还难么
后来正面我错了.并不是php的门槛比java高,而是他们不肯跳出自己的舒适区,从心底生成了一种抵触的想法,从而导致他们工 作的并不开心,但是公司招聘你进来是为了创造价值的,真正厉害的程序员针对各种技术都是信手拈来,并且我相信,我学习到的 任何技术,在将来都是有用的.也许只是时间未到.在10几年前,你会想到带有GC和面向对象编程的开发语言会如此之火么?现在 又有哪个新兴开发语言没有这两种东西的.所以千万不要一直保留着自己那可怜的固有思维,试着跳出舒适区,也许你会看到新大 陆
对自己喜欢的事情投入100%的热情
我有个优点,也正是我的缺点,当我喜欢做某个事情的时候,我会投入100%的热情,说废寝忘食也不会过,因为这段时间内,我满脑子都是这件事情,甚至睡觉上厕所,吃饭,走路都会想着它,这样的优点让我能迅速掌握某个新技术,但是往往因为这样,也同样让我产生了.我是天才,学什么都很快的错觉,从而导致自己很多东西都学不精通就放弃了.我觉得以后需要更正这个错误的想法
比如之前公司项目中有一个图库,全国各地的用户上传图片到服务器,觉得非常简单,但是真因为非常简单,里面需要涉及的东西却非常多,各地的用户使用的网络环境不一致,他们的通信节点也不一致,怎么保证每个人的上传速度都是可控的.
当某个用户突然无法上传的时候,怎么办? 难道跟用户说我这里好好的,别人也是好好的就你那里不行? 因此我针对每个人的上传记录,做了一些记录,记录每个用户的上传速度,上传ip,以及上传文件大小,还联系cdn服务提供方,开启了服务日志,记录每个人的上传情况,并且增加了动态请求分配节点,防止某个区域某个节点突然挂了,而导致用户无法上传图片,这个系统刚上线的时候,基本上传1万张图片会有100多次的甚至1000次的失败,而现在,随着系统越来越完善,越来越稳定,失败次数已经降低到了两位数,甚至个位数.并且针对产品上也做出了相关的修改,例如友善的告诉用户为何会上传失败,是不支持图片大小,还是不支持图片格式,千万不要高估用户,用户不知道图片有多大,也不知道自己用的单反有多厉害,层级有个用户上传了个图片一直失败,结果我看了下那个图片有70多M,而我的服务当时最多就支持18M,虽然满足了大部分的请求,但是个别情况下也是会挂,最后我也修复了这个问题,
总结起这个项目,我觉得后期维护的期间,我学到的知识比开发期间多的多.因此我想说,投入100%的热情,并持之以恒,我知道这是非常难的事情,也正因为如此,技术专家,资深大牛才那么稀缺.
站在巨人的肩膀上
另外一点提高自己瓶颈的方法就是借鉴前人的代码,程序员这个行业,并不一定非要什么都不看直接写,也许你在有基础的情况下,直接开始写,遇到问题在查找问题会来的更加容易上手,但是正因为这样,你写出来的代码往往质量非常差,优化性不够,语法啰嗦,不够优雅,因此我们要学会多从其他人的代码中汲取优点,多逛逛开源社区,针对自己感兴趣的方向去学习别人的代码,也是进步的一种方法.最讨厌某个前辈或者资深人士说,看什么看,直接写,这样的说法是极其不负责任的.
做团队最差的人
做团队最差的人,当你觉得其他人都比你优秀,那么你自然而然就成为了最差的那个人,跟比你优秀的人工作,会让你更加的快乐,学习到更多有用的东西,也许宁做凤尾,不做鸡头也是这么来的,而做团队最差的人,往往可以有非常强的学习动力,以及非常迅速的成长空间.否则只有固步自封,100行代码写了一万次,有什么意义么?
学习如何失败
越早的发现问题,就能越早的弥补损失,你应该庆幸现在发现了这么多bug,而不是上线的时候,你也应该庆幸人少的时候发现了这么多bug,而不是用户拥堵的时候,如果你的软件没有定期向你抱怨,你就不知道危险的故障隐藏在哪里,此外带着防御性的措施进行编程也是很重要的.出现问题的时候,才是考验软件开发质量的时候,出现问题的时候,解决方法,解决思维也是检测工程师技术的时候,学习处理也是非常重要的.
1.因此发现问题第一时间提出,在开发和测试中,越早发现错误,造成的问题就越小,越早发现并且暴露自己犯下的错误,造成的负面影响也就越小
2.接受批评,也许这个问题并不是跟你有直接关系,也许只是间接关系,也许压根跟你没关系,但是当出现问题的时候,我们第一时间需要的是解决方案,而不是互相甩锅,我们的目标是在最短的时间内解决修复问题,在谁来负责这个问题上纠缠不清的后果就是拖延解决问题的时间.
3.寻求帮助,当我们遇到困难的时候,一定要学会跟团队成员互相沟通,寻求解决方案,而不是因为责任感和自尊心而掩饰问题,以及拖延问题,没有人不会犯错,越是及早的解决问题,越是能减少问题带来的负面影响.
说"不"
在团队中,经常会遇到需求方给你提出某个需求,也许你觉得这个需求不合理,但是还是碍于同事的面子抽时间给他完成这个需求,这个时候你在同事的眼里也许就是负责的好同事,但是也许你遇到的只是一个不动脑子,或者压根只是抱着试一试态度的产品经理,没有经过完整的调研,只是拍拍脑袋觉得用户可能会喜欢这个产品,没有做出需求调研就话了一个prd给你扔了过来,如果项目表现不错,你的努力受到了大家的认可,那么皆大欢喜,但是如果这个项目最后还是失败了.那么你付出的努力也会白白浪费,也许这个项目还是你抽空闲时间,大晚上熬夜写的.
所以在需求方提出需求的时候,你一定要问他,做这个功能的意义是什么? 你有数据做出支撑么? 这个功能对我们现有的产品会有什么影响以及正面作用? 没有数据支撑的需求一律说不. 我手上事情还没做完,就因为你一个拍脑袋想出来的点子,就让我陪你一起疯? 记住,战术上的努力并不能弥补战略上的懒惰,如果方向从一开始就是错误的,那么为什么要一直错误下去? 及早回头,悬崖勒马,也许有人会说,互联网就是不断迭代,不断试错的过程,那请问你在进行之前有经过详细的规划么? 有详细的数据支撑么? 如何看出你这个需求就是非常紧急,如何看出你这个需求一上线就会有N多的人乐此不疲的使用的? 如果没有,请你先去想清楚再来说话.试水的前提是我大概知道这个水有多深,而不是一无所知,不然为什么没有人去试海? 试洋?
上面都是从业务上面来说的.下面说说技术上
当你的项目经理问你是否能完成这个任务的时候,你模棱两可的说可以,也许行,好像行,也许你的项目经理只是询问下你需不需要帮助,又也许你的项目经理听了你的回答,会跟大老板拍板保证,这些都是建立在他对你的信任上的.或许你只是想表现的不那么弱,或许你只是想在你上司面前表现一下,我不是部门最菜的.但是这种信任是慢慢积累起来的,如果有一次你让他失望了.两次让他失望了,甚至三次,那么这种新人就会崩塌, 你可以说"我不确定我能hold住这个项目,这是一次挑战,但我想要试一试."这就是非常好的答案. 提前告知你上司这个项目会遇到的风险点,以及不确定因素,我想他更愿意给你更多的时间去调研,去整理整个项目的技术难度
敢于说"不"的人做出的承诺更可信,也更有分量,我不知道并不代表我不可靠,某个领域内的专家对于他们不知道的事情,总是勇于承认.
价值僵固
正如上面所说的跳出自己的舒适区一样,价值僵固依旧也很可怕,很多前辈都喜欢对后辈们谆谆教导,一部分前辈会把自己踩过的坑,遇到过的问题告诉你,你吸取了这些话,那么以后能少走很多弯路,但是如果这个前辈的思想已经过时,或者已经落伍了呢? 他的成功经验往往还停留在他们自己的那个时期,他们觉得自己的成功可以复制,但他们往往忽略了风向,站在风口,猪也能飞,如果有个公司的CTO跟你说他是学delphi起家的,让你去学,你信么? 你要知道delphi在二十世纪初,在C/S那个年代可是非常火的,而现在,你出去找工作,估计都找不到.所以可以听信前辈们的一些话,但是也不能全听,每个人都需要有自己的判断力,以及独立思考的想法,这是非常重要的.
我老弟跟我说,他想考公务员,我说为什么? 你知道公务员做什么的么?你知道公务员是怎么工作的么? 他说不知道.他父母让他考的,觉得够稳定,他父母对公务员的认知还停留在他们那个时期,稳定,工资高,工作舒服,压力小,但是随着公务员的人流越来越多,公务员已经不像以前那么吃香,福利没有那么好,竞争压力也非常大,几万个人去争取几十个岗位,这尼玛比高考难多了好么?
现如今,高考制度只是帮你走入社会的敲门砖,相对而言最公平的一种人才方式,但是这种方式以后,将来肯定会改变,而大部分学生都不知道高考以为着什么,对自己的将来以为着什么,甚至很多人为了进入某个大学,而匆匆报了个自己都不知道是什么的专业,就去上课了.有的人及时醒悟,他们是幸运的,而有的人一路走到黑,你说是他们自己运气差?还是当今的人才筛选体制不够完善呢?
再举个例子,很多人说外国的数学物理很简单,但是他们往往坐进观天,外国人教育的思想是兴趣引导,如果你没有兴趣,那么只让你学习些基础知识就好,如果你有兴趣,甚至将来会进入这个行业,那么授课的难度也会加深,因为兴趣是学习的源动力,而压迫式教育不是.这不得不说是我们这一代的悲哀,但是我相信未来会愈来愈好,越来越完善
不知不觉写了这么多.主要自己想说的话也太多,可能有些啰嗦,耐心看到这里的人,也是厉害.
总之我觉得很多程序员进入这个行业都是兴趣所致,也有部分人是因为想要找一个合适,体面的白领工作而进入这个行业,但是,在这个行业里面厉害的,就是那种真正专注技术本身的人,他们往往都是稀缺人才,可遇不可得的厉害人物,而这些人大部分都有几个特点
1.从不制定自己的职业规划,我写代码完全就是兴趣所致(任性)
2.我制定项目技术方案是根据项目业务需求本身,而不是单单从技术的角度出发,因此程序员在应对大部分场景和工作需求中,广度比深度更加重要,但是如果你想要专精某个单一领域的知识,并且成为专家,那么深度就比广度重要的多,而这种人才同样可贵
3.跳出自己的舒适区,大牛会写的代码有很多,从c,c++,java,到php,ruby,python,js再到go,swift,haskell,erlang通通信手拈来,并不是别人天赋有多强,而是人家能适应新技术,跳出自己的舒适区,慢慢积累,导致看起来比别人厉害的多,你要相信,凭现如今大部分人的努力程度,还远远轮不到拼天赋的时候.
4.投入100%的热情,大牛写代码不是为了钱,而是自己喜欢:)
5.学会处理人际关系,以及表达自我想法,沟通能力,也是程序员需要掌握的一件事情,因为你的上司看重你的表现的,往往不是 你实现某个功能的细枝末节,而是你对于整个项目的把控,以及沟通,他需要的只是结果,而不是过程,因此往往沟通能力强的资 深程序员,最后都会往高层去发展,慢慢转为管理层,而如果你只是想要安静的写代码,不想被这些无聊的事情干扰的话,那么你 可以忽略这一点.做一个技术资深大牛.但是你要知道,这个行业很多资深大牛往往都是沟通能力强,技术高深的体现,除非你是 求伯君,一个人单干的兰博式英雄,但是随着年代发展,团队式工作已经是主流,你无法一个人去单一的实现某个任务或者功能. 团队式开发针对开发效率,项目进度,项目复杂度,以及成本控制都比单一人员要好,而团队式协作就表名,你必须要有最基本的 沟通能力
如果让我在职业规划上做出一种选择,我希望技术走广而不深的路线,业务上也同时齐头并进.虽然整理文档,写项目汇报总结这些文档会让我痛苦不已,但是我觉得这才是我应该走的路,也是最适合我的路,不过,也许过一段时间,我就不这么想了:P
共同学习，写下你的评论
评论加载中...
作者其他优质文章
