亞馬遜程式設計師:我曾拼命逃離996

最近的事,大家應該都聽說了。網傳拼多多一名女員工,在跨年夜加班到凌晨一點半,下班回家路上猝死,年僅23歲。

拼多多內部帖子越來越多人都在爆料,而官方並沒有出來闢謠。截至目前,拼多多官方也尚未迴應。

本文作者是一名亞馬遜員工,一度過著 996 的生活,雖然懼怕大公司的權力,但他把自己的想法,以及調節方式大膽的講述了出來,很有借鑑意義。

我在亞馬遜從事開發,熬到第二年底我就感到精疲力盡了。我不得不尋求改變,找到健康、可持續的方式,維護工作與生活的平衡,並再次享受工作。我寫下本文的初衷是:

提高人們的意識,尤其是對新員工;

對亞馬遜或其他公司裡,有類似經歷的員工以幫助和建議。

Hello,World

有關亞馬遜的企業文化的軼事、觀點和反駁都有不少。我寫下本文並非為了跟風蹭熱點話題,而是為了分享我的經歷。我以為沒有人會想聽我的故事,但很明顯的是,人們正經歷著類似的經歷,卻沒有發言權。

我在亞馬遜任職軟體開發工程師,現在級別為 SDE II;SDE II 基本上是指至少有 2~3 年以上行業經驗的軟體開發人員。我剛來亞馬遜時,是從 SDE I 開始做起的。

對大多數開發人員來說,在五大科技巨頭工作並非什麼遙不可及的夢想。在透過一個計時的線上程式設計測試後,我飛到西雅圖參加面試。回來後不到一週,我就接到了錄用電話通知,並溝通了一般的薪酬和福利,以及特殊補貼,如搬家補貼、簽約獎金和股票期權什麼的。記住那些 “特殊” 的內容,因為接下來我將會提到這部分,很重要。

在最初的幾個月裡,按照公司標準接受了一些典型的座右銘和 “你的工作不僅僅是工作” (your work is more than just work)之類的培訓。我現在算是看透了,但在當時,聽了“世界上最以客戶為中心的公司” (the World’s Most Customer-Centric Company)這樣的口號,對於天真的新員工來說就跟打雞血似的。

首先是尋呼值班問題

我在團隊裡待了幾個月後,就被安排到隨叫隨到的輪換名單上。所謂的隨叫隨到,也就是待命,是下面這幾個意思:

每隔 X 周待命一週,其中 X 為團隊成員數。

在待命期間,你的其他專案在工作日最多佔用你一半時間。

工作日的其餘時間集中在 operational issues 上(隨時待命)。

在待命期間,每天 24 小時需保持尋呼值班。

下面是尋呼值班的含義:

如果你的團隊擁有的 “東西” 進入了警報狀態,就會呼叫你。這是故意含糊其辭的,因為它對不同的團隊來說,意味著不同的事情。

一旦被呼叫,你將有 15 分鐘的時間上網並回復該呼叫。

如果你不這樣做,就會呼叫你的經理。這可不是你希望發生的事兒。

對我的團隊來說,隨叫隨到並不算(現在也不算)太糟糕的事。最初我們平均每兩週被尋呼一次;現在我們每週大約有一次被呼叫。而其他團隊的情況就糟糕得多。

不過,它是一種 “社交阻尼器”。如果你必須能夠做到在接到呼叫通知立即實施 “緊急援助” ,你就不可能真正制定外出計劃了。

我之所以提到尋呼值班的問題,是因為它很 “特殊” ,因為唯一需要這種響應能力的其他職業是醫生,他們是真正的救命恩人。當你第一次尋呼值班時,你會感到恐懼,心想:“這可不是鬧著玩兒的!”

在招聘時,除了通常所說的 “全職工作,你願意晚上加班或者週末加班嗎?” 之類的籠統問題外,並不會提及 “隨叫隨到” 的事兒,任何形式都不會有。

然後就是借調的問題

有時候,為了完成一個大型專案,其他團隊可能需要進行程式碼更改。當然,其他團隊可能無法抽調所需的開發人員,於是你就被借調走了。在專案完成之前,你要在兩個團隊之間來回輾轉,為兩個經理服務。

在某些情況下,那個其他團隊認為他們可以抽出時間完成程式碼修改。如果他們不這樣做的話,他們在某種程度上就會落後,所以你就被借調借出去了。

任何讀過《人月神話》(The Mythical Man-Month)的人都會覺得這樣有問題。沒讀過這本著作的讀者,可以透過維基百科(Wikipedia)瞭解一下這本書的要點:“在一個時程已經落後的軟體專案中增加人手,只會讓它更加落後。” (Adding manpower to a late software project makes it later。)

亞馬遜程式設計師:我曾拼命逃離996

我在亞馬遜的至暗時刻就是借調出去的時候;事實上,我這輩子最糟糕的日子也正是借調出去的時候。

在亞馬遜工作的第二年接近尾聲時,我被拉進了 “X 專案” (此為化名)。這個專案具備了一個前途黯淡的專案所具備的所有特點:

不同團隊、不同國家不斷變化的需求。

高風險、高知名度(幾乎和亞馬遜老闆貝索斯一樣知名)。

我就不一一敘述了,但還是開門見山地告訴你吧:事情變得緊張起來。

隨著專案的進度落後,來自上邊的壓力越來越大,審查也越來越多。專案經理希望以最有效的方式向團隊成員傳遞緊迫感,以取得適度的成功。

週末也變成了漫長的工作日。當時我覺得專案的落後在很大程度上是我的責任,但到目前為止,我還不知道到底是不是因為我。不管是什麼原因,是為了需要證明自己的價值,還是出於對失敗的恐懼,結果都是一樣的:我馬不停蹄地工作。我清醒的每一個小時,都用來投入到寫程式碼和修復 Bug 中。

起初,我還是有一些自我意識的。我客觀地知道,工作越多,只會降低人的工作效率,但必須這樣做。

到最後,精疲力盡佔據了上風。我的程式碼變得越來越糟糕,Bug 的數量不斷增多。“死亡螺旋” 的第一環已經開始旋轉起來。

最終,巨大的壓力使我的性格發生了改變,明眼人也能看得出來,我變得很粗魯,而我平時是很外向,很善解人意的。我以前也很有幽默感,喜歡開玩笑。我的同事們開始注意到我的變化,儘管我試圖偽裝自己。當時我開始選擇工作而不是和朋友在一起,起初他們還能理解。“抱歉啊,我得工作了” 這句話在某種程度上是可以被人理解的。但到最後,他們也開始擔心起我了。再一次,為了不給他們帶來負擔,我又一次誤入了歧途,開始孤立自己——這是 “死亡螺旋” 的第二環。

禁閉狀態

我們還沒有走出死亡螺旋,但首先,讓我們簡短地說一下。

還記得我前面提到的亞馬遜的搬家補貼和簽約獎金嗎?有一點需要注意的是,如果你在兩年內離職或被解僱的話,你就必須償還這筆錢。

當時我大學剛畢業,我幾乎沒有什麼積蓄,遠遠不夠還我所欠的錢。因此,如果我離開亞馬遜的話,我不僅會失去一份工作,還會失去至少超過三個月的收入。

所以,現在我可不能 “一走了之” ,當我意識到這一點後,隨之而來的是令人麻痺的絕望。一旦我失敗了,被炒魷魚了,那麼我可能很長時間都找不到另一份工作了。千禧一代的未就業問題是一件大事。現在我的壓力來自於要堅持一切工作——這是 “死亡螺旋” 的第三環。

連環失敗

在這一點上,“自我調節”?No,不存在的。為了最大限度提高程式碼的輸出,我一直靠著垃圾食品和咖啡續命。本來我一直有一定程度的失眠,但現在情況越來越糟糕了。最後一根稻草是我用睡眠換去程式碼的時候。

這時,壓力在我的腦海中變成了一個巨大的黑洞。我找不到合適的比喻。就是身體有被壓垮的感覺。情感和思想上都沒法逃避。我只能一遍又一遍地想著這有多痛苦。我想讓這種痛苦隨風而去。而這就是我一聽到 “亞馬遜” 這三個字就會出現的狀態。

就在那段時光裡,我哭了很多次,有時在睡覺的時候,想到第二天還是這樣的生活。有時候我和老婆一起哭,有時候我在衛生間哭過幾次。但我沒有在辦公室哭過。隨著我的腦海中只剩下兩個想法( “痛苦” 和 “讓痛苦停下來” ),沒過多久,自殺的念頭就悄然襲來。

需要說明的是,這些想法我從未付諸於行動。我不想傷害自己,但這樣的念頭就是這樣的:不管你真正想要的是什麼,這種念頭卻一次又一次地出現,我最後用 “讓痛苦停下來” 取代了 “讓一切停下來” ——這是 “死亡螺旋” 的最後一環。

結束階段

終於,我尋求心理醫生的幫助。我記得當時做出這個決定是如此的簡單。就像你打電話給物業一樣:“嗨,我家水管子漏了,麻煩叫個水管工過來修修吧”,我應該也找個人幫我看看。

直到這時,唯一知道到底發生什麼事的人就是我老婆。在這段時間裡,我無法(但會試著)向她表達我的感激之情。我遵醫囑服用西酞普蘭(一種抗抑鬱藥,在臨床上常用語抑鬱性精神障礙)。最終,“死亡螺旋” 解開了。幾個月後,一切恢復正常我才停服了西酞普蘭。從此以後,我嚴格將 “自己的需求” 放在首位,每天工作八小時,準時下班。我開始和朋友們約會。

為了回報我的努力,經理給我多批了幾天假。我被提升到 SDE II,身體甚至還很健康,可以慶祝這一喜事。

要有骨氣

“那又怎樣?所以你把自己搞得精疲力盡,累壞了。你還能指望什麼呢?” 我寫下這篇文章是因為我需要把我的故事寫下來,作為一個警示故事。我在這裡,並不是為了給自己設定 “真正的” 程式設計師應做什麼事情的標準,這很愚蠢。而且我也不是來妖魔化亞馬遜的。

至於我對亞馬遜和傑弗裡·貝索斯有什麼話要說,我只有幾句話。

請重新審視你的獎金 / 搬家補貼償還政策。我不知道 “正確的” 解決方案是什麼,但如果這是你留住員工的手段,那你就完蛋了。

要儘可能坦率地、準確地說明職位的要求。只寫上 “需要與聰明、熱情的人一起工作” 這句話,就是懶政。

要鼓勵員工不僅要批判性地對待想法,還要批判性地對待期望。要讓他們相信,為了得到你的認可就必須放棄其他一切,這是一種虐待。

要認識到生產力和快樂員工不是零和遊戲。顧客也不是憤怒的上帝,不會要求我們犧牲自己的利益。

我寫的這篇警示故事並不是亞馬遜所特有的。這種情況可能會發生在幾乎任何人身上,尤其是在高強度工作場所中工作的人,特別是軟體開發人員。

有這麼一句話,我在論壇和 Reddit 上看過無數次,但直到我親身經歷後才相信:

駁回不合理的期望是你的職業義務。你的老闆可能一開始不喜歡你這樣,但他們會因此而尊重你。(It‘s your professional obligation to push back on unreasonable expectations。 Your bosses may not like it at first, but they will respect you for it。)

我的另一個建議:存一筆Fuck You money。

常見反應

我知道,透過匿名發表這篇文章並不能促進討論。我之所以以匿名的方式來發表這篇文章,就是為了能夠要把這個警示故事說給你聽。

但我這麼做確實有苦衷,要不是我真的害怕丟掉這個飯碗,我就不會透過匿名方式來發表這篇文章了。我們從現任員工那裡聽到的唯一其他聲音都是支援亞馬遜的:

一位亞馬遜員工對《Inside Amazon:在激烈職場與偉大理念的角力》的迴應(An Amazonian’s response to “Inside Amazon: Wrestling Big Ideas in a Bruising Workplace”)

我叫 Brittan,我是一名亞馬遜人。(My name is Brittan, and I‘m an Amazonian。)

對這兩篇帖子的幾個主要批評是:

他們都是在 LinkedIn 釋出的。我很討厭在 LinkedIn 上釋出的任何東西。所有的批評都沒有什麼說服力,所有的話都被淡化了。因為在 LinkedIn 發表的所有資訊,都有可能被未來的僱主看到,因此,每個人都害怕禍從口出。

這些帖子都不是一線員工寫的,分別是高階經理和人力資源代表寫的。

我們並沒有看到任何來自現任員工的負面批評,難道沒有人不覺得這個現象很有趣嗎?不管你在哪家公司工作,從來都不缺願意抱怨的人。那麼,為什麼亞馬遜的現任員工沒有寫過負面文章呢?

是恐懼。恐懼滋生了一種沉默的文化。

以下是我看過的一些對文章的常見反應,請容許我搶先一步:

“工作時間超過 40 小時是作為職業人的本分。” (及其類似意思)

我完全同意,但這些應該是偶爾事件。每週 70 多小時的工作時間不應該是固定模式。他們應該得到管理層的賞識和獎勵。

“你為啥不少乾點兒活呢?這好像不都是你自找的嘛?”

這個問題,在我的腦海裡一遍又一遍地重複著。加上前面提到的原因,我只是覺得有必要堅持下去。我覺得在被這樣一家 “大牌” 公司錄用後,如果我不全力以赴,就是在傷害所有幫助我走到今天這一步的人。我沒有意識到的是,事實恰恰相反:透過打破自己,我確實表明了自己在某種程度上還沒有準備好。謝天謝地,我確實挺了過來,並從中汲取了教訓。

“你渾身充滿了負能量,難怪你會這樣消沉。” 請看我寫的下一段。

旅途快樂

除了我的故事外,我還想列舉我在亞馬遜工作的樂趣。畢竟我還在亞馬遜工作,並沒有辭職的計劃。

工作時間寬鬆,可以在家工作

但是說真的,當沒有發生危機時,也就是 80% 多的時候吧,開發人員的一天很少在上午 9 點之前開始。你通常可以每週在家工作一次。如果你有充分的理由需要提前下班,那也沒問題(儘管下班後在家接著工作通常是出於職場禮貌行為)。

沒有著裝要求

在大多數職場,可能會提出著裝要求,但 T 恤只適合商務休閒場合,能穿的話真是爽得不要不要的!

薪水

必須得提提薪水。但我不會給出具體數字,因為這樣的話可能會被人肉出來,但你可以上 Glassdoor(一家求職網站)看看來滿足好奇心。當我很多朋友努力保持高收入的工作時,這是件好事。儘管我在本文中吐槽了亞馬遜很多問題,但我仍然處於經濟穩定的優越地位,現在也有了很好的工作保障。

與 “巨人” 合作,並在 “巨人” 的基礎上發展壯大

科技公司常見的招聘口號之一就是 “與聰明人一起工作”。雖然我通常對此嗤之以鼻,但對於開發人員的成長而言,不一定要成為房間裡最聰明的那個人,這一點很重要。

招聘

近乎即時的滿足感

每天都有成千上萬的人執行你寫的程式碼,感覺是不是棒棒噠?很少有人有這樣的機會給他們的朋友和家人看他們經常訪問的網站,並說,“看,這就是我做的!” 也許這個激動的感覺最終會消退,但它仍然是我的心頭愛。

結束語

我現在被借調到一個新專案。又是一個 “DEFCON ZEROMG” 的專案,但我現在有了界限,並且還知道,如果我每週不超過 70 個小時,亞馬遜也不會因此轟然倒下。工作和生活的平衡在很大程度上是主觀的,但我現在自導了這種平衡對我來說是什麼樣子的,並且在努力工作的同時,我也要努力做到這一點。我只能希望你不必如此。

作者:不詳,因想保住飯碗,作者沒有透露任何資訊,只知身份為亞馬遜程式設計師。

-END-

“養碼場”

現有

技術人80000+

覆蓋JAVA/PHP/IOS/測試等領域

80%級別在P6及以上,

含P9技術大咖30人

技術總監

CTO

500餘人