余生皆假期

起了个很有B格的标题，实际上只是要讲一件简单的事情：同事离职。

同事离职之后在豆瓣上发的第一个状态：余生皆假期。

抛开那本同名的推理小说不谈，很难想象一个人在何种情况下能够说出这种话，不过除了中二青年之外，大概只有那种对于自己的人生有着确实把握的人才能说出这句话，因为他已经到了几乎可以随心所欲的安排自己的生活的程度了，又或是有了摒除杂念，择一路而独行的觉悟。

今晚和他一起出去吃了个饭，算是离职送行，走了半天还是不知道吃啥，只能选择了一家冒菜2333.

他年前入职的吧，在公司呆了一共不到三个月，试用期都还没结束，他就选择了离开。

如果说理由的话，也无外乎是一般程序员离职的两个理由之一：钱不够，干得不开心。

不过他的性格，显然是因为干得不开心。

一是因为公司里人的水平不尽如人意，可以说Python方面他是最厉害的吧，写业务这块的人里面，他也是最厉害的那个。

关键问题是：公司里的某些进程他并不能推动，比如，改用更加高效的工具（从gerrit到gitlab之类的），编码时常被打断（经常需要确认一些未确认的需求），另外就是，code review的时候，大家在想法上时常冲突，而往往他的说法很有道理的时候，风格却得不到认可。

之前一直看到的一个观点就是：当你在一家公司已经是最NB的时候，你就该走了。

这句话虽然有些偏颇，而且于公司不是最有利的吧，对于个人发展的好处应该更多一些。因为在一个公司已经无法积累对于职业生涯的经验的时候，你的职业发展实际上处于一个停滞阶段。

现在公司里这段时间一直在做前后端的混合开发，实际上是比较低效率的，因为不在擅长的方面发力，算上时间成本其实不划算（不过特殊时期也是并没有办法，资源不足）。

从这个同事那里学到的最大的几个Point：

用辩证的方式思考一个观念/做法的正确性，尝试用“为何要这么做，两者比较起来有什么明显的不同”来替代“Google也是这么做的/xxx都这么做，我们为何不这么做？”
始终保持一颗学习的心，对于不了解的事物不要急着否定，应该先了解之后，再想办法否定它！
当一个工具阻塞了你的进程，你可以改变这个工具，不应当让工具把人奴役了。
不要把单元测试写成功能测试，尽量不要在你的单元测试里产生对外部环境的需求。
Keep it simple, stupid. 没想清楚的东西就不要写，尽量写的简单易懂，能面向过程就面向过程，能写function就不要class，因为没想清楚就写的东西或者一个”pass”之后多半需要重写。
不要提交未完成功能的代码，因为你的队友或者是系统可能需要使用它，保持每个commit都是可运行的。

以上，也不想详细掰开来说，希望和这位基佬的革命友谊不要消失：）能够一直保持下去，良师，益友。