点击上方[全栈开发者社区]→右上角[...]→[设为星标⭐

点击领取全栈资料：全栈资料

当冲突爆发且到了必须让程序员离开时……那让他们“及时离开”吧。

假如你已经对某个开发人员下发解雇通知，你还会让他深度参与重要项目甚至把项目做完再走吗？放在今天，这个答案往往是显而易见的：不会。但如果是几十年前，那就未必了。

来自程序员的“报复”

近日 The Register 上有个热门帖子正好讨论了类似的话题。帖子背景是这样的：一位叫做“Thomas”的读者，用自己的亲身经历带大家梦回 70 年代。Thomas 当时在一家咨询公司供职，客户则是某国家医疗保健服务商。那时候一片岁月静好，如今这些“笨重”的工具库还远未出现。当时的开发思路非常明确：节约资源、优化代码。

Thomas 回忆道，当时所有代码都是用汇编语言写的，对于那些从未深入了解过的人来说，这就像是机器代码。“我们还得尽量为代码瘦身，这里头也涉及不少技巧。但现在大家已经不在乎了，充裕的资源让节约成了老古董。”

那时候 Thomas 才刚刚出道，从被他称为“二货”的前任手中接下来项目。Thomas 坦言，这位二货“其实很聪明，但又特别招人烦。”但看得出来，这并不是二货同学的本意，而是项目经理们不理解真实工作量、又把项目周期压得太紧。

尽管困难重重，二货同学还是坚持了下来。为了完成代码编写，他每周工作 100 个小时以上。Thomas 还记得，“他真的很想多加班、早点做完，但管理层却认为他只是想骗加班费。”

于是乎，二货跟管理层之间爆发了激烈冲突，最终他被解雇、上头还勒令他用一个月时间把项目做完。

一般人在这种状况下肯定要在项目里埋雷，但二货同学的报复方法却是另辟蹊径。你觉得 C 语言不好理解？那是还没跟汇编语言比较。要想理解汇编代码，良好的注释绝对必不可少。

所以二货更改了代码中的所有注释。乍看上去，这些注释还挺像那么回事，但实际内容跟代码功能已经没有任何关系了。

“接手工作之后，我的第一项任务就是为项目添加更多功能。这事当然做不成，因为我根本没法通过注释理解现有代码的作用。”情况被报了上去，但管理层压根不以为意，于是 Thomas 担心自己可能也会被解雇。为了保住工作，他又对代码进行了多次复核，结论是：注释完全是在胡说八道，没人能搞清这些代码到底在干什么。

“所以我最后只能删掉所有注释，再把二货同学的‘遗产’黑盒化。一年之后，我离开了项目组，但这些黑盒代码还是继续运行了五年，直到另外一家咨询公司全盘接管。”

但即使到今天，这些代码可能还是在某个隐秘的角落保持着运行。毕竟，黑盒代码就跟蟑螂一样顽强。

别瞎冒险

显而易见，Thomas 这个故事告诉我们的是，如果你想解雇某人，就该马上请他离开且别再碰项目了。

一名叫 Dave K 的网友对此深以为然，他认为，只要决定解雇任何重要人物，就要马上撤销这个人的访问权限，最好能让其马上离开。这相当于是尽职工作，对劳资双方都是保护。

Dave K 举例他曾面临过的类似状况——但被解雇的不是他，而是其顶头上司。人力通知说公司已经确定要被收购，新的母公司认为没必要保留两位 IT 主管。于是他当场就禁用了领导的账户、更改了所有共享密码（管理员账户密码），确保上司再也没法访问任何系统。“听起来挺残忍的，但这就是职业性。”——不管你多信任对方，只要确定离职了、这些权限就必须收回。

的确，另一角度来看，这确实未尝不是对离职者的保护。网友 yetanotheraoc 表示，“如果有人在我们被解雇后不久破坏了系统，那已经交出所有权限的我们至少不会成为被怀疑的对象、自然也不会成为无辜的替罪羊。”

“别瞎冒险”尤其是指要避免一些比较极端的人和情况，需果断下决定。有网友分享说，曾接触过那种技术很强、但完全让人无法与之共事的家伙——他不给代码写注释、也不参加例会，因为他觉得自己很聪明，认定这些事情都是浪费时间。他还放出豪言，“如果他们蠢到理解不了我写的东西，那也不是我的问题。”最后，管理层做了早就该做的决定。那天是周五，例会对这位自负的人进行了 5 分钟的简短批判，会上还出现了让该网友至今记忆犹新的金句，“你一直觉得没有你我们就做不成事，但从下周一开始，我们打算试试。”

再比如有网友分享了个报复的例子，公司 CEO 在某次会上当着大家的面，解雇了一位态度傲慢的工程师。这人真的不讨喜，所以看着他离开大家并没什么感觉。然而，在动用了如此激烈的裁撤手段之后，公司居然还让他在办公桌前过完这一整天。当天下班之后，办公楼门禁瘫痪、账户被锁定，所有主要服务器都被重启、内容全部擦除。大家几乎都知道是他干的，但因为定时脚本已在重启后被擦除，所以人们找不到证据。

摸鱼度过最后的在职时光

从裁员方的立场，别瞎冒险、当断则断是要义。而从离职者的角度，何尝不是如此。但若“被迫”必须得多待一段时间，心安理得地“摸鱼”未尝不是一个解决方案。

网友 Ken G 回忆道，在 1999 年 10 月下旬他接到部门发出的通告，第二年 1 月他就要离职了。其实他之前负责的项目根本不受千年虫问题的影响，项目文档已经更新完毕、交接工作也相当顺利，但项目经理还是希望他能“小心谨慎”。问题是，有什么可小心的？于是他只能嘴上回答“是是是”，另一边该休年假休年假。

休了 5 周年假之后，到了第二年的 1 月 4 号，Ken G 回到办公室。他日常就跟同事们聊天、泡茶，随便上上网。这样的日子他重复了一个月直到离职。

接着 Ken G 的回忆，也有留言给出了类似的经历，名为 DS999 的网友说：我被迫在企业里度过了 3 个月的“垃圾时间”，之前我以外包商的身份负责 SAP 项目中的 Unix 与存储工作，合同应该在当年 5 月就结束了。但因为那位全职员工一直在忙着无薪加班和夜间维护，公司决定把他升任成技术顾问，薪水一下涨了 3 倍。之前他已经帮工程部门的 Unix 团队培训过几位抽调过来的新人，但他们才刚刚接触项目、对很多问题还不熟悉。

“于是乎，我就成了唯一一位了解整套系统的人，公司意识到必须把外包合同再延长几个月。为了帮甲方度过难关，我接下了这份时薪 30 美元、为期三个月的延期职位。但接下来的情况属实出人意料：两位全职新人找上我，希望我别碰项目里的任何东西，只需要回答他们的问题。因为在他们看来，在我离开之后，所有工作就只能由他们接管了。所以他们宁愿问题出在当下、也别出在交接之后，免得让他们背锅。”所以，DS999 倒是成了真正意义上的顾问。整个夏天，他都在上网、发呆、鼓捣 Linux。刚开始他们每天还会提出几个问题，后来连着一个半月都没找过他。“这钱真的好赚，怀念。”

具体情况具体对待。也许，报复或不报复并不是关键。Steve Herseyren 认为 Thomas 故事里的深层寓意是这样的：“既然你都说了‘项目经理们不理解真实工作量、又把项目周期压得太紧’，那这家公司就是妥妥的垃圾场，任何自尊自爱的人都应该尽快离开、躲得越远越好。你的技能、时间和自我价值真的很宝贵，别再给雇主虐待你的机会了。赶紧跑，找个更靠谱的去处。当然，如果你特别需要这笔工资，那就明确规划一下还要忍耐多久、然后早点找机会离开。”

• 觉得本文对你有帮助？请分享给更多人关注「全栈开发者社区」加星标，提升全栈技能
  本公众号会不定期给大家发福利，包括送书、学习资源等，敬请期待吧！
  如果感觉推送内容不错，不妨右下角点个在看转发朋友圈或收藏，感谢支持。
  好文章，留言、点赞、在看和分享一条龙