工程师加班

昨晚十一点半，我收到一条企业微信消息，师加来自组里刚转正的工程小张：“哥，那个并发压测的师加bug我复现了，是工程线程池配置漏了拒绝策略，明天早上改完再跑一轮。师加” 我回了个“行”，工程然后盯着屏幕愣了几秒——这已经是师加他这个月第四次在凌晨发技术结论了。不是工程卷，是师加那个bug确实卡了三天，他不想拖到第二天站会再被问进度。工程

工程师加班这件事，师加外人看是工程“996”，内行看是师加“上下文切换的代价”。写代码不像搬砖，工程搬砖累了歇十分钟还能接着搬。你正在调试一个内存泄漏，堆栈翻到第三层，突然被拉进一个需求评审会，四十分钟后回来，脑子里那根线断了，得重新jstack、重新看日志、重新把调用链在脑子里拼一遍。这一来一回，半小时没了。所以很多工程师宁愿晚上留下来，不是为了给谁看，而是晚上没人打断。白天被会议切碎的注意力，晚上才能重新焊起来。

我待过一家做金融系统的公司，上线窗口固定在每周四凌晨。周三晚上整个组都在，没人强制，但没人走。因为你知道那个分布式事务的补偿逻辑是你写的，万一凌晨两点报警了，你不在，别人得花两小时才能摸到你的代码逻辑。这种加班不是制度逼的，是责任边界模糊导致的——代码是你写的，线上出事你跑不掉。后来我学乖了，写关键模块时把注释写得像说明书，连变量命名都带上下文，就是为了万一自己不在，别人能五分钟接手。这算是一种自救。

但有些加班纯粹是管理颗粒度太粗造成的。我见过一个团队，每天站会开四十分钟，每个人轮流讲昨天干了啥今天干啥，PM还要追问每个细节。工程师为了在站会上有东西讲，不得不把本来一小时能做完的事拆成三件，显得产出多。这种表演式加班，根子在管理者不信任工程师的自驱力，非要用可见的时长来量化不可见的思考。结果就是大家白天演戏，晚上干活。

我现在的做法是：把加班分成两类。一类是“事故驱动”，线上挂了、数据错了，这种必须立刻处理，没得商量。另一类是“进度驱动”，需求排期太紧，正常工时做不完。第二类我会直接跟PM说，这个排期我做不到，要么砍需求要么加人，我不靠加班补。刚开始说这话时有点虚，怕被觉得不够拼。后来发现，你越是不吭声地加班补排期，PM越觉得排期合理，下次还这么排。你说了，他反而会重新评估。

还有个细节：很多工程师加班时效率极低。我观察过，晚上八点后的代码提交，bug率比白天高不少。因为大脑累了，写出来的东西自己第二天看都想抽自己。所以我现在给自己定了个规矩：晚上九点后不写新功能，只做三件事——回邮件、看日志、写注释。写注释最安全，因为不改变逻辑，还能帮明天的自己省时间。

说到底，加班不是工程师的勋章，也不是原罪。它是一个信号，告诉你哪里出了问题——可能是排期，可能是流程，可能是你自己白天被切得太碎。看懂这个信号，比熬到几点更重要。小张今早十点把修复推上去了，压测通过。他下午请了半天假去看牙，我批了。这才是正常的样子。

(责任编辑：休闲)