花时来信 | 工牌厂打工体验 | #0x04
Link
大家好！最近这封信拖延的时长比我想象的长许多… 当写下这封信的时候，我已经在工牌厂干了三个月并且已经离职了！
在离职前看到的网图
我刚入职时开始第三季度的 OKR 制定，到离职时最后的会议就是第四季度 OKR 会议，也算是完整经历了一个季度的工作。这个季度对项目来说似乎也称得上重要时期，组里持续了两个月周六加班的高强度工作，终于在我离职当天划上句号。项目正式公布了国服上线时间：
尽管网上对字节的工作氛围多有批评，但我这三个月来的实习体验相当不错。
首先在公司层面上，字节确实是相当“现代化”的一家企业：始终创业、多元兼容、坦诚清晰、求真务实、敢为极致。其中或许有很大的原因在于公司有庞大的海外业务。不管怎么说，我在办公室里确实看到了字节范的每一条。
在部门层面上，虽然不及抖音那样光鲜，但毕竟有了啊手这一大王牌，还称得上体面。主管相当靠谱，常谈论字节范的价值观，对我的实习安排也十分坦诚。同事也很愿意给我提供帮助。这大概就是我能获得良好的实习体验的原因。
不可否认，赶工上线国服的工作强度的确很大，不过我实习期间做的是代码的静态检查，相对独立于主项目，因此也没有承受什么压力。公司的免费三餐和健身馆也很大程度上减少了日常的负担。
说到自己身上。作为我的第一次工作经历，我也由此接触了一个大型项目的运作逻辑和流程，当然也见识了这样庞大的代码库（屎山）为什么是能跑的。而正好我的工作内容也是对代码做静态检查。
真实的工作经历也展现出了我的很多不足。在接手静态检查的工作时，前辈给我开了一批工单，对应需要实现的检查规则。然而在离职时，这些工单大部分没有完成——我的主要工作其实是设计实现了一套底层的类型分析，无法直接对应到工单上。
这一方面可以说工单的设置其实不合理，另一方面也可以说我对实际落地效果不够重视。而这件事本身其实也反映出，我对这套基于工单的工作流程不够重视，也缺少跟主管的沟通。
虽然工单流程在我这里有些失效，但我在前辈的催促下确实制订了一个工作分解和估时的时间表。我一直觉得制定时间表是很痛苦的，毕竟我自己也不知道这项工作要做多久。但这可能也说明了能力的不足：如果我对一项工作的实现路径很清晰，那应该是能做出一个靠谱的时间表的。而这也是团队协作的基础。
在答辩时，评委对我的静态检查工作提了一个开放式的问题：“这里成百上千个检查出来的问题，你要怎么推动它们的修复。”乍一听这个问题很没道理，毕竟我只负责静态检查工具的开发，修复当然是交给责任人去修复呀。但细细一想确实如此：很多代码写的不太对，但是能跑，因而也不怎么受重视；而我应该负责的并不只是“静态检查工具”，而是“团队的代码质量”。另一个角度来说，推动别人去做一件我重视的事情，大概也是一项有用的能力。
因此在离职前的最后三天，我又写了个 VSCode 的插件来显示静态检查报告。一来在编辑器里抬头不见低头见的报错，大约更能让人警觉；二来也期望这能帮助大家更轻松地修复问题。
谈论软件工程，我学到的一大道理是：屎山其实是能跑的。
对于自己写的小玩具，往往规模是可以控制的，确保代码的逻辑是充分完整正确的——如果不行，那这个小玩具就会被抛弃。
但对于一个庞大的工程，代码失控是不可避免的，屎山必然会产生，而且我也不能一走了之，更不可能“用 Rust 重写”。因此必须接受一个事实：屎山是能跑的。而对屎山的管控要从一开始就做起——我们在编码时预设这段代码会成为屎山，因此要插入足够多的 log 打印等信息，这大概也就是所谓的“可观测性”。
也给自己设计一个新的季度 OKR：
- 投入开发 ，学习理解SQL、数据库和向量。获得自我管理的能力。pgvecto.rstensorchord • Updated Oct 14, 2023
- 运营一个社团的博客催稿小组，并且能够固化成为社团的定番。获得运营的能力。
- 完成 xv6 最后一章文件系统的学习，在 OpenDAL 提一个 feature 的 PR。
- 学习基本的 PL ，理解数据流和控制流分析。
祝大家生活愉快！