如何讓你的程式設計師不要厭倦工作？

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

　　（ 免責宣告：我很幸運地生活在一個程式設計師工作崗位供大於求的地方，所以對我來說在換工作永遠不止一個選擇。）

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

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

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

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

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

　　1、專案時間延續太長，學不到新東西

　　引發程式設計師無聊情緒最常見也最明顯的原因就是一個開發專案拖得時間太長。

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

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

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

　　在我們的團隊裡會試著避免讓任何一個程式設計師接觸相同的程式碼、產品或者資料庫超過三個月的時間。將時間設定為三個月也許比較武斷，對於大公司來說這段時間可能也太短了。但是我們相信讓程式設計師在不同專案中快速輪轉是正確的。

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

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

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

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

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

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

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

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

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

　　想要解決程式設計師在維護程式碼中產生的無聊情緒有很多種方法可供選擇，公司採用微服務戰略只是其中一種可行方式。還有別的公司會通過打造智慧工具去讓程式碼維護工作變得更有效率也更有意思。一個比較極端的例子就是 Facebook 對他們的海量 PHP 程式碼庫所做的工作。Facebook 開發了他們自己的編譯器以及帶有 Facebook 風格的語言（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翻譯