到明天5月22日,我就入职满满一周年了。回想起这一年,从刚开始啥都不懂做事都有些畏手畏脚,到现在能在听到 pager 响的时候气定神闲地打开 ticket,还能在组里面搞一些事情,想办法提升一下工作流程或者减轻一些 operations 负担 。开心过吐槽过迷茫过失望过,一年下来还是收获了很多。

入职前以为自己以后的工作就是天天写码,从早写到晚。但实际上出于组里项目的安排,到现在我也没写多少代码(想了想还是不要说我写了多少行了)。前几个月还在和我的小伙伴们半开玩笑地说,我作为 SDE 终于从 Ops 的工作中脱身出来,开始做 PM 了。

入职的前几个月安排我做 migration 的事情,大体来说就是一些 service 之间相互通信的 protocol 需要更新,需要升级一些相关的 package。这件事听起来很容易,也的确是可以按照步骤一步一步完成的,但问题在于,我们组有很多继承下来的老系统,大多“年久失修”,改动这一部分可能会影响另一部分,这让我遇到了层出不穷的问题。我一开始由于对系统不了解,像一只无头苍蝇一样,全靠内部版的 stackoverflow 来解决问题。虽然也能解决一些问题,但是这个过程非常痛苦,需要一个方法一个方法尝试,而且常常是越试越绝望。

这让我想到了很早以前看到的两个图。(用 Google 图片搜索找到最开始的出处应该是这里

howto

我觉得这还是理想情况 —— 新手花了成倍的时间,终于还是找到了出口。但真实的情况很可能是,由于现实过于复杂,在找到出口前就已经饿死在迷宫里了。即使找到出口了,也有可能找到的不是真正的出口,而是另一个深渊的入口(会在未来引发更多更大的问题)。

所以,与其期望“瞎猫碰到死耗子”,倒不如静下心来,花时间去了解事情背后运行的机制,在懂得原理之后,就能对目的地的大致位置有谱了。

这让我想起吴军老师经常提到的“鸟飞派”和“空气动力学派”。说人类很早就梦想着自己能像鸟儿一样飞翔。于是人们就开始模仿鸟类,比如将鸟的羽毛做成翅膀的样子然后绑在胳膊上往下跳,结果自然不必多说。后来人们将这样的方法论称为“鸟飞派”。我们都知道,最后怀特兄弟发明飞机靠的是空气动力学,他们根据科学原理设计了飞机,而不是简单地模仿鸟类。

这种解决问题的方法说起来都懂,但做起来并不容易。至少对于我自己来说,我很容易就直接 copy-paste 别人的解决方案,毕竟简单、快捷。但要知道,这种方法的弊端除了前面说的 —— 这个方案可行很可能只是因为你幸运罢了,它可行很可能是问题本身就比较简单;如果问题复杂,变量太多,很难说别人遇到的问题和你遇到的问题一模一样 —— 另一种更严重的危害就是,这样做其实学不到任何东西。Copy-paste也许能让我们解决眼下的问题,但是这不能赋予我们解决未来类似问题的能力(也许能提高一些搜索能力),说白了也就是这种方法论不能产生复利效应。

这是我最大的收获。后来我遇到比较复杂的问题,往往会要求自己静下心来研究。我还会在草稿纸上将子问题一个一个列出来,然后一个一个找答案。就像在黑暗中慢慢地牵着这些小问题的绳索往前走,一步一步来,就能找到答案。

很不巧,做完了上面一个 migration 的任务,我们组出现了一些人员安排上的变动,将大组拆成了两个小组。而我被分到的小组所负责的新项目 v1.0 正好 code complete,于是我就要做一些 production readiness 的事情。说白了就是,set up infrastructure、deploy、set up monitors and alarms 等等。每一件事基本上都是手动在内部工具上点鼠标。最要命的是,因为我们要在全球 launch,所以每一个地区都要重复一遍类似的事情。当时每天工作无聊至极,一度怀疑自己工作的意义。

后来我找大老板聊,我说,你看我入职那么久,都没写什么code,现在又在做这些比较机械式的事情,别的小伙伴一个月能写好多代码…… 他的回答让我印象很深。他说,你不能仅仅把关注点放在“我写了多少code”上面,能不能到下一个级别,关键在于你做的事情的复杂度以及影响力。 就比如说这样简单的事情,你能不能想办法自动化,能不能开发一个工具简化流程,能不能更有效率地完成这些事情,能不能把经验分享出去从而为别人创造价值?

吴军老师在得到的专栏里经常讲 “一流的人能够把二流的项目做成一流的”。与此类似的,买土豆的故事你一定听过。后来我就换了一种思维,不再百无聊赖地做着这些看似无聊的事情,而是主动去思考怎么样换一种做事的方式。于是我发现,除了点鼠标,其实很多内部的工具是提供 CLI 或者 API 调用的方式来做的。这些方式往往支持批处理,特别适用于我的情形。有了这个认识,在后来的工作中,一旦我发现我做的工作比较机械化的时候,我就会写一个 script 来自动化完成这些小任务。

我当时意气消沉的另一原因是总觉得这些活儿不该 SDE 来做,SDE 的主要工作难道不是写代码吗?从这段经历得到的另一个收获是对软件工程的认识。这个认识的提炼要感谢陈天老师的知乎LIVE谈谈工程师常常忽视的软件开发能力。陈天老师将软件系统类比于人的成长,分为

  1. 婴儿期(Proof of Concept,本地运行,关注是否可行)
  2. 少儿期(开始面对真实世界,加入错误处理,关注健壮性)
  3. 青春期(日志,错误报告,部署等)
  4. 成人期(性能,监控,报警,统计分析等)
  5. 消亡期

我们在学校里其实只学了“婴儿期”的工作。当然这是最重要的,也是最有意思的部分,但这仅仅是一个软件系统最初的一个阶段,我们再后来还要面临很多问题要解决。而我只是正好错过了产品的婴儿期,但并不意味着我做的事情不重要或者毫无意义。后来我意识到,如果一开始的一些 configuration 没有调好,到后面可能会面临很重的 operations 的任务。这些都是 technical debt,而出来混迟早要还的。

当然,对于前面的类比我想补充的是,不同于人的线性的成长(虽然我很羡慕有些人越长越年轻),软件系统发展的各个阶段是相互交融的,很多情况下我们既要面临开发新 feature 的任务,也要面临运维和优化的任务。

第三件事是最近发生的,简单解释一下我为什么还当了会儿PM。两个月前我们组 database migration 的任务快结束了,剩下都是一些零碎的活儿。跟我 mentor 聊,他就建议这时候要提前准备准备我们组 roadmap 上的新 project,提前自己做一些研究。可问题是,我们的PM还忙着其他事情,项目的很多 requirements 还没有明确。我跟老板聊,也大老板聊,他们也都很支持我,说现在没有,那么你可以去做。于是我就开始联系别的组,做了很多超越 SDE I 范围的事情。

这件事情也是我入职前想象不到的。入职前总是被贩卖着一种焦虑,说大公司就像一个庞大的机器,而刚入职的我们就是一颗颗螺丝钉,说平时的工作哪有多少你自己发挥的东西,上面说什么你就做什么,云云。但我个人的感觉并不是这样,因为小组非常自治,很多时候都有自己发挥的空间。翻看一年前的日记,老板当时就跟我说,千万不要觉得什么东西是理所当然的,要想办法打破它,改进它,要主动去发现问题,然后解决问题。我也不知道是不是其他公司也这样,但这样的文化的确能让我有更多的动力去“搞事情“。

上面所说的其实还是做事要主动 (proactive),不过我还想说的是,还要去想怎么主动、在什么事情上主动。对我来说,我会在对自己职业发展上有利的事情主动,会在对整个 team 有利的事情上主动。像有一些事情,比如说突然来了个需要立即处理的事情,如果不是我 oncall,我一般会抑制住好奇心而让自己专注在正在做的事情上。可以插一手的事情很多,我们总不能什么事都管一管。毕竟到最后,功利一点来说,能写在 promotion doc 上面的也就那几件事情。其实人生也如此。主动并不是要做很多很多事情,主动是要把关键的事情做好。

尾声

说了这么多,我觉得我还是很幸运的。虽然之前做的事情让我一度想换组,但现在看来我们组还是挺好的,每一个人也都特别好相处,大家也很乐意不断改进流程和提高标准。这一年也与很多人交流过,得到过很多人的帮助(谢谢大家!)我从交流中学到了很多,比如最近就会去了解别的组的 best practice,然后借鉴到我们组。当然才入职一年,我觉得在技术/coding上的锻炼还不够,也还有好多问题没想清楚(比如一个好组的定义是什么,知道那么多业务逻辑有用吗等等),还需要更多的见识和经验。总而言之,我觉得这是很好的开始,相信接下来也会有更多的收获和成长。

本文最早发布于LinkedIn一亩三分地论坛