工作的感悟

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

 

一

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

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

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

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

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

这种解决问题的方法说起来都懂，但做起来并不容易。至少对于我自己来说，我很容易就直接 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上的锻炼还不够，也还有好多问题没想清楚（比如一个好组的定义是什么，知道那么多业务逻辑有用吗等等），还需要更多的见识和经验。总而言之，我觉得这是很好的开始，相信接下来也会有更多的收获和成长。