來源：infoQ； 整理｜燕珊、核子可樂

當沖突爆發且到了必須讓程式設計師離開時……那讓他們「及時離開」吧。

假如你已經對某個開發人員下發解雇通知，你還會讓他深度參與重要計畫甚至把計畫做完再走嗎？放在今天，這個答案往往是顯而易見的：不會。但如果是幾十年前，那就未必了。

# 來自程式設計師的「報復」

近日 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 故事裏的深層寓意是這樣的：「既然你都說了‘計畫經理們不理解真實工作量、又把計畫周期壓得太緊’，那這家公司就是妥妥的垃圾場，任何自尊自愛的人都應該盡快離開、躲得越遠越好。你的技能、時間和自我價值真的很寶貴，別再給雇主虐待你的機會了。趕緊跑，找個更靠譜的去處。當然，如果你特別需要這筆薪資，那就明確規劃一下還要忍耐多久、然後早點找機會離開。」

參考連結：

https://www.theregister.com/2022/04/04/who_me/

https://forums.theregister.com/forum/all/2022/04/04/who_me/

熱門推薦