如何讓你的程序員不要厭倦工作？

作為一個程序員，我從來沒有在同一家公司工作超過兩年。每換一份新工作都是一次很好的職業變動，在這個行業里跳槽如同家常便飯。但是我的前東家們 對我的離去并不開心，他們其中一些人花了很大力氣想要挽留我，但是我已經對一成不變的工作感到厭倦了，真的不想在同一家公司再待下去。

（ 免責聲明：我很幸運地生活在一個程序員工作崗位供大于求的地方，所以對我來說在換工作永遠不止一個選擇。 ）

如今我成為了 Enki 公司的合伙人與 CTO，同時我還要負責在公司里面打造工程師文化。我工作內容的一部分就是確保我們的程序員不要對工作感到厭倦，就像我過去那樣。

在團隊的幫助下，我們設計了一整套策略去幫助程序員們對抗工作中產生的厭煩情緒，并將這些策略運用到了公司的實踐當中。距今為止這套方法還是挺管用的，因此我想要和大家分享一下。

在 Enki 我們的程序員很幸運地一直從事著具有挑戰性的工作。我們有很多有趣的事情需要去編碼，還有大量有意思的問題亟待解決。因此如何解決「無聊」這件事情對我們 來說并不很緊急。但是所有的工作都不會一開始就讓你感覺厭煩，無聊這種情緒是隨著時間推移蔓延開來的，并且會在最糟糕的時刻爆發出來。

這就是為什么我們從公司成立之初就開始著手預防這類問題，并依靠建立起一種企業文化去幫助我們的程序員克服工作中產生的無聊情緒（真心祈禱這套東西管用吧）。

下面就讓我們總結一下為什么程序員會感覺工作無聊，以及如何避免發生這些狀況吧。

1、項目時間延續太長，學不到新東西

引發程序員無聊情緒最常見也最明顯的原因就是一個開發項目拖得時間太長。

我在自己的第一份工作中就充分體驗到了項目時間過長帶來的無聊感。我的團隊要做的是通過一個通用 API 去處理金融數據。一開始這項工作確實令人興奮，因為這些數據十分復雜且規模龐大，很有挑戰性。我從這項工作學習到了如何高效分析數據以及 API 接口設計。但是在一年之后，我們依然在針對相同的數據庫工作，使用的也是同樣的技術。我在這一針對性很強的領域已經成為一個專家了，在這項工作中再也沒有 什么新東西可以讓我學習。

我不可能再去別的團隊或者項目，因為公司感覺把我留在這個項目里才是最合適的。我明白在這個項目中現有的數據與技術已經用的太順手，所以不可能被 替換。我無法說服公司僅僅為了讓項目組成員學習新知而改變原本使用的技術。我向公司表達了自己的這種厭倦情緒與沮喪心情，但是無濟于事，那么我只好換一份 有奔頭的新工作了。

如何阻止無聊情緒的產生？

在我們的團隊里會試著避免讓任何一個程序員接觸相同的代碼、產品或者數據庫超過三個月的時間。將時間設定為三個月也許比較武斷，對于大公司來說這段時間可能也太短了。但是我們相信讓程序員在不同項目中快速輪轉是正確的。

為了實現這一設計，我們在公司里提倡一種全棧文化，團隊里的每一個程序員都能夠承擔任一部分的編碼工作（或者是能夠快速學會操作）。

預防無聊情緒滋生的另一個方法就是開誠布公地討論這個話題。我們每周都會進行一次直接、開放的一對一談話。如果一個程序員在工作中已經感到太過舒服沒有挑戰，或者是已經在這一方面過于專精，那么就是時候讓他輪轉到另一個項目當中去了。

2、維護代碼這種遺留問題讓人感覺太無聊

你能夠很清楚地分辨出何時項目就開始進入了維護模式，不論是從正式的渠道還是別的途徑，只要當你的程序員花上了 90% 的時間去修補 BUG 而不是開發新功能，那就代表著他們已經進入了代碼維護期。有人會說維護代碼是一項不可避免的工作，老舊的代碼需要不斷得到支持。開發軟件就像造房子，你總 是需要維護和翻新房子的，不是嗎？

既是，也不是。這項工作確實需要有人去做，但是問題通常會出在工作態度上。

我曾經的一位職場前輩對于維護代碼具有強烈的抵觸情緒，他理所當然地認為維護代碼這種事情根本沒有什么好做的，軟件開發完畢之后就讓它們自己去運行好了。生活簡直糟透了，你還不得不適應它。

如何緩解這種抵觸情緒呢？

項目開發工作進入無聊的維護模式有時候是由于糟糕的技術決策與缺乏勇氣的雙重作用。

一個擁有著復雜的依賴關系的龐大整體代碼庫需要額外的付出時間去做維護工作，于此相反的是，一個架構良好的微服務基礎設施擁有更強的靈活性。當一 個微服務架構出現缺陷時，你可以立即采取措施去修復。你可以重新寫一遍代碼，使用不同的編程語言或技術。通過這種方式，你會學習到新的東西而不是僅僅在遺 留下來的代碼上修修補補。如果你的架構不允許你重新來過，你還可以采取別的措施來改善，并且在這個過程中學到一些 DevOps 的技巧（譯者注：DevOps 就是開發（Development）和運維（Operations）這兩個領域的合并，可將原本笨重的開發與運維之間的工作移交過程變得流暢無礙）。

想要解決程序員在維護代碼中產生的無聊情緒有很多種方法可供選擇，公司采用微服務戰略只是其中一種可行方式。還有別的公司會通過打造智能工具去讓 代碼維護工作變得更有效率也更有意思。一個比較極端的例子就是 非死book 對他們的海量 PHP 代碼庫所做的工作。非死book 開發了他們自己的編譯器以及帶有 非死book 風格的語言（Hack），這使得他們的 PHP 代碼庫不僅便于維護，也改善了程序員的工作體驗。我猜想這種方式并不能完全解決代碼維護的遺留問題，但是它確實讓這個工作聽上去更有趣了。

3、工作只剩下復制 / 粘貼這種小兒科的東西

程序員所做的工作就是不停寫代碼。

我在之前的工作崗位上曾經產出了大量沒有什么意義的代碼。比如說我曾經為數據集成而編寫了 Groovy 與 Python 腳本。這些數據相當復雜，包含了許多不一致的數據庫對象集合，因此也不能夠自動化運行。鑒于此我不得不編寫大量代碼，我的同事都猜想我肯定從中學習收獲了 很多。

然而并沒有，為什么會這樣呢？

因為 50% 的代碼（這是夸張的描寫手法！）是我直接從 Stack Overflow 復制粘貼過來的。還有 40% 的代碼是從其他腳本中復制過來的，有一些來自我同事的代碼，還有一些是我之前寫過的。工作變成了一種重復勞動，其中沒有一點創造性與學習長進可言。

我們如何避免這種情況？

作為一個團隊，我們都會花時間去了解團隊其他成員寫了哪些類型的代碼。我們在代碼審查、同步以及工作回顧的時候去完成這件事情。如果一個人花了一星期時間卻只寫出了毫無創造性的代碼，我們就會試圖去弄明白在他身上到底發生了什么。

有時候問題的根源來源于你所用的技術。我們可能使用了過多的腳本，或者是做了許多本不應該做的配置工作。如果是這種情況，我們就會添加更多的自動化設置。有些時候我們進行代碼的復制粘貼是事出有因的，在這種情況下大家就會一起分擔這項不得不完成的無聊工作。

4、只能使用內部工具也太沒勁了

作為一個程序員，我們喜歡打造一個自定義的內部工具來解決某些特定問題，因為動手創造是一件令人興奮的事情。而且，構建一個定制化的解決方案通常要比找出一個現有的方案進行再利用要好得多。

然而相比于學習一門時下流行的開源技術，學習一個內部專有工具的趣味性只有前者的十分之一。 這到底是為什么呢？

因為它不能成為你和朋友聊天時的談資，你也不能到處吹噓，你不會在 Hacker News 上讀到關于它的新聞，你也不可以在編程馬拉松（hackathons）活動中使用它，當然了你也不能將其用到自己秘密開發的副業項目中。

很多公司都跌入了打造內部工具的陷阱當中，因為它隨之而來的就是給程序員帶來更多的無聊情緒。換句話說：你為了解決一個短期問題所開發的內部工具反而帶來了更多后患無窮的長期問題。

在我的上一份工作中就對于這個問題有著切身體會。我被限制只能使用公司自己開發的針對大規模數據集成的 DSL 語言，而我此前一直學習的完全是另一種 SQL 語言。我更希望能夠用上哪怕是 Spark 這樣開放程度沒那么高的語言。如果不使用內部工具，我將會 10 倍投入工作，寫出的代碼也會 2 倍優于現有的水平，還會讓我的生產力提高 5 倍（不要糾結于其中的倍數是否有數學邏輯，你只要體會我的心情就行了！）。

什么樣的企業文化能夠避免這一困境？

在我們公司中不會對開源技術抱有偏見。如果能夠重新利用相關開源技術，我們當然很樂意去做。我們不會回避前沿技術，一旦開源技術變得足夠成熟能夠 取代我們現行的專用語言，我們就會立馬拋棄原有的定制化代碼投向開源技術的懷抱中。在我們自己開發的定制化代碼變得足夠通用之時，我們就會將其開源。

這么做也偶爾會犯錯。比如說我們曾經使用過一段時間 agenda.js 去安排我們的后端工作，因為感覺這種技術既尖端又令人興奮。但是不久之后它就變得太過復雜了，我們只好重新用回了之前老舊但是可靠性更高的技術。即便如 此，我們依然不后悔曾經嘗試過，因為這也是一種寶貴的學習經驗。

5、如果不知道自己為何寫代碼，必然厭倦工作

糟糕的人力管理也是造成程序員對工作心生厭倦的常見原因。更具體地說就是：針對程序員的自上而下的獨裁式管理會讓他們產生抵觸情緒。

心懷良好意圖的管理者經常在不知不覺中就使用了這種獨裁式工作方法。尤其在一個開發項目進行的不是那么順利或者是截止日期臨近之時，這種管理方法 就更為常見了。在巨大的項目壓力下，管理者很自然地就會縮短團隊討論時間，減少頭腦風暴，直接命令程序員去寫代碼，卻不解釋為何這么做，也不接受任何爭 辯。而管理者通常這么做的出發點就是想要節省時間，盡快完成工作。

如果這種管理方法能夠被理解，也不是每一次都會招致厭煩；事實上，有一些人還挺能接受你簡單直接地告訴他應該做什么。當然了，這也是建立在你的說話語氣是能被對方接受的基礎上。

使用這種獨裁式管理方法也有隱藏的成本。通常程序員在明確知道寫什么代碼之前，需要有一個將智力與創造性進行轉換的固有思考過程。換句話說，如果你不讓他想明白其中的關鍵，只是一味地命令他去編碼，他就會變成一只會寫代碼不會思考的猿猴。

更重要的是，你應該鼓勵程序員去追問「為什么」，這樣他們能夠更加投入到自己所做的工作中去。除非你們現在所做的是一個劍走偏鋒的極端玩意，或者 是一個臨時補丁，不然的話都應該和程序員交代清楚。如果一個程序員不再關心與項目有關的重要決定，也不再思考這些決定背后的邏輯，那么他應該是已經準備跳 槽了。

如何防范這一問題？

想要解決這一問題最需要的就是在企業文化中建立起公開討論問題的機制。要留出固定的討論時間，讓整個團隊都參與討論接下來該做些什么、如何計劃。想要保持這種開放討論的企業文化，每個人都要對獨裁式的管理方式保持警覺。

尤其是在團隊遭遇困難的時刻（或者是截止日期臨近的時候），團隊成員需要更大聲地表達出自己的意見，而管理者則更需要小心謹慎地聆聽大家的心聲。

6、日復一日的工作總會不可避免地走向無聊

還有一點不得不提的是：在一個封閉的工作環境里長時間工作絕對會扼殺人感知生活的樂趣。這一點不僅僅是針對科技行業工作者或者是程序員崗位，放諸 于其他行業也是一樣的。這一條幾乎適用于任何一個后臺操作崗位，每一天在相同的辦公室里，見著同樣一幫人，做著一成不變的工作，也沒有什么不同文化的碰 撞。即便是在一個快速增長的企業環境中，縱然所有的事情從客觀角度看都在「良好」運行著，人們也會感覺自己有資格去尋找一些樂趣，并且會從不那么好的事情 中感到沮喪。

如何與日常工作中滋生的無聊情緒做斗爭？

解決這一問題的關鍵就是盡力創造多樣化：招聘擁有不同背景以及來自不同國家的員工（比如我們的團隊現有的 6 個成員就分別來自英國、法國、俄羅斯和希臘）。如果你每天看到的同樣一幫人能夠給你帶來不同文化的沖擊，那么上班這件事肯定會更有趣一些。

同時，我們會積極地創造一些走出常規工作環境的機會。

例如我們會一起去參加一些行業聚會以及編程馬拉松活動。我們還會一起打造工作之外的副業，共同研究我們喜歡的開源工具。除此之外我們還會不時地幫 助其他團隊完成一些不那么技術性的工作（包括招聘、市場和分銷）。這么做并非因為我們都擅長這些工作，只是為了在日常工作中尋求改變。

我們還會組織一些團隊活動（比如一起看一場秘密電影），我們每周還有一個固定的不需要事先預設主題的團隊活動時間。在這個自主活動時間里，有時候 我們會一起專研技術，有時候會頭腦風暴出一個新點子，有時候僅僅是聚在一起玩 LOL，或者是約好一同去泡吧。這個自由活動的美好之處就在于當我們坐下來討論該該去玩啥的時候，不到最后一分鐘根本就不知道要去干什么。

給生活增添這一小小的未知數成為了我們對抗無聊的終極一招。就像其他對抗無聊的方法一樣，這也不會是非常完美的解決之道。我們要做的就是在原有基礎上不斷調整，找出一些新招數，并且將其不斷地運用到對抗無聊的戰斗中。

文章來源： Medium ，由 TECH2IPO / 創見 陳錚 編譯，首發于創見科技（http://tech2ipo.com/），轉載請注明出處