Java教程

被通知一个月离职,我修改了项目中的所有注释……

本文主要是介绍被通知一个月离职,我修改了项目中的所有注释……,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

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

假如你已经对某个开发人员下发解雇通知,你还会让他深度参与重要项目甚至把项目做完再走吗?

放在今天,这个答案往往是显而易见的:不会。

但如果是几十年前,那就未必了。

来自程序员的“报复”

近日 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 故事里的深层寓意是这样的:“既然你都说了‘项目经理们不理解真实工作量、又把项目周期压得太紧’,那这家公司就是妥妥的垃圾场,任何自尊自爱的人都应该尽快离开、躲得越远越好。

你的技能、时间和自我价值真的很宝贵,别再给雇主虐待你的机会了。赶紧跑,找个更靠谱的去处。当然,如果你特别需要这笔工资,那就明确规划一下还要忍耐多久、然后早点找机会离开。”

这篇关于被通知一个月离职,我修改了项目中的所有注释……的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!