RT Log 6: Career summary v3
刚在看冬奥女子花滑决赛,特鲁索娃太过分了这么多四周跳,不过妹子长大了之后感觉没有原来轻盈了。结果看到有人在询问第三份总结的事情,想了想自从上次跳槽过了快半年了,也差不多是时候写一下新的总结。
这篇文章会分为两个部分,包含上一份工作和这份工作的总结。
上一份工作
这份工作主要是带一个团队在初创公司搭数据平台,做下来最大的感受就是累,也因此觉得回去做IC不失为一个不错的选择。管理团队人员的成长同时也要赶各种deadline,实际上对整个团队的成长都不好。成员没有得到足够的学习时间,没办法积累,而我也差不多被掏空了,无论是耐心还是精力。
收获1:技术上的自我实现
当然收获是不小的,主要是证明了自己能够带着一群人从零搭起来一整套东西,而且是scalable和extensible的(at least to some extent)。当然从各个方面来说一个创业公司的数据架构不需要太复杂,所以也不能很说明问题。尤其是这几年data stack这一块变化实在太快了,当我还在为前移到Airflow 2暗自窃喜的时候 (可以看下我这篇文章DE Log 7: Migrating from Airflow 1 to 2),过了一年已经有人开始说其实我们本不需要Airflow (https://blog.fal.ai/the-unbundling-of-airflow-2/)。其他方面就是愈发认可开源的理念,虽然我并不主动贡献开源 - 主要是因为懒, 但是我开始积极提issue和讨论bug。因为用了诸如dbt之类的开源工具之后发现,自己吭哧写不如跟社区一起进步。
这一点上,我觉得无论大厂小厂都应该花时间去看看,尤其是数据这一块。小厂造轮子浪费时间质量不一定比开源好(先承认自己是平庸的),大厂造轮子你作为个体会比较难看到全局,从学习角度来说开源的工具,哪怕玩一玩还是有很大帮助的。多看看博客发现发现新工具啊啥的,比如
https://github.com/monosidev/monosi
https://github.com/re-data/re-data
这些最终可能最终不一定能做起来,但是能看一下他们到底在解决什么问题,哪些可以被我们工作中取其精华加以利用。
收获2:大概率排除了一种职业规划
除了技术上的自我实现,也正儿八经在管理团队,也曾经想过要不要写一点这方面的总结。最终还是放弃了,第一觉得也没啥好说的,第二是最终意识到自己不喜欢做people manager。不是说我不关心成员的个人成长,我其实很关心,但是我觉得培养一个人的成就感还是不如设计系统本身的成就感强烈。可能这也促使我在现在的工作中更多的专注于代码和产出而不是人,虽然现在要升职还是得高一些有的没的。
关于数据工程的职业细分,我也写过一篇文章(英语):DE Log 8: Thoughts on Data Engineering Specialisations
收获3:公司文化的认同
现在说文化认同这件事有点老调重弹,但是实际上随着年龄工龄的增长,这个因素在我选择offer的时候变的愈发重要,这次跳槽面试的trigger也是对前公司文化的不认同,在疫情期间这一点显得尤为突出。面试过程中,包括出结果之后最后的选择也是基于文化而决定的。拒了腾讯选了现在的公司那当然是因为文化,没人敢说去腾讯学习不到东西对吧,或者发展前景不好。当然不得不说因为数据工程本身细分出来起步晚,所以市场还是很小,求职者的bargaining power还是很强的。
这一份工作
我干啥
目前的工作方向是让做一点工具让我们的数据湖仓(data lakehouse?) 能够支持自助操作,比如让其他团队的人,无论你是不是技术人员,选择要往湖里加什么新数据,要schedule什么batch job 或者real time streaming job,这个设计方向也跟我这几年来的感受很吻合。例如在上一份工作中,我个人总是先做出一个框架,然后让团队成员去填充具体的业务内容,本质上跟我现在的工作是很类似的,在职责上也感觉是同时在做开发和数据产品经理的感觉。未来我相信没有太多的人会需要手动setup pipeline了 ,可能都是configuration as a service。
好的方面
选这份工作的原因基本上也是为啥我喜欢目前这份工作的原因吧,所以面试时传达的承诺基本都实现了:
- 这份工作基本上就是IC目前,闷头写代码,开始啥会不开,有会你不去好像也没事,只跟美国的lead async 交流,简直爽歪歪。我个人是很讨厌开会的,async的交流我觉得能有效避免废话,能让你有条理的想清楚自己要说啥 - 当然能随时有条理的说话这也很重要,加上进来过试用期就要当什么pod lead 带一个小弟于是又开始了开一点会的节奏
- 工作模式当然一直在家,也很自由。早上三个小时集中,下午三小时,晚上看心情和累不累可以酌情工作,兴致来了也会多干一点,所以本质上已经没有加班的概念了,但是不会累,因为这样工作本身是不断带来正反馈的
- 文化很好,基本的workload management和友好交流模式就不提了,基本硅谷风格吧。也不是水,毕竟还是(独角兽)创业公司,虽然团队水平不是顶尖,但都很有学习的氛围和动力
- 技术对我是新的,spark + hive + presto/trino 属于我知道存在但是没咋用过的东西,不过知识上的迁移成本其实不大。因为我本身只是一个使用者,很多东西看看docs 看看别人讲的也就理解了。比如partition keys 跟redshift distkey 的使用和注意事项其实是很相似的。除此之外,还做了delta lake的迁移。虽然我不确认这一定是一个好技术,但是能在一个公司里大规模的真实体验一下这种使用场景,帮助也还是挺大的。
工作的时长和分配
由于工作量的合理分配,我有更多的时间去思考一整个季度的工作规划。虽然我们团队不讲什么okr kpi模式,但是就总体设计上应该是更偏向okr。 比如我需要保持pipeline health在99.5%,那我需要做什么?我需要哪些checks,哪些自愈功能。
同时因为写代码比原来更能集中,写高质量代码的熟练度也是有上升的(废话)。在python下严格执行type hinting和dataclass passing,然后实现了一些strategy pattern之类的东西,总之接手原先的代码之后发现自己在实现一些东西前总能想一想能不能做一些小的重构,慢慢把整个代码库搞得还行。也同时践行了那句,
Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.
确实在写一些懒代码之前会问自己几遍,这真的没时间好好写吗?
最后想说一下写文档的熟练度,感谢我至少在毕业之后依然偶尔在写博客。由于一直是远程工作和异步交流,所以文档很重要。很多时候我写个分享文档可能就是要写个半天,但是幸好这个公司把文档当做产出(我觉得这也是正确的)。
总体来说,因为整个公司的人员和团队结构就是分布式且分散的,当然这是ceo本来的设计。他想牺牲一部分效率来让整个公司的文化更团结,也更多元,就不会出现什么哪里是总部哪里是分部的结构,虽然决定过程长一些,但是最终结果看起来是不错的。不过这也导致了一些工程上的冗余,虽然我对目前公司的总体数据架构不是很满意 - 但是就我目前操作的这一块地盘来说我还是有比较大的操作空间,最终做出来的impact也是比较大的,也就是说我还比较能在目前的工作中找到意义,故比较满意。
升职规划
好巧不巧明天要写outcomes docs,就是一个说明自己干了啥为什么值得一个升职加薪的文档。所以短期内可以争取一下,感觉自己进来之后主要成就还是比较多的。升职不重要,钱比较重要说实话。如果还可以的话也可以过几年指望这个公司上市毕竟是独角兽哈。
好了睡觉了 - 现在由于早上8点要起床跟美国开会,睡得也比原来早了,挺好的。