工作一年了，聊聊三件事

以前申请和找工作都在一亩三分地里得到很多小伙伴的帮助。现在入职一年了，想跟大家分享一下感想，交流交流。以下是正文。


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

入职前以为自己以后的工作就是天天写码，从早写到晚。但实际上出于组里项目的安排，到现在我也没写多少代码（想了想还是不要说我写了多少行了）。前几个月还在和我的小伙伴们半开玩笑地说，我作为 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 谈谈工程师常常忽视的软件开发能力。陈天老师将软件系统类比于人的成长，分为婴儿期（Proof of Concept，本地运行，关注是否可行）、少儿期（开始面对真实世界，加入错误处理，关注健壮性）、青春期（日志，错误报告，部署等）、成人期（性能，监控，报警，统计分析等）、消亡期。

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

当然，对于前面的类比我想补充的是，不同于人的线性的成长（虽然我很羡慕有些人越长越年轻），软件系统发展的各个阶段是相互交融的，很多情况下我们既要面临开发新 feature 的任务，也要面临运维和优化的任务。顺便提一句，我还是很认同亚麻 two-pizza team 理念下每个组都要从端到端地负责自己系统的组织架构，这样能让组里的每个人都参与到软件开发的全过程，渐渐地也就能从全局系统的角度来想问题。

三

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

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

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


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

你再工作一年后回头看今天这些事又会有不同的想法，你会知道大老板是最善于画大饼和利用一些听起来很高大上很有道理的话来忽悠你的人

All he cares is everyone stays on his own position doing his own job, the whole team's success is his success, not yours.
but the end of the day, you are the ONLY one who cares about your career and you have to work it out.

脏活儿杂活儿总是要有人干的，大老板并不关心是谁干，只要有人干就是了，但从你的角度讲就是unlucky了正好落到你头上
在这种时候有人选择换组，有人选择像你一样从灰烬里寻找希望，努力发现一些学习价值。either way, 这都是让自己开心工作下去的方法

诚然你现在干的活儿仔细揣摩还是能学到一些东西的，但你换了组做了能学到更多东西更实际更transferrable的skill的活儿之后可能才会幡然醒悟，后悔自己为什么不早点儿换组，如果你之前的1年从一开始就是再做更有技术含量的活儿，现在的自己是不是完全不一样？Think of how much you could have grown in one year if working on something else。。。

还是觉得如果作为一个entry level SDE工作中如果连写代码的机会都不多，还是move as soon as possible
这只是我个人的一点建议，给LZ参考

我也是入职亚麻一年多了 目前准备跳槽
可能没有像楼主那么好的心态 再加上自己的组也是比较不好 ops重 oncall重 修bug居多 写代码少
一年下来感觉自己学到的东西并没有达到预期 加上周围的环境不算太友好 现在也是慢慢懂了为什么一直以来亚麻会受到这么多的诟病
我个人是比较认同把软件类比成人的成长的这个观点的 前期的开发和后面的ops同样重要 但是作为一个junior developer 如果没有前面的代码累积 是很难在技术专业上得到成长的
没有大量代码和大project的锻炼 直接会让人在面试跳槽升职的时刻落入下风 如果还想在engineer这条路上走的话 当然如果是manager之类的 可能是另外一说了

他说，你不能仅仅把关注点放在“我写了多少code”上面，能不能到下一个级别，关键在于你做的事情的复杂度以及影响力。 就比如说这样简单的事情，你能不能想办法自动化，能不能开发一个工具简化流程，能不能更有效率地完成这些事情，能不能把经验分享出去从而为别人创造价值？

作为一名Senior，一看这老板就是在画饼。就算这老板到时候让你升职，写一年script的能力和写一年production code的能力也没得比。

说的好 我还是支持换组

讚樓主～

说的太好了 很多地方我也有同感

看完第二段就觉得lz是亚麻的

感觉楼主的心态很积极，不错，好多地方有同感。不过就像有人说的，换个组你能学到更多

tbu 发表于 2018-5-23 12:38
你再工作一年后回头看今天这些事又会有不同的想法，你会知道大老板是最善于画大饼和利用一些听起来很高大上 ...

谢谢你的建议！我觉得说得非常有道理。我觉得我可能是那种“既来之则安之”的人，能够尽可能在当前的环境想办法学到更多的东西，却忽视了如果换一个环境可能会学到更多的东西。

其实当时也有点担心即使换组，也不能保证新的组一定更好，而且看很多组对SDE I也不怎么招，所以纠结了一会就没行动了。目前我们开始开发新项目了所以还好，老板也说会在年底给我升职(hopefully)。不过目前的组就是bussiness logic太复杂，很花时间在理解业务逻辑上。你提醒得很好，等过段时间我应该要有所行动。

Euler57721 发表于 2018-5-23 13:00
作为一名Senior，一看这老板就是在画饼。就算这老板到时候让你升职，写一年script的能力和写一年produc ...

嗯是的，我当时也觉得他在忽悠我 lol