聊聊这几年的工作经历

Posted by Ink Bai on 2019-04-01     & views

从 15 年毕业算起,不知不觉已经快要工作 4 个年头了,不久前刚从上一家公司离职,趁着中间这几天难得的空档期,回忆一下自己这几年的工作经历吧。

关于找工作这件事

记得刚毕业的时候,找工作那叫一个难字了得。因为我大学鬼使神差的被调剂到了数学专业,这个专业如果不考研的话可能最对口的工作就是数学老师了,而考研的一般都会向金融方向发展,原因嘛你懂得,其实我们学院的学习氛围还是不错的,但还是形成了一个很尴尬的局面:一方面知道数学专业不好找工作,另一方面呢学院内部的学习氛围都是向什么经济学和金融发展,就导致直到工作了一年,我都不知道牛客网、Leetcode 是什么东西。

毕业之后本着有人要我就干的原则开始做 Java 开发,在新手村首先拿到了 SSM 这个新手套装,然后又学习了一些 Linux 和数据库的一些技能,积累了差不多一两年工作经验的时候去跳槽才发现自己学的都是一些武功招数,各个大厂好像都很看重你的内功:「算法」。

到了最近,差不多工作快 4 年的时候,明显感觉到工作机会比工作一两年的时候多了很多,虽然也并不是一帆风顺,但是总体上也可以跟一些大厂过过招了。

回顾自己为数不多的几次跳槽经历,其实并不是工作年限越长找工作就越顺利,因为人总是往高处走的,每一次的跳槽都要求去到一个更好的地方,遇到更多优秀的人,所以跳槽的难度其实也是在逐渐上升的。而且生活并不是电视剧,电视剧里面主角从新手村出发后,一路遇到不同的 boss,虽然 boss 等级越来越高,但是主角也越来越强大越来越游刃有余。然鹅现实生活就不同了,现实是一个充满变数的存在,所以:

找工作也是看运气的。

现实生活中找工作这件事就是能力运气缺一不可,甚至有时候运气的成分比能力都要大,有时候你的能力其实已经达到了,但是就是缺那么一点运气。运气呢是个概率问题,是个不可确定因素,但是好消息就是我们有很多条命,那么多的公司,这家不成换一家,只要能力基本达到了,总会有运气好的时候。这就是所谓的:

运气是给有准备的人的。

另外就是跳槽的时候千万不要裸辞,有个猎头跟我讲过,他那边很优秀的候选人也得需要两个月左右的时间才能找到满意的工作,对于平常人来说这个时间可能是半年,所以如果你不是真的非常牛逼的话,还是老老实实呆在现在的地方,做好打持久战的准备。

关于技术成长

如何更好的技术成长是每一个技术人一直在探索的问题,我个人经历了两个阶段的改变。

第一个阶段是刚毕业的时候,那个时候学东西充满了学院派的作风:把所有接触过的新知识都尽可能详尽地列出其整体技能树,然后循序渐进地按照 写 Demo -> 看官方文档 -> 看相关书籍和博客 -> 实际生产环境中应用 这个顺序来学习,理想很美好,现实呢,就像我们背英文字典一样,每次都止步于 abandon,😢

到了现在,学习东西开始有了针对性和选择性,我会深入掌握的知识主要是两种:

  1. 工作中需要的
  2. 自己感兴趣的

而且每次深入研究一个东西之前都会有一个确切的结果,也就是 结果导向。比如在 Spark Streaming 中如何实现数据的 exactly-once 语义,为了实现这个目标去找相应的资料研究,或者通过用 Scala 来写一个网站来学习 Scala。

总之,之前学习技术的方式,是 为了学习而学习。现在学习技术的方式,是

为了达成某一个具体目标而去学习。

学习方式上的另一个转变是从 全面并且循序渐进的学习整个知识体系 变成了 从最初就开始深入挖掘某一点

之前学习的时候的习惯是 demo 代码是 demo 代码,生产环境代码是生产环境代码,最开始只要写出 demo 代码即可,后面随着学习的加深慢慢重构。实际操作下来发现,线上没出问题的话开始写的 demo 代码我并不会专门花时间去重构,线上出了问题我只能花时间去解决这些 demo 代码导致的 bug。

所以现在研究一个东西,目标一定是 生产环境可用,这就要求从你第一眼开始接触这个东西开始就不要妄想只是简单了解一下。当然人的精力是有限的,不可能把所有东西都研究透彻,所以正如我上面所说,深入研究的东西仅仅是其中的一个点而已。

每次都研究一个点就导致了一个问题,知识没有体系。

所以我们一定要有一个属于自己的技能树,而且这个技能树应该尽量和当前市场要求的技能保持一致,勇于去研究新的技术。

比如我开了一个专门的 git 仓库 i-want-to-learn 作为知识的输入,用来总结自己的技能,然后通过写博客来输出。输入到输出才能形成一个完整的闭环,点亮真正属于自己的技能树。

关于职业素养

最开始我以为工程师是一种简单而又纯粹的动物,只要管好自己的一亩三分地就好了,不会跟其他人有很多交集。而「职业素养」这种看起来就很高大上的词汇,应该属于那些掌握经济命脉的金领阶层中。

但是随着遇到很多优秀的工程师和更多没那么优秀的工程师以后,我发现职业素养对工程师来说也是重要并且应当有一个标准的。

首先,一个总是有很多问题要问的工程师总是不会太差。

对于新手程序员或者是一个刚来公司的新人来说,有很多未知的东西,有时候他们会问“老鸟”一些很“弱智”的问题。好一点的老鸟呢,告诉他们答案,然后告诉他们下次遇到这种简单的问题先通过什么途径去自己解决一下,对于脾气不好的老鸟呢,可能就直接告诉他们请先读完 学会提问 再过来问我。

但不管提的问题是不是很基础,自己有没有先做大量的功课,我觉得一个工程师能够总是对自己的工作提出一些问题,并产生想要弄清楚的好奇心,这就是一种很好的态度。君不见多少新手程序员,老鸟告诉他这个东西只要跑一下这个脚本,然后配置一下这个参数就可以跑了,他们只会把这些配置和步骤牢记于心,但对其中的原理却懒得去弄明白。君不见多少老司机,别人问他这个代码为什么这么写的,他的答案直接就是以前的人就是这么写的啊,你照着写就对了,而不会考虑以前的人的代码有没有错误有没有重构的可能性。

所以,如果你真的是一个新手,那就大胆去提问吧,不要害怕别人说你这么简单的问题自己怎么不会查一下,也不要怕给别人造成困扰,为了进步脸皮厚点不丢人,但是也不要忘了没事请帮助你的人喝杯咖啡噢。

当然,归根结底,一个工程师最重要的还是解决问题的能力。

虽然爱因斯坦说过,提出一个问题比解决一个问题更重要,但是在工程界这个说法行不通,因为工程界其实就是为了解决各种商业上问题而存在的。所以当一个程序员走过新手村以后,就要努力尝试着去自己解决问题了,毕竟师父领进门修行在个人嘛。

而问题也有多种解决方法。想当年当熟练掌握谷歌搜索和 ctrl+c/v 以后,我一度以为自己已经是不世出的高手了。直到遇到一个学习某个技术要把最原始的论文找出来读,网络上找不到任何学习资料就直接上去生撸源码都要弄清楚的真大神,才知道原来问题还可以被这样解决。

解决问题的方法有千万种,如果不知道使用哪一种,那么每一种都试着用一下,然后再试着弄清楚为什么这么解决,总没错。

主动一点,再主动一点,拥抱新世界。

去年新东方的年会火了,其中有一句歌词这样写的:

「干活的累死累活,有成果那又如何,到头来只不过写 PPT 的」

所以各位累死累活的程序员们,不要总是守着自己的一亩三分地,以自己是技术人员自居而两耳不闻窗外事。没事向领导汇报汇报工作,既能反映自己做过的工作又能看自己的方向是不是正确,有没有可以改进的地方。

另一方面,主动去发现问题,主动去承担更多的责任。这块代码是不是可以重构一下呀,这个流程是不是太慢了,能不能引入效率工具啊。主动去找问题找事情,而不只是一个堆砌业务代码的码农。

关于 ETA

上面提到了解决问题的能力,但是解决问题呢也是要有期限的,这就是 ETA。可能很多工程师都有过被 PM 强制缩减 ETA 的经历,导致听到 ETA 这个词就眉头一皱菊花一紧。其实我觉得 ETA 是一个非常有意义的东西,不仅对于工作,对于我们人生中的很多事情都有很好的指导意义。额这么说好像也有点绝对,比如感情就不能定 ETA,可能因为我是一个摩羯座,所以任何事情都是结果导向的,没有好处的事情真的是没有动力去做,有时候可能 ETA 带来的压力就是我的动力了哈哈哈哈。

为什么我说 ETA 很重要呢?首先给解决问题定一个 ETA,说明你真的是把这个事情当作了一个确定的目标,有一个确切的目标是一切的前提。当你问一个人他的梦想或者目标是什么的时候,如何判断他是真的想做还是只是说说而已呢,最简单的就是看他说完这个梦想以后有没有加上一个确切的时间期限。

没有 ETA 的目标都是在做梦。

比如一个人说“想在 30 岁之前年薪百万”一定比说“未来想成为一个架构师”的可信度高。其次,

合理准确地预估 ETA 其实是一件很难的事情,考察你的多个能力。

首先遇到一个问题,你需要快速弄清楚这个问题的前因后果吧,需要你有很强的理解能力吧。某些不是很清楚的点可能还需要询问他人,这也会要求你有一定的沟通能力吧。第三,弄清楚问题以后,能够合理拆分问题,大事化小小事化了,这也是一种很重要的能力。第四,一般不会给你很长的时间去调研然后预估 ETA,而在你差不多能预估出 ETA 的时候,说明你心里已经有了至少一种解决方案,在这么短的时间内能够完成调研和预估时间,这需要很强的学习能力和行动力吧。

所以 ETA 真的是一个很锻炼人的东西,我们应当试着去改变自己对 ETA 的固有思维。尽管有时候“迫于无奈”,需要多报 ETA,但我们自己还是应该每次都尽可能准确的定一个 ETA 并且制定出给自己的奖罚制度,甚至可以尝试着把 ETA 疗法扩展到生活中的各个方面。

关于未来

逼逼了半天,突然想起一句话,「说的比唱的好听」。大道理都懂,还是过不好这一生。其实我并不是一个对技术很狂热的人,甚至有时候觉得技术就应当为业务服务,没有业务场景的支撑再好的技术也毫无意义,当时选择做技术这条路也是因为别的什么都不会。o(TヘTo)。

但是既然选择了,那就坚持吧。

有时候并不是因为热爱才坚持,而是坚持了才热爱。