花时来信 | 工牌厂打工体验 | #0x04

date
Oct 14, 2023
slug
hana-letter-0x04
status
Published
tags
Weekly
type
Post
pin
0
summary
因为办公室到处都要刷工牌。
大家好!最近这封信拖延的时长比我想象的长许多… 当写下这封信的时候,我已经在工牌厂干了三个月并且已经离职了!
notion image
在离职前看到的网图
我刚入职时开始第三季度的 OKR 制定,到离职时最后的会议就是第四季度 OKR 会议,也算是完整经历了一个季度的工作。这个季度对项目来说似乎也称得上重要时期,组里持续了两个月周六加班的高强度工作,终于在我离职当天划上句号。项目正式公布了国服上线时间:

尽管网上对字节的工作氛围多有批评,但我这三个月来的实习体验相当不错。
首先在公司层面上,字节确实是相当“现代化”的一家企业:始终创业、多元兼容、坦诚清晰、求真务实、敢为极致。其中或许有很大的原因在于公司有庞大的海外业务。不管怎么说,我在办公室里确实看到了字节范的每一条。
在部门层面上,虽然不及抖音那样光鲜,但毕竟有了啊手这一大王牌,还称得上体面。主管相当靠谱,常谈论字节范的价值观,对我的实习安排也十分坦诚。同事也很愿意给我提供帮助。这大概就是我能获得良好的实习体验的原因。
不可否认,赶工上线国服的工作强度的确很大,不过我实习期间做的是代码的静态检查,相对独立于主项目,因此也没有承受什么压力。公司的免费三餐和健身馆也很大程度上减少了日常的负担。
说到自己身上。作为我的第一次工作经历,我也由此接触了一个大型项目的运作逻辑和流程,当然也见识了这样庞大的代码库(屎山)为什么是能跑的。而正好我的工作内容也是对代码做静态检查。

真实的工作经历也展现出了我的很多不足。在接手静态检查的工作时,前辈给我开了一批工单,对应需要实现的检查规则。然而在离职时,这些工单大部分没有完成——我的主要工作其实是设计实现了一套底层的类型分析,无法直接对应到工单上。
这一方面可以说工单的设置其实不合理,另一方面也可以说我对实际落地效果不够重视。而这件事本身其实也反映出,我对这套基于工单的工作流程不够重视,也缺少跟主管的沟通。
虽然工单流程在我这里有些失效,但我在前辈的催促下确实制订了一个工作分解和估时的时间表。我一直觉得制定时间表是很痛苦的,毕竟我自己也不知道这项工作要做多久。但这可能也说明了能力的不足:如果我对一项工作的实现路径很清晰,那应该是能做出一个靠谱的时间表的。而这也是团队协作的基础。
在答辩时,评委对我的静态检查工作提了一个开放式的问题:“这里成百上千个检查出来的问题,你要怎么推动它们的修复。”乍一听这个问题很没道理,毕竟我只负责静态检查工具的开发,修复当然是交给责任人去修复呀。但细细一想确实如此:很多代码写的不太对,但是能跑,因而也不怎么受重视;而我应该负责的并不只是“静态检查工具”,而是“团队的代码质量”。另一个角度来说,推动别人去做一件我重视的事情,大概也是一项有用的能力。
因此在离职前的最后三天,我又写了个 VSCode 的插件来显示静态检查报告。一来在编辑器里抬头不见低头见的报错,大约更能让人警觉;二来也期望这能帮助大家更轻松地修复问题。

谈论软件工程,我学到的一大道理是:屎山其实是能跑的。
对于自己写的小玩具,往往规模是可以控制的,确保代码的逻辑是充分完整正确的——如果不行,那这个小玩具就会被抛弃。
但对于一个庞大的工程,代码失控是不可避免的,屎山必然会产生,而且我也不能一走了之,更不可能“用 Rust 重写”。因此必须接受一个事实:屎山是能跑的。而对屎山的管控要从一开始就做起——我们在编码时预设这段代码会成为屎山,因此要插入足够多的 log 打印等信息,这大概也就是所谓的“可观测性”。

也给自己设计一个新的季度 OKR:
  • 运营一个社团的博客催稿小组,并且能够固化成为社团的定番。获得运营的能力。
  • 完成 xv6 最后一章文件系统的学习,在 OpenDAL 提一个 feature 的 PR。
  • 学习基本的 PL ,理解数据流和控制流分析。
祝大家生活愉快!
 

© Beautyyu言醴 2022 - 2024