程序員慘遭辭退竟只因提了些代碼修改意見？

關鍵時刻，第一時間送達！

【CSDN編者按】技術人在職場中，是該做「正確的事」，還是該做「正確的人」？如果想做一番實事，就應該大刀闊斧、掃除一切破舊技術。但如果想在職場中如魚得水、混得更好，隨波逐流或許才是最好的選擇。本文的作者Renato Athaydes將將試用了五個月，就慘遭辭退了——不是技術不好，而是技術太好從而引發了「眾怒」。原因如何，我們來一探究竟。

以下為譯文：

在工作了5個月後，我被老闆辭退了。一般來說在我們國家，我簽的合同包括6個月的試用期，在此期間內任何一方（員工或者老闆）都可以終止合同，基本上不用提前通知。

我很驚訝……不是因為我以為自己做得非常出色，很長一段時間裡我自己很不開心，我知道一些同事也不是很喜歡我……我覺得驚訝是因為幾周前我們進行了「業績考核」，當時我大多數同事都恭喜我，說我的工作做得很好，只有一個人不太滿意我的工作，在和別人一樣誇獎了我一番後，給我了一個暴長的列表，上面寫著他認為我需要改進的地方。

在討論這個列表之前，先讓我從頭給你講講我的故事。

我的這份工作的薪資和福利非常好，雖然沒有很響亮的頭銜，就是個簡單的後台開發，我曾要求他們改成軟體開發，以準確地表述我的能力，而不僅僅是片面的技術力。我的技術總監對我的技術測試非常滿意，而且非常幸運的是：他在面試我的時候，知道我做過Kotlin，就在討論過程中問我怎麼看Kotlin（我個人認為Kotlin是非常好的語言） ，他說他讀過一篇文章說Kotlin的性能非常具有競爭力……結果發現，我就是那篇文章的作者！

這個開頭看似好極了，所以我決定辭掉Curity（很有前途的授權與認證的服務商）舒服的工作，並加入了這家做支付系統的公司。

我希望自己學習新技術，並有機會接觸Cassandra、亞馬遜ECS和Kubernetes等高訪問量以及可伸縮的系統。我已經在產品開發公司工作了多年，一方面能夠了解整個代碼庫是一件好事，在Curity的時候，因為我們做的產品相對較新，所以有很多未開發的領域。但是，另一方面，你所接觸的技術非常有限，比如我，過來過去就是Java虛擬機的東西，包括Java及其語言、Kotlin、Groovy、Jetty等等。

新上任的第一周，我被分到了一個臨時的隊伍，負責修復非常緊急的安全問題。在我第一次接觸新同事的時候，就感覺到一絲異樣：儘管與我之前的工作相比，此次修改非常的簡單，但是其他開發看似對當時的情況倍感壓力，他們還說需要幾個月的時間才能解決問題。可是，我覺得幾天應該就夠了！

作為公司的新人，有可能我不清楚一些他們沒跟我說的具體細節，但是無論如何，情況非常緊急，經理要求我們在兩周內改好，但據我的理解，兩周不是硬性規定。

然而，開始著手工作後，我發現根本就沒有什麼複雜的東西是我沒有預見的，實際上問題非常小，我們幾乎只用了一周就做完了，儘管之後我們還花了很多時間討論可能的替代方案。因為我有這方面的經驗，所以我帶頭實裝了解決方案，並寫了大部分代碼（不幸的是，這個項目不是開源的，所以我不能確認，但是我可能寫了超過70%的代碼）。第二周我們大多時候都在做測試，並與其他相關團隊溝通我們的解決方案。

有人似乎很擔心將這些代碼部署到產品中去……很明顯，他們不相信測試系統能在上線之前找到所有的問題。對我來說，這其實是第二個警告，我以前都是儘可能建立一個可以可靠地重現生產環境的模擬環境，這樣在代碼通過單元測試、系統測試和一些最終的手工測試之後，我可以很自信產品不會出什麼嚴重或明顯的問題。即便有問題，也只能說明測試沒有覆蓋到所有的邊緣用例，並不關乎產品和模擬環境的差異。

無論如何，我們將此次修改部署到生產環境，就是很大的勝利，尤其是對我來說，我才在這個公司幹了一周，就可以在修改嚴重問題的工作中擔任重要的角色。

但是從這次最初的經歷中，我發現了這個公司的開發流程中的很多東西還差得比較遠，所以我決定指出我們需要改進的地方。

我注意到，每當我指出什麼東西不對時，技術組長就非常不高興，很明顯他個人以為我指出的這些錯誤是針對他的：沒有輸入驗證，很多半途而廢的修改，缺乏單元測試，生產環境與模擬環境之間顯著的差異，開發人員從自己的機器上發行代碼而不是從CI伺服器上……等等問題導致了代碼質量的低下，在我看來，這些都是不可忽略的。他們給我的答覆總是千篇一律：他們不得不考慮時間限制，或人手不夠……都是常見的，慣用的（即便無法令人滿意）借口。

但是，我不能只指責別人，而不提出更好的方法，所以我馬上開始修改最明顯的問題，那些當我剛開始接觸微服務時注意到的問題。這些問題需要很大範圍的修改，並需要寫很多單元測試。我將寫的代碼分成幾次提交，希望有人能幫我確認測試的用例是有效的。

就在此時，我和我們隊伍的關係開始惡化。我經常發現我提交的PR閑置好幾天也無人問津。我不厭其煩地找他們，求他們審核我的修改，但是很顯然我做了太多改動，即便我事先將PR分成了幾次提交，也沒人願意審核我的代碼。這種情況一直持續發生，也可能是導致我們之間出現問題的根本原因。

我注意到不僅是我……其他人的PR也會被擱置好幾天，甚至幾個月都是常見的：我甚至發現別的項目中有的PR甚至整整一年都沒人審核。

如果我有一個擱置的PR，那麼我會從PR分支上創建一個新的分支，然後繼續我的工作，直到我準備提交下一個PR，所以PR審核不夠快的話，會導致PR堆積成山。請注意我們說的是幾天，而不是幾個小時！

我跟組長講了這個問題，結果他說他們不能花整天的時間審核我的代碼！我感覺是因為自己工作太快而慘遭人指責。

隊伍中的另一個人開始指責我，說我的PR太亂。一些人抱怨我去幫助別的隊伍的工作，就好似他們可以做主我可以幹什麼不可以幹什麼，可是對我來說那都是很簡單的工作，而且我絕對沒有影響到我們的進度。所以，很顯然每個人都不滿我拿著白菜的錢，卻做著太多的工作。

不止一個人跟我說，工作慢一點，別著急。

為了給大家做個榜樣，我很快地審核了別人提交的PR，結果有人抱怨我說，他的PR還沒準備好我就給審核掉了……但是我覺得吧，如果你沒有準備好讓別人審核你的PR，那你為什麼要提交PR呢？！你壓根不應該提交PR呀！！

這個時候，我感覺自己所做的一切都受人指責（除了代碼，儘管我倒是很希望有人能指出我代碼上的不足），這種氛圍太濃烈，我有點難以承受……所以我開始越來越有戒心，這讓情況愈演愈遭！我想著乾脆重回我之前的工作（原來的同事很歡迎我回去），但是我有點擔心我的簡歷看起來似乎我是一個喜歡跳來跳去的人。而且，我天生不喜歡放棄，如果事情進展不順利，那我更要傾盡全力。

一兩個月後……直到現在我們都在做Cassandra資料庫的遷移，這項工作不僅涉及代碼，還需要數據的變更，包括數據結構。這類的工作如果是發生在Postgres等SQL資料庫上那很簡單，但是Cassandra不一樣，這基本上可以讓我們的數據分崩離析。

一個自稱Cassandra專家的傢伙寫了一些代碼進行數據轉移。但是很顯然他遇到了麻煩，每次他嘗試在較大的數據卷上運行數據轉移時都會報錯。他說數據配置源已經崩了，因為內存中的數據太多了（或者其他這方面的問題）……我調查後發現這個錯與內存一點關係都沒有，只是Java的classpath中出現了衝突，從而引發了代碼中的一個路徑拋出了NoSuchMethodError的錯誤。我試圖跟他解釋，但是貌似他根本聽不懂我在說什麼，很顯然他對Java運行時的知識非常有限。這讓我對他的技術信心大打折扣。後來與他爭論技術問題的時候都很困難，因為我知道不能相信他的判斷（之後這個人也曾幾度在技術上做出了錯誤的判斷），而當我跟他說「你說的不對」，「我不相信你」（當別人大放厥詞，比如他說「不能在Cassandra中迭代所有行」時，我只能這麼回答他）的時候，別人可能感覺我很不理性。

不管怎樣，之後我找到了我們所需的正確的代碼庫版本，那段代碼終於跑通了……但是他爭辯說在Cassandra中我的方法行不通。他建議我應該去讀一讀Cassandra的書，還問我知不知道自己在幹什麼，即便是我推動了整個進度，解決了問題，而不是他。可能我不是特別了解Cassandra，但是我有CouchDB、MongoDB、MySQL、Postgres等等資料庫的經驗……我無法想像一個資料庫居然不能提供在表內做所有數據分頁等基本的功能。

最後不照樣好使了嘛。測試顯示所有的數據都按照預想的正確地迭代了。但是有一個壞消息：在不了解情況的人看來，我是個愚昧的人，不懂Cassandra，有人給出專家建議，我還不聽（如果他真的是專家，就該由他來寫代碼，但是他忙著玩Terraform，試圖自動部署新的資料庫集群，我們都明確說了這根本沒必要。）還有更甚者，另一位同事指出我非常愚蠢，居然用BATCH語句往新的數據表中插入數據，而這個人從來也沒有寫過一行代碼幫助我們的工作！

問題在於：Cassandra書中確實不允許在載入的時候使用BATCH語句，因為會影響到節點的穩定性。所以他沒說錯……但是我沒有直接使用BATCH語句，而是通過類似Java的東西寫的，我讀過文檔，說與這個問題一點關係都沒有。無論怎樣，我在大家心目中的形象已經毀了，因為我在批處理中使用了BATCH語句這樣大的錯誤。

我不喜歡大家這樣看我，所以我決定用數據驗證這個問題。我測量了一下在使用BATCH語句和獨立的語句時節點產生的負載狀況。我完全無法理解為什麼應該發送成千上萬的獨立語句到DB上執行，而不是像任何正常的資料庫客戶端那樣利用BATCH將它們打包到一起。我的測試很全面，所有測試都表明，無論在JVM還是OS上，BATCH導致的負載都顯著低於獨立語句，其結果與書上完全相反。有可能BATCH在擁有大量節點的情況下會過於昂貴，但我們只有幾個節點而已！所以這個問題完全不會影響到我們。我還給團隊做了次演說來展示我的發現。

最後有人認同我的努力並同意使用BATCH嗎？沒有！相反，他們認為我太固執，從來不肯聽取意見。

沒錯，我確實很固執！但如果測試結果表明BATCH性能更差，那我肯定會第一個改變看法。這個偏見還導致另一個結果，他們認為我太強勢（有人對我人身攻擊），估計這是壓垮他們的最後一根稻草。

最後我們決定不用BATCH。但是，他們讓我負責資料庫轉移過程中的流量控制。在我看來這十分荒謬，而且透露了他們對技術的無知：我已經採用了限流的方式防止INSERT語句衝垮資料庫——「生產者」每次只發送一組請求（我們不再用BATCH了）然後等待所有請求結束後才發下一組。在這種情況下，在「批次」之間通過sleep進行流量控制似乎完全沒有必要——特別是當「消費者」是Cassandra時，這個資料庫的目的就是處理高吞吐量。而且我的測試結果顯示這種方式對最終用戶完全沒有任何影響（我通過在運行腳本的伺服器上運行模擬實際情況的負荷測試進行的）。

但無論如何，我的爭論似乎完全沒有意義。

最後，資料庫轉移成功了。雖然我們花費的時間比實際所需得要多，但是最後只出現了一些小問題，並沒有影響到產品。

技術總監說，我們應該買個蛋糕慶祝一下，一般來說這種情況都值得慶祝。幾天後，我離開了公司。

在公司的5個月里，每一個任務我都做得很出色，但是很多方面我做得還不夠，最重要的是不討人喜歡。

在我之前的工作中，我很確定很多人喜歡我（我離職的時候，好幾個人挽留我），即便是在現在這份工作中，我也有幾個很好的朋友。但是由於不清晰的流程引發的碰撞和技術爭論，再加上不同的工作理念，所以導致我目前的情況，我的隊友不喜歡我，他們要我走人。

這給了我一個很大的教訓，我希望這篇文章可以幫我自己和別人明白，冰凍三尺非一日之寒，小不忍則亂大謀。

那張列表上指出的我需要改進的地方包括：多聽別人並接受他們的意見，不要過於有戒心，不要太強勢……基本上就是說要更加討人喜歡。

我知道了我犯了很多錯誤，但是我相信犯錯的不只是我一個人……但是我還在試用期，所以，再見，謝謝所有的人。

以上即為作者Renato Athaydes慘被辭退的經歷。對於他的這一遭遇，Hacker News上有很多網友給出了自己的看法。

評論一：

同情樓主，下面是我在「專業」環境中工作時總結的一些教訓，希望能幫到你。

在把現有系統扔進垃圾堆之前必須先贏得尊敬，不管那些代碼是如何垃圾，或如何缺乏測試。一般來說最好先「老實完成工作」，做功能也好改bug也好，因為你現在處於食物鏈的最底層。贏得了「尊敬」之後，再做新的東西就容易了。

垃圾代碼進入生產環境的借口很可能是正確的借口，一家以SaaS產品為生的公司需要快速上線並快速迭代。產品經理、銷售和市場人員可不在乎你的單元測試。用戶也不在乎你的單元測試。不幸的是這是個進退兩難的局面，因為一旦出了問題就是你的責任。

要明白，你之前的團隊為了特定的原因做出了特定的選擇，無論選擇正確與否，在扔掉他們的垃圾之前必須先接受之。

或者你可以自己開個公司自己制定規則。

評論二：

我認同上面的觀點。從樓主的經歷中我看到了兩點：

顯然博主的技術力遠遠超過了他所在的團隊。他有經驗，知道最佳實踐，還能夠改進軟體過程。

第二點，卻是最關鍵的一點，他很不擅長在團隊合作，也不擅長溝通。在他說的五個月的時間內你沒法改變任何東西。那是公司的文化。如果你不是老闆，那就只能通過柔和的建議、潛移默化的影響、裙帶關係、討論等……不依靠強制手段（或恐嚇），改變行為是完全不可能的。只能慢慢來，而且並不是每個人都能講道理的。這個就說來話長了。

其實我是在說，我同意他離職是個更好的選擇。

評論三：

沒錯，這個人和這個公司三觀不合呀。

有個老笑話，面試之後應該問三件事：第一，她能幹活嗎？第二，你能和她一起幹活嗎？第三，她是個殺人狂嗎？

博主肯定能滿足上面的條件之一，但即使他們能容忍條件三，那麼不滿足條件二就足夠把你掃地出門了。

當你發現所處的環境很垃圾（以你的觀點）時你只有兩個選擇：選擇留下來，就必須努力適應環境並與其他人好好相處。

貌似博主選擇的處理方式跟他的想法完全不一樣。「做正確的事」固然沒錯，但如果你招人煩，那麼幹得多好都是錯的。

作為一個過來人，這種經歷我有過好幾次，最後終於在感覺自己換工作太頻繁的時候，想通了應該如何在「與人相處」和「做正確的事」之間做出選擇。

觀念的轉變很痛苦，而且我有過多次反覆，使得別人都以為我又要回到以前的待人方式了——那種感覺依然在我腦海里迴旋呢。但最終我做到了，而且現在我是那種能和人好好相處的高手之一了。

從我的薪水上就能看出我現在很受歡迎。

畢竟，就像老Janis說的，「如果不能和你愛的人在一起，就去愛和你在一起的人。」這樣你就能更快樂，壓力和血壓都會降低，社交也會更廣泛，連工資條都會獎勵你。

評論四：

我在Coursera上的一門社會心理學課程上學到，受歡迎的孩子和不受歡迎的孩子的重要區別是，不受歡迎的孩子加入圈子後會提議玩個新的遊戲，而受歡迎的孩子會和大家一起玩一會兒再提議新的遊戲。

顯然跟這個故事有點類似……為了「受歡迎」，你得先迎合他們正在做的事兒，再慢慢尋求改變。這並不是正確與否的問題，而是如何才能受歡迎的問題。

原文：https://sites.google.com/a/athaydes.com/renato-athaydes/posts/belikeableorgetfired

作者：Renato Athaydes

譯者：彎月，責編：言則

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！