我的2016
2016-12-27 / modified at 2022-04-04 / 2k words / 7 mins
️This article has been over 2 years since the last update.

又到了年底,去年年底还懒散地打联机游戏,并抱怨着PM2.5,现在却在深圳关外当加班狗,过着906的生活。多的不说,总结下今年有什么收获吧。

1. 技术提升

1.1. 以下是我满意的

  • Blog:1900+ 粉丝,12万余字,文章打赏还赚了100 😊
  • Github: 700+, 目前是吃老本,很久没有更新了。工作忙到甚至睡觉时间都不够了。
  • OkHttp: 当初花了一个月去读源码,没想到反响不错,也为后来分析后台重量级框架增加了信心。
  • FunctionalProgramming: 从开始的RxJava,以及后面用的Java8、Groovy、JavaScriptES5.1中的内置函数,实现了一次学习,反复使用。
  • 后台系列: 包括对Spring、Redis的源码分析,以及Groovy在DSL中元编程技术。
  • 常见DevOps技能: 第一个就是基于Expect的自动化脚本,减少重复劳动;第二个是写跨平台的Ant自动化构建,可以从源码到调测环境重启一键实现;第三个就是与测试沟(si)通(bi)用例,避免出现用例挂掉而返工。如果说还有一点就是上述技能一律写成标准文档,这一点对弱化单点故障(也就是半夜叫你上班)有很大的帮助。
  • 架构/中间件的学习: 比如SOA微服务,以及基于它的ZK、MQ。这个也是比较宏大的,还要看理论书籍学习一个。
  • Android: 从入门到放弃,很可惜。从去年iOS开始萎缩,到今年互联网创业的破灭,再到各厂强制996(对我厂奋斗者来说,996就是渣渣),可以看出IT行业正变得阶级固化起来,还好混了一个专业对口的工作。个人预测明年(2017)前端跨平台技术将得以发展,现在还在Android坑的小伙伴可以参考一下。
  • 读书: 使用Kindle看了许多书,特别是非技术类

1.2. 以下是我不满意的

  • Go/Ruby/Lisp语言学习没有坚持下来,而全转到了Groovy,这些吃力不讨好的玄学玩意应该在大学多贯通学下试错,现在时间比较贵了,看书都有投机性了。
  • 开源项目因为加班,全部停止维护了,这也从侧面证明选择一个靠谱的开源项目有多重要。

1.3. 以下是计划做的

下面最起码要出源码分析的文档,最好是可以出Demo或者流程图

2. 工作提升

2.1. 以下是我满意的

  • 混进了某500强公司: 成功地成为了一枚忙碌的螺丝钉,毕竟公司高大上,流程完善,培训充分;从最开始的大队培训,到最后看到各位同学去亚非拉各奔东西,接触了不少非技术类的有趣的人;与许多985的研究生同时加入,在同一个工作起点。
  • 非技术能力提升较多: 比如邮件、拉通、支撑。公司总体上还是从制造业方向对软件进行管理,另外比如AAR、KPT、PBC等方法在小公司基本也是见不到的。每天拉(si)通(bi)后,现在讨论事情可以单刀直入了,不会像普通码农一样闷骚羞涩。
  • 编码习惯: 使用FindBugs与Idea Inspect能够检查出来的问题,很少再次发生。可惜我司是括号换行党😂
  • 后台: 从零开始学习,目前项目最底层的SOA架构是米帝博士写的,很有阅读价值。

2.2. 以下是不满意的

  • 长期906的生活,太累。睡眠不足,无法自学,恶性循环。
  • 干起了传话筒的活,一旦涉及到环境维护,基本上就不写代码了,每天就是把时间耗在测试、开发与老大的拉通/推动/定位上(想想有哪些时间可以压缩?)。
  • 开发工作每个人都分别负责极小的模块,分工太细。
  • 问题表达能力还是比较烂,前因后果说不清,可能需要一本书?
  • 忙于工作,对技术的敏感度下降,害怕变成螺丝钉。
  • 工作时间加班过长,一方面是剩余价值的压榨,另一方面也说明了时间控制的太渣。
  • 一定要自学,一定要自学,一定要自学。这个在任何大公司都会出现,尤其是作为螺丝钉,需要时刻保持危机感。

2.3. 以下是计划做的

下面全部需要落地,首先形成文档,接着要去实践并更新文档。

  • 无论多晚,也要统计每日时间的使用,并形成AAR

多的计划不写了,写了也没时间做,所谓温饱思淫欲,挤出时间才是最吼的。

3. 其它感想

  • 关于公司:在我厂待满2年的实在太少了,有各种原因,最主要的就是时薪过低,这点的确需要改变,否则就只能招到拼命的应届生被当作简历跳板了。
  • 关于城市:深圳是一座好的城市,可惜只是关外客。不过适应了深圳,已经回不去家了,无论是气候、环境、工作、人际还是生活方式。
  • 关于鸡汤:运气 > 选择 > 努力,一定要对选择操作进行可控,投入前要进行时间投入与回报率计算,可以用5WS分析pros与cons。
  • 关于时间:每个人的时间都是有限的,一定要计算投入产出比,想办法压缩时间,这样才能为自己+1s

4. 总结

2016年就这样过了,总的来说吧,比上不足,比下有余:工资不高,温饱水平;技术尴尬,需要加强。

祝我在新的一年里,提高效率,早日下班。

5. 附录

几条提高效率的方法,均来自某500强的管理方法,没有废话与鸡汤,希望看了有用。

如何表达

很多人觉得自己表达能力太弱,第一个是对自己呈述目的不是很明确,第二个就是总结能力太渣。

介绍一种来自岛国的KPT(Keputo)方法,来如何呈述你一天/周的工作

  • Keep: 你正在做什么
  • Problem: 你遇到了什么问题
  • Try: 打算如何解决问题

举个晨会的例子:

我昨天进行了XX接口的开发,并调通了XX模块,但是在某些参数下会报500错误,目前定位可能是XX参数问题。今天打算解决此错误,并与客户端完成此接口联调。

为了避免浪费集体时间,努力在1分钟内完成呈述,这个可以用写作来训练。

如何总结

AAR(After Action Review,事后回顾)是一种知识管理与总结的方法,俗称事后诸葛亮。 它在米帝中得以推广,而国内企业对此进行了借鉴。

具体就是这样一个例子

我希望发生什么结果发生了什么为什么导致此原因以后应该怎么做
今天把XX接口调通搞了很晚也没搞定,0点才回去对框架掌握不足;自己定位时间过长;找不到接口人求助;多写技术文档;将接口人责任合并清楚
今天通过XX测试反复调试无法通过代码健壮性太渣;强制分出时间进行代码审视;

你的2016年终总结也可以用AAR来写,如果你去年也写了年终总结,就可以通过AAR的方式进行前后对比,从而分析自己的目标为什么没有达到。