一个程序员自述,他留下3000多次文档提交,离职后月薪2万的岗位被4千实习生接手:最先被拿走的不是最难的活,是最说得清的活

QUOTE

文档能教人接手，不能替你保住位置。

—— 天总会晴

2020 年，一个程序员在 V2EX 上吐槽过自己的离职交接。

他长期维护项目的文档库，组件、API、配置、怎么启动，全写得清清楚楚。光他自己提交的 commit，就有 3000 多个。接手的实习生照着文档做，一个礼拜就能上手。

离职后，前同事跟他说，那个 HR 天天在老板面前邀功：招了个 4K 的实习生，就把他这个 2W 的主工程师给替代了。

他气得不行，说自己以后要是再好好写文档，就是傻逼。

这事看完，多数人会得出同一个结论：文档别写，注释别加，最好离了你谁都跑不动。

我不同意。

故意把事讲含糊，接手的人确实会多熬几个通宵。可公司重新分工时，看的是这块活能不能拆出去，不是别人接手时熬了几晚。

这就像搬家。最先被搬上车的，往往是封好箱、贴好标签的东西。不是它不值钱，是别人一看就知道怎么搬。

活也一样。步骤写得越明白，别人接得越快。你拦不住这一步，也不该靠把文档写烂去拦。把事写清楚是你的本事；故意写烂来卡人，反而掉价。

实习生一周接住的，只是文档里那部分活。组件怎么启动，API 怎么调，报错先查哪里，都写在纸上了。剩下的，帖子没提，那个 HR 也未必看得见。

线上出了故障，先回滚还是再扛十分钟；测试和产品各说各有理，先找谁把口径定下来；业务今晚非要上线，哪个风险能冒、哪个碰不得。

这些事没有固定步骤，也写不进交接文档。可真出了岔子，总得有一个人出来拍板、出来担着。

能把步骤讲明白，是能力。手里只剩步骤，才危险。

换作是我，手里真有一件闭着眼都会做的活，我会照写交接，也会带接的人。但谈的时候，我会把另一件事一起摆上桌：

“这块我周五能交出去，接的人我也可以带。空出来的时间，我想接那件一直卡在测试和产品之间的事。优先级我来定，出了问题我负责。咱们今天把分工一起改清楚。”

这些话要在交接做完之前说。等文档全交了、人也带走了，再提，就成了求他补你一份活。

熟活交出去，你手上少一块。换回来的是出事时得有人扛的那摊事，那句“这个我负责”得轮到你来说。哪样更累，不用我说。

代价也得认。新活会出错，错了没法拿流程挡。领导也可能只收文档，不肯改分工。真碰上这种，至少你看清了他要的是省一笔钱，没打算给你让路。

那个程序员的委屈是真的。把东西写清楚，别人确实更容易接你手里的活。

但为了不被接走，就把文档写烂，守住的是一块别人暂时搬不动的活，未必是一条更长的路。

把步骤写进文档，把判断写进分工。