半年过去，我的 dream job 怎么样了
虽然我毫无“事业心”，对技术也毫无热情，最初也是纯为了钱和福利入的码农行，但是因为彻底贯彻“喜欢就买，不行就分”的原则，我倒是在 7 年多的职业生涯里相对于同届 peer 而言折腾过不少公司，包括最近这一次求职中期还在探索。虽然没有碰到过于奇葩和惨痛的精力，也确实对这个工种由读书时的反感，到择业时的勉强介绍，到近两年的逐渐有点喜欢甚至还会自己搞 side project 的地步。但于正职工作而言，直到最近的一份工作才称得上我的“dream job”。
点击查看无审原文、原图及更新：https://blog.douchi.space/?p=1884
但开始这份“dream job”，我有点诚惶诚恐。说是 dream 是因为：
- 找工作前几周爱上了这个产品
- 面试期间聊得来，感觉公司 culture 很合
- pre-ipo 既有 startup 的灵动又有基本确定能跟大厂 compete 的价钱
诚惶诚恐是因为：
- 从上面那张可视化简历和我过去无数的工作厌班 blog 不难看出我 bunrout 的速度越来越快，次次裸辞，不知道这次深度用了不到一个月就喜欢上的产品带来的 enthusiasm 能跟工作的苟且较劲多久
- 面试光环不代表实际工作体验，事实上我第二份互联网大厂工作的组也聊得非常好产品和行业也喜欢，但结果是 manager 是个傻屌，折腾没多久我在组散之前转了也对那个公司丧失兴趣飞速跑路了。所以虽然面试时候跟现在的公司相谈甚欢是我有史以来最好的面试体验，但也难保能持续到实际工作中
现在离我入职已经过去了快 7 个月，我想大概是时候停下脚步 reflect 一下这份“dream job”了。
这是现充过度没空写的 2、3 月 Patreon 二合一投票票选结果其中之一。欢迎金主们去四月的投票选出接下来的命题帮助我重新 get back on track:
- Portable Monitor 体验：不止是移动办公
- 那些鼓舞人心的单人开发的独立游戏们
- 为什么 RSS 仍然是信息摄入最好的选择
- 你为什么需要一个 discord 社交圈
点击查看无审原文、原图及更新：https://blog.douchi.space/?p=1884
过去的半年我做了什么
首先，工作的 tech stack 基本上跟上一个公司相同：python + typescript fullstack，那里有需要上哪里。上一个公司虽然是 backend 组但是公司太小就也啥活儿都干，这个公司是 premium 产品的 growth 组，哪里需要点哪里。
看了一下自己的 PR，总共 49 个，大多数是 10~100 行左右的小改，记忆中 500~1000 行量级的大概（除了 clean up）只有 3 组。基本上带的稍大的（超过 1 周）的项目也就 3 个，其他都是 bite size 小项目（但其实百来行的做起来就挺有成就感了）。
组里每个项目基本模式是 PM 搞事情 + designer 出活儿 + eng 出 design + 一两个 eng 写码。我加入的时候这个组包括我 4 个 senior（其中一个 tech lead，一个 Android eng）+ 2 个 mid level eng. 我的一个项目带了一个 SDE II，剩下都是一个人做。
premium product growth 嘛，做的无非就是 life cycle 那些，个性化个 cancel model 啦、加个 notification bar 啦、做个提醒邮件啦、哪里加个 upsell 啦、implement 个 promotion 啦，处理一下 edge case 之类的。当然因为我们对应的 premium product 组也小，所以偶尔我们 growth 组也做功能性的东西，比如新加一些视觉糖啦，做一些内部工具方便大家 self service 或者测试之类的。
开发运维体验
注：本部分 target audience 是有大型项目经验的码农，专有名词就不解释了（不然光解释就比全文长了），请非码农略过本段。
配环境老大难问题什么的不存在的，顶多刚进去的时候 local dev 整个 app monorepo 在本地跑 intel mbp 16 风扇飞机引擎，但是没多久 remote dev box 就大规模推广了，偶尔碰到环境问题一般 rebase 一下就解决，要么公司 eng channel 一搜要么已经有解决方案了，要么有 breakage status update，要么提问题 tools help 一般很快就解决了。
本地跑 test 没什么问题，pytest 本来就简单，随手 copy & paste 一个框架自己新加一个文件立刻可以开始写，公司的 CLI run test 也 well-maintained 没遇到过什么问题，PR 发出去 github webhook 一堆 testsuite 跑起来也挺让人安心的（当然 move fast 还有很多 test 要加，不过 test coverage 和代码质量比某以 move fast 著称的大厂强多了）。我回想起早年在某大厂本地 java dev 被配环境和开新 test setup 支配的恐惧现在不禁觉得过于幸福（当然也不是所有大厂都这样， move fast 大厂的 automation test 体验就相当不错，但也就是跟现公司差不多顺滑度而已）。
此外，虽然 move fast 但是大家 care about code quality。除了常见的 PR & eng spec comments & pair coding（虽然社恐如我我很少参加但是每次都受益匪浅）& eng channel async chat 能经常学到很多，就连 clean up task 大家也不含糊，尽量不 leave 辣鸡 behind，experiment complete 了立马互相提醒 clean up。
然后因为产品是个 electron App，aka 整个 client side 是个套壳 Chrome，因此 web 和 desktop 的产品体验是一样的（底层跟 OS 对接和 RTC 的部分有大神组们搞，产品组完全不用操心，把 client 当 web 测就行了），甚至能在 App 里直接打开 dev console，快速 debug 非常方便。
我最喜欢的部分是，client 可以直接 build override，拉一个 GitHub branch 就可以直接测 WIP 的代码，如果改动只有前端的话开发测试、给非技术岗位当 working prototype 测 UX和分享给外组乃至公司外部 partner 试用超级方便，还能设置可见用户和过期时间等等。此外 App 本身就带的 developer option 也提供很多方便。
我至今没有 ssh 过任何一个 prod fleet 或者看过 prod log，metric 出于兴趣看过一些。fleet 在哪怎么 deploy 的运行状态如何完全不知道，没有 handle 过任何 incident。不过有大 promotion 临时出问题的时候是有看同事加班搞的。
产品组 oncall 也不存在的，incident handle 都在 infra 那儿，产品组只有几个月一次的 on-point rotation（不过马上要被 broken up 了），business hour triage 一些进来的 bug/问题，找 owner 也很容易（找不到的话自己修通常也很容易）。
跟我之前呆过的几家公司比：
- 大厂 1 每个 team 自己 own 从代码到 deployment 到 fleet,从 prod issue sev 1 到半夜日常被 dependency 搞挂 sev2 到检测一堆 metrics 的 oncall 的恐惧记忆犹新
- 大厂 2 第一个组完全没 oncall 过，第二个组处理 ticket 一头雾水一知半解公司的 Tooling 也非常垃圾，虽然不用 24 小时 oncall 但是依然最讨厌的部分是 oncall
- 前一份 startup 虽然是 infra 组但是是 B2B 所以也是 business hour，但是有千奇百怪搞不明白的小问题（因为公司产品核心技术比较 specialized 不是 general 互联网产品），也会有点头大。
唯一一个不大满意的地方是至今我们前端居然还是所有 code single branch manual deploy. 即，要 deploy 的话，在公司产品了 run 一个 bot command 你的 commit 之前所有人的代码都跟着你的一起上 prod。并且居然任何 eng 都能在任何时间 deploy。后端我刚进去的时候也是这样，前阵子才改成 continous deployment.
TLDR – 集大厂（Tooling 完善甚至超过我见过很多大厂）和小厂（速度超快，你有信心的话半小时上 prod） 的好处于一身，又很少大厂（错综复杂令人头大的环境）和小厂（很多 manual work 要自己做）的毛病，oncall 也暂时没碰到太大压力第一次就能较为游刃有余，爽。
点击查看无审原文、原图及更新：https://blog.douchi.space/?p=1884
典型项目流程
自己熟悉领域的小 bug 或者小 adhoc task 进来随手修了就不说了。
完整的项目构成，基本是 EM（engineer manager，aka 我的直系上司）和 PM 商量出一些项目（来自于 quarter planning 以及之前的 brain storm、平时 eng 提出的 pain point，外组不知道哪里来的外部需求等等）之后，PM 开始写 product spec，EM 跟 eng 商量协定人选，eng 写 tech spec。
这个 tech spec 的复杂度和 review 流程严谨度介于 Amazon（非常 structured 很多甚至要 async comment 完之后再开会 review 好几轮） 和 Facebook（很多地方 design review 不存在的）之间。一般就是 eng 给自己写个称不上 system design 但又比 notes 严谨一些的文档让其他 eng 看看合不合理（product 方面非技术能看懂的毕竟已经在 product spec 里了）。范围从组内到 org 再到全公司都有（前两天刚被元老 senior staff comment 过），一般是 async comment 的形式。因为较为轻度所以写的时候 reluctant 程度也低了一些，就是把自己 dive deep code 的 notes 整理一下方便没有 context 的 eng 看懂以便提供参考意见即可，不是特别形式化。
PM 的 product spec 会成型较早，大体确定之后 PM 和 designer 商量搞出一个 design draft，之后 po 到 team 和 designer channel 里大家 comment & review。这个 design 不大确定，我遇到过几次码写好之后大家用 build override 测试又提出修改意见然后改 design 的。不知道 designer 会不会 frustrated，反正我带薪来回改没有被这个困扰到。
Design draft 或者 product spec 基本定稿之后 PM 一般会开个 kick off meeting 所有做这个项目的人（PM、desinge、eng、data scientist、marketing manager）开个半小时 kick off meeting 讲一下 high level goals & UX。
与此同时因为是 growth 组，所以 eng & PM & DS 一般会一起商量出一个 experiment plan，定一下什么东西要 log，哪些用户 eligible 之类。
开发部分我暂时只带过另一个人一个项目，组里我进来之后最大的项目也就是两人的，其他都是各做各的。manager 一直想给我们找点大项目，但本非合作型码农窃喜一个人写。又不想升职要啥 complexity。自己快乐写码能摸鱼的空间也比较大。
我很喜欢的一点是组里每个人都可以对项目有足够影响力，即便在开发的时候发现要改的地方如果合理也不会有什么阻力，我跟 PM 和 designer pair 过几次商量出来比原来更好的方案各方都很有成就感。
如前面提到的公司的 testing & deployment & infra 体验意外地好，所以作为产品组基本除了写 tech design 就是写码，中间穿插跟 PM 和 designer 和其他组商量细节。开发运维本身几乎没什么 overhead。当然要提供 launch support，出了大问题 bug 得自己修。
launch 了之后会在各个 channel 宣布一下，每两周 org demo 也不用跟组里商量自己在 notion doc 里报名就行。如果是 experiment 的话收集够 data 会再进行一个同步或者 async 的 experiment result readout。之后根据要不要 ship 的决定做一些 cleanup。
绝大多数项目没什么 deadline（我做过一个跟 holiday 相关的有，当时临近去欧洲玩非常 stressful 熬夜通宵加班，最后各种问题在欧洲的时候还是被迫营业，不过也只是 stressful 没有 burnout 让我对这个 dream job 的持久性稍微有了点信心），既 move fast 又不 pushy，又不向 B2B 养老厂那么没 deadline 但是无聊。下面是我的 commit history，就其实摸鱼空间还是很大的，但想不摸鱼的时候又不无聊。
点击查看无审原文、原图及更新：https://blog.douchi.space/?p=1884
TLDR：没有大厂那么啰嗦和细分，因此有足够 cross function 合作，对产品的影响也比较大，而且从头到尾从前到后能很快搞出来一个完整的功能，很有成就感。又能得到比小厂大很多 data/user to work with 和更大 impact，看到 experiment readout 里的数字喜滋滋。
公司文化、行政、前景等
首先我不大是能被工作完全绑住的人，再喜欢工作也必须要有工作之外的事情和自由，而且讨厌 commute，因此即便还住在 tech hub 我也想要 remote work，方便说走就走出去 working holiday 做半个 digital nomad。本司 hybird friendly 的模式满足这个条件，这点要感谢 COVID（pre-covid 更偏向 in-office 一些，现在没有大厂的各种 BS 彻底拥抱 hybird 了，又比纯 remote 公司感觉更人情味一些，就像我也不想当纯住房车或者背包那种 digital nomad，我还是想有个 homebase 满足我的物欲，做牵线风筝最爽）。
美国互联网公司一般都比较 progressive 无需多说，但本司让我感受到大家是真诚的 care 而且 trying to live up to it. 比如员工福利首页（不是隐藏小字）就有每人 gender affirmation fund，而且我从面试到实际工作也确实见过比之前呆过其他公司更多的 transgender/non-binary 等。稍微大型会有不熟的人出现的会上每个发言人（包括 CEO 在内的 executive 们）哪怕非常顺直都会介绍自己 pronoun。
此外 CEO 本人毕竟是在 all hands 直接说过诸如 （On California governor recall case vote day 鼓励大家出去投票) If you want to vote for some randomly generated right wing candidate, go vote, that’s your right 和（有人把他和 Elon Musk 类比员工问什么看法他说）that’s an insult 的人，感觉三观非常合。
行政没什么 BS，各个 function role 都有比较完善且方便的联系机制，绝大多数事在 channel 里问一声就会很快得到回复，policy 大都明文集中在几个地方很容易找，不像我在大厂 1 找个病假 policy 翻了 internal search 和十几个 tool 都没找到一个 source of truth，最后还得接一个专门的 leave team 电话来商量，非常不透明。
每周 all hands CEO 依然全程参加，一般是一些重大宣布和一些 success story + 最后 Q&A。all hands chat 还能严肃认真的话题非常激烈有深度的 no-filter 的争论，不严肃的话题 meme 和 shit posting 横飞。
组里氛围也非常 chill，之前 happy hour 一位大哥聊到兴起跟大家讨论起 high 了之后去吃 fine dining 体验佳、eng 互相闲聊开会摸鱼等。但又不像 finance bro 那种恶臭没边界氛围（比如大哥问了两遍如果有人对 recreational drug use not comfortable plz tell me to shut up）。社恐和特别喜欢 social 的共存融洽，暂时没见到美式（皮笑肉不笑）热情 peer pressure.
能感觉到绝大多数同事都真心热爱这个产品（当然临近 IPO 发财和职业发展优先级更高的人当然会越来越多），比如 hackweek、polish week 会有很多推陈出新的点子，从各种 announcement 了解到其他组在做的东西也感觉非常有价值是我作为用户想要的东西。从各种会 share 的 customer story、我平时看到的 Twitter、reddit 互动和我自己的 community 来看，受众用户也非常热爱这个产品，虽然上手有一定门槛但在年轻用户群已经有了基础。而我也差不多重度使用一年了，热情未减，而且发现了更多这个产品的不可替代性，甚至暂时非刻意发展的领域都已经比该领域内现有的细分产品体验更好。
TLDR：三观豆瓣/Mastodon友好，社恐 geek 友好但也很 inclusive 较为 diverse，very transparent & very little BS.
点击查看无审原文、原图及更新：https://blog.douchi.space/?p=1884
Verdict
写了这么多，所以过了半年这份 dream job 到底禁住考验了吗？答案或许不止是是，还不降反增。大概有如下理由：
- 日常核心工作体验佳。产品再热爱文化再融洽，如果本职工作做起来非常痛苦的话也是坚持不下去的
- 我依然对这个产品有热情，成就感有
- 喜欢公司气场，老板同事可爱，文化 inclusive（无论是对员工和用户背景、还是对不同意见、或者是不同工作形式等）
- 看好产品前景
像开头说过的，我一开始根本不是因为喜欢入的行，工作头几年也并没有特别喜欢这个职业本身。但是在不断尝试中开始逐渐找到乐趣，也误打误撞（literally 恰好的时间开始用这个产品才选了这家公司，甚至开始找工作的时候这家还远非第一选择）找到了现在这份 dream job。
我觉得除了部分有使命感或者能为止奋斗终身事业的人，大部分像我一样的普通人如果能过了“追求一步到位”这种精神枷锁愿意局部最优走一步看一步的话会快乐很多。比如工作——如果我当初坚持本科对写码的不良印象没有入这个行（当然，运气成分很大），现在不知道热不热爱职业，至少物质上不会过得比现在轻松，由此而来 lifestyle 也会有很多限制（满世界乱跑、喜欢电子产品等等）。又比如买房（仅针对想买房的人，不想买的 perfectly fine），见过很多人预算内这不满意那有点遗憾，结果同期一开始就买了妥协一些的人省下的成本和增值都升级第二套了。
在工作里我们把这个东西叫 MVP——先搞出一个符合当时首要目标局部最优的 Minimum Viable Product（我觉得这是硬凑词，我更喜欢称之为 minimum working version），然后投入到实际使用里再 iterate，运气不好确认了方向不对就及时止损，碰到正反馈就朝这个方向迅速改进，很多时候比闭门造车想憋个大招结果错过了星星又错过了月亮效果更好也少更多精神负担。
点击查看无审原文、原图及更新：https://blog.douchi.space/?p=1884
如果您觉得本文对您有帮助，想支持我的博客创作，或者有特定的内容想要看到，或者干脆就想单独聊五毛钱，欢迎点击下面按钮成为我的金主：
