去年过得怎么样?你的目标还差了多少?就算没有实现你的小目标,也没关系,到来的2018可要好好规划一下呦!先来掌握一下技术人拿高薪必知的11件事!
2018 如何成为高薪的技术人?
对于IT技术人而言,技术过关当然是非常重要的,这是硬实力。然而只会技术也是不行的,毕竟大多数的工作还是要与人打交道,软实力也是不可或缺的。怎样才能拿高薪,有以下几点:
计算机领域是一个快速更新换代的领域,每隔一段时间都会有新的语言、框架、思想产生,追随每一个新技术很累。
但仔细想想,事实上并没有那么多新东西。很多新东西只不过是已有技术的封装、或者借鉴的其他领域的技术。
比如缓存数据库 Redis、Memcached,其基本思想不就是操作系统中的缓存吗;分布式存储中的分片与复制集,不就是文件系统中 RAID 的扩展吗?
还有 Google 的 MapReduce 框架,不就是来源于函数式编程语言的 Map Reduce 吗?掌握好计算机基础知识,能够更本质的看待新技术。
磨刀不误砍柴工,打造好自己的工具集非常重要。
开发中会用到大量的工具,不管是编辑器、调试工具还是监控工具,大家都喜欢争论哪个 IDE 更好。
然而,这并没有多大意义,关键在于能够熟练的使用自己喜欢的工具,掌握各种快捷键,高度自定义,这样能够大大提高工作效率。
而且对于日常中重复的操作,最好脚本自动化,这里推荐一下 Python,写小工具还是很快的。
另外,强调程序员必备的两个工具,那就是浏览器和 VPN。后者大家都懂的,不多说,主要是有了后者才能发挥浏览器的威力。
浏览器大家天天都在用,但是如何高效的使用,比如在指定网站搜索、通过标题、url 过滤、选择合适的关键字还是值得研究一下。
对于程序员,要使用好浏览器,那还得具备下一个能力:英语。
不得不承认,在软件创新领域,国内还是落后于国外的,新的技术、一手的资料都是英文的。
当新技术被广泛应用之前,我们在百度搜到翻译要么是 machine translated,要么错误百出。
看翻译的最大问题取决于翻译者本身的水平,即使翻译水平都很高,但同一个单词往往有不同的翻译,导致看文章的时候会有困惑,最好还是直接看英文原文。
大多数原文,除去专业词汇、还是比较好理解的,而且,我发现很多牛逼的项目,都有非常通俗易懂的文档。
代码是写给机器执行的,同时也是给人阅读与维护的。维护者可能是别人、也可能是几个月后的样子。良好的代码规范,必要的、清晰的注释可以让自己少被问候祖宗十八代。
对于代码风格,网上争议也很多,最重要的是保持项目内的统一。做为技术负责人,一定要在项目开启之初就定好规范,当大量代码被堆出来之后就很难统一了,然后做好新人的 review。
程序员这个职业,相比其他职业,可能还是要年轻许多。特别是在国内,最老的一批程序员好多都转管理了,再过 10 年 20 年,我们会怎么样呢,没人知道。
前段时间华为 35 岁程序员被离职的事情,还有最近传遍朋友圈的中兴 42 岁程序员坠楼身亡的事,都给我们敲响了警钟,悲哀之余,只有尽力学习了,拼不过体力就拼能力与经验吧。
学习这个事情说起来就复杂了,我觉得两点很重要:基础、学以致用。
合格的程序员解决的是问题,而不是实现某个解决方案。产品经理(特别是知道一点技术的产品经理)的某个需求可能只是某个问题的解决方案,他认为这个方法可以解决他的问题,于是把解决方案当成了需求,而不是真正的问题。
程序员应该主动沟通,多问几个为什么,了解真正的问题,也许能有更好的解决方案。
之前就有这么个例子,给到的需求:为每一个用户(用户有唯一的 id 标示)生成一个唯一的邀请码,同时也要为未来一段时间可能增加的用户预生成邀请码,保存到数据库。
而真正的需求是老用户分享自己的邀请码,如果新用户使用了该邀请码,则老用户获得相应奖励。我提出的方案很简单,直接用户的唯一 id 生成可逆的邀请码,这样就根本无需数据库存储。
产品经理经常改需求这是程序员最头疼的事情,作为程序员应该也站在 PM 的角度思考,帮助 PM 分析出本质的需求,这也许可以减少需求的变更。
当然,前提是得干一行爱一行,需要对业务有一定的了解。
写代码的时候先想清楚了再下笔,而不是先写出一堆代码,然后在开始修 Bug。
修改 Bug 的时候,多看看上下文,搞明白为什么出 Bug,修改这个 Bug 可能带来的影响,然后再修改。
反面教材有两种:
随便改改就把代码改好了,但自己心里并不清楚为什么这样修改就修好了,撞运气,也许还有其他同样的 Bug 也发现不了。
头痛医头脚痛医脚,不仔细评估修改的影响,这样往往会引入新的问题。
程序员成长的一个办法就是修 Bug,修别人用不了的 Bug,但前提是搞清楚 Bug 的缘由,这样才能避免类似的错误,有所收获。
顺畅沟通不是巧如舌簧、也不是忽悠达人,需要的只是耐心倾听,然后清晰表达自己的意见。
现在的软件开发,已经不再是单打独斗的年代,大多数的软件、产品都需要多人、多部门的协作。而交流、沟通是非常耗时耗力的。
沟通之前,先想好目标,组织好语言,尽量不要发散、不要跑题,对事不对人。对于重要的事情,保留沟通记录,最好有邮件,免得说不清。
沟通是门复杂的艺术,最基本是听明白、说清楚。
作为一个程序员,要被 PM 怼、要被交互怼、要被 QA 怼,再变态的需求都可能有,QA 给你提的 Bug 可能也不属于你。而且,还有猪一样的队友(自己在别人眼里何尝不是这样呢)和下属。
不管谁是谁非,发脾气、吵架都一点用没有,吵完还是得解决问题。calm down,有怒火也得等个几秒再发作,也许这几秒理智思考一下,就能解决问题。
能力(技术能力)与责任心谁更重要呢,都重要。如果一个新人有培养的潜力,那么责任心就更重要。
两个人,第一个技术能力很强,但责任心很差,对项目的事情也不上心;第二个能力差些,但责任心强,是自己的问题一定负责到底,即使自己不能解决也能主动寻求帮助。
我觉得前者对项目的危害更大,特别是项目紧要时期,因为能力强的人一般负责的是比较复杂、困难的功能,别人上手也需要时间,这个时候如果摞担子,Bug 也不修,那么就很为难了。
不负责任的典型表现就是扯皮、甩锅:这不是我的 Bug、不关我的事。
有协作的地方更容易出现问题,比如前端与后端、各个部门之间。如果不清楚到底是谁的问题,不妨主动一点,帮助排查。
作为程序员,总有一些工作是以前没有做过的,也许来自产品人员的需求,也许来自项目自发的优化。
我见过一些程序员,在面临未知的问题、挑战时,总是习惯于说:不会、没办法、不可能,这样的程序员就算不上合格的程序员。
事实上,这样的程序员是给自己过早地留好退路,事实上问题可能并没有想象的那么困难,也许经过一番探索就能解决。
如果习惯于对未知说不,那么在别人看来就是能力不行,影响个人形象与声誉,而且总是待在自己的舒适区也不利于自我成长。
当然,也不是说要盲目自信,急于拍胸脯保证一定能解决,这样往往是坑自己。
所以,面对新的需求,谨慎对待,既不轻易否决也不随意承诺,而是再理清需求先去研究一下,评估是否能完成,需要的资源与时间。
可能很多人都觉得不以为然,那是你还不了解技术人日常工作中的 种状态。。。
技术人的 17 种工作状态,扎心了
1.明明是个小 Bug 但就是死活修不好...
2.作为一个码工我意外走入了一个充满 PM 的会议室...
3.偶然间看到了自己多年前写的代码
4.调试过多线程的都会懂!
5.这就是你们追捧的结对编程
6.Git merge
7.当他们问我是否需要兼容 IE 的时候
8.当我以为已捕获了所有可能的异常的时候
9.你永远 try...catch 不到所有的可能性!
10.数据库的 Delete 语句忘了,使用限定词 Where...
11.当我试图把一个 Bug 踢给别人的时候....
12.好像真的没人发现我产品里的 Bug...
13.第一次尝试退出vim
14.当我试图清理几行所谓的旧代码的时候...
15.当我按照 Stack Overflow 上的回帖,解决问题的时候......
16.编译错误:括号不匹配
17.作为一个程序员,最后是拷问灵魂的时刻了:
“你热爱自己的工作吗?”
“...爱!”
“再给你一次机会”
“...唉...”
人艰不拆,求别说。
好了,说多了都是泪,所以还是牢记上面达妹推荐给大家拿高薪必知的11件事吧,至少工作不顺利,技术和高薪可以来凑,是吧!
Relax!迎接好你的 2018 吧。
Linux云计算免费课程火热开讲中,5天免费运维干货内容免费听,点击文末“阅读原文”即可免费听运维课!速速来抢~~~~
PS:记得查收小编送你的免费大礼包呦~
免费领 | 《Shell脚本 100例》电子书免费拿,运维必备干货~
▼▼点击【阅读原文】,免费听5天Linux运维干货分享课,火热开讲中,速来抢!