工作三年多,聊聊一句话

过去一年多自己在工作上有些折腾,在公司内部换了两次组,然后现在又回到了第一个组,这个剧情发展我自己都有些惊讶。在不同的环境下工作过之后,回到原组(以下用A组指代)竟然最舒服。这一年多来的感悟和收获概括一下,其实就一句话,知道自己喜欢什么,适合什么,以及想要什么。 在A组待到一年半的时候如愿升职了,于是就想着换一个组锻炼一下。换组的主要原因是觉得这个组的技术栈比较单一,新项目都是大同小异的,只是为了解决不同的业务问题而已,希望能去一个技术比较强的组学习。还有一个原因是觉得在这个组大家太 chill 了,其乐融融,也没什么压力,大家以前不是都说“有压力才有动力” 吗,那或许应该 push 一下自己。 于是有些草率地跑到了B组。说“草率”其实是后来的认识,当时还是试图做足功课,跟 manager 聊了两次,也跟组员聊了,还看了大家给 mgr 的打分,同时面试也不容易(给了我这个组 bar 很高的感觉),心想哪能有太大问题。可是后来在B组的经历挺不好的。当时的项目只有我跟另一个在远程工作的组员做,组里不同项目的人没什么交流,我感觉每天上班都跟机器一样,连说话的人都没有。当时的 mgr 仿佛更热衷于 science 方向而不是 managing ,经常跟 scientists 讨论研究问题,就是对我的体验和需求不怎么上心,很多问题不帮我解决。我曾经以为A组的 mgr 每周 one-on-one 问我开不开心没什么意义,以为A组每周的 happy hour 也没什么意义,那时才意识到有一个真正关心你的 mgr 是多么难得,才意识到工作的环境和组员的关系也是如此重要。 我曾经以为作为 mgr 也要“上进”,要不断 “学习” 才行,我那时才意识到,判断一个 manager 最简单的方法(从自己作为下属的角度)就是看 ta 关不关心你的需求,以及最重要的是能不能去真正帮你解决问题。不能看 ta 说了什么答应了什么,而要看 ta 到底做了什么。比如有些 mgr 会积极地让你写 career doc,但 ta 从来不跟你 review;有些 mgr 在 one-on-one 只讨论项目或者 ta 自己的想法,从来不问你的状态,或者问了却又不当回事;甚至有些从来不跟你设定一个正式的定期的 one-on-one. 而且通过这个经历,我对“什么组是好组”也有大概的认识。首先 mgr 要关心你的职业发展和需求,要关心你每天工作得是否开心,这是最基本的,我觉得这个标准的比重至少占 50%。然后是这个组做的项目好比较有意思,有技术上的挑战(每天做事不会觉得太无聊)。然后是组员之间的氛围要好。说白了这些都是决定你每天工作是否会开心,以及能否从工作中进步。像组里的 oncall/ops 是否会很重这些其他因素,如果这三点好了,都不会太差的,至少会往好的方向改进。我觉得这些方面对 junior engineer 比较重要,senior 受到直属 mgr 的限制应该会小很多。...

September 7, 2020

工作一年了,聊聊三件事

到明天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 来自动化完成这些小任务。...

May 23, 2018