最后一天的胡思乱想不一定对（别问我下一站，问就是阿兹卡班🤬）

1. 两种工程师。我是那种以实验+观测去触碰未知领域的工程师，所以一个经常发生的对话是，领导问我一件我不知道的事情，我第一反应是思考怎么去构造实验，如：“wireguard control plane 的性能瓶颈是什么”——“不知，但我可以构造一个中等规模集群让节点不断加入和退出触发大量控制平面事件，观测控制面同步延时和 cpu 消耗，etc.” 这自然是不错的思维方式，但另一种工程师，我的 vertical lead，教我在大脑里走一遍业务逻辑，关注可能的性能热点——几次更表、哪些数据随规模线性增加、多少临界区、etc. 我很欣赏这种解决问题的方法，虽然这要求对业务逻辑极其熟稔，但解决问题时的极端高效让我印象非常深刻：当我还在拉集群准备抓包观测时对方可能就已经靠想象梳理出可能的根因，非常强。我愿称之为，靠想象解决问题的能力，我见证过，我学习。

2. 在职场说好话和做好事同样重要——马杰克《年会不能停》。我愿改为：简洁正确的代码变更和仔细切分的 commit + 仔细书写的 commit message 同样重要。可惜大部分程序员并无此习惯，大部分社区也并不要求，合并的时候还是 squash merge。有几条最简单的可以很容易做到的：（若是 rebase merge）需考虑 git bisect 性；尽量把“重构”的代码单独塞 commit 标记为无业务逻辑变动；commit message 写小作文详细记录前因后果和可能的方案；考虑以业务场景的区分来切分 commit。需要一段时间的观摩学习练习才能有所感悟，不要以为“我的 reviewer 是大佬ta肯定懂这个 bug 的前因后果我蜻蜓点水一下就行了懒得写作文”。不，他们不懂，小作文写起来。

3. “达成共识” 是大项目推进大变更的核心之一，这也是小 lead 的最重要的工作之一，是我做得超烂的部分。解决问题的能力我绰绰有余，但若要辐射出更大的影响力（impact🤬），不仅要能自己解决问题，更要能带动上下级（上：manager；下：工程师）达成共识，这个共识大到变更的战略意义，小到角落场景的技术困难，中到测试方案，如果不能达成共识就会来回拉扯——“你为什么要这样做而不是那样做”——工程师疲惫、项目失控。其实在开源社区达成共识更是瓶颈，我开玩笑说给某子系统提大便更，先做个 demo + cover letter 写作文 + LPC 传教，半年以上过去了；第二年在技术细节上来回拉扯，收获若干 ack + nack，在 LPC 和子系统维护者不能达成技术细节共识，又一年过去了；第三年这个 patchset 可以合并的话简直堪称人月神话。这就是这个世界大工程的复杂度，我已经躺平了。顺便一提，因此我对跨时区远程工作持有负面看法，达成共识的成本左移。

4. 开心最重要，我是开心超人，我一开心就超人。在写代码谋生十年之后我依然非常热爱代码，我的笔记本上每隔几天就写下乱七八道的工程想法、未解决问题、想做的实验，但我并不享受工作里的枯燥、内耗、内卷。我承认自己的能力不足，在努力尝试（高压高强度加班）几个月之后，项目还是一副失控边缘的样子，上不满意，下很疲惫，我精力被榨干失去探索代码世界的想象力，我想，去他妈的，我炒自己鱿鱼总行吧。加班开会？影响我博德之门全成就了，再见。别忘了我的新年祝福： Make Love, Not Code.

那么，阿兹卡班见🤬