作為一個程式設計師，我從來沒有幹一份超過兩年的工作。
每份新工作都是一個好的職業轉變，並且在我們這個行業頻繁跳槽也很普遍。但之前的老闆們對我的離開非常不爽。有些老闆一個勁兒地試圖挽留我，但是我待得實在太悶了，所以呆不下去了。
（免責宣告：我很幸運待在了一個對程式設計師求大於供的地方！我意識到換工作並不總是一個選擇。）
現在我是 Enki 的聯合創始人兼 CTO 。同樣，我負責公司的工程師文化。我有一部分工作就是確保我們公司的程式設計師不會像我之前那樣感到無聊。
在我團隊的幫助下，我們想出了幹掉無聊的法子。因為到現在為止，這個辦法效果還不錯，因此我想在這兒和大家分享。
在我們公司，我們很幸運能忙於解決一個有挑戰性的問題。我們為很多有趣的事情編寫程式碼，有很多有趣的謎題需要解決。因此“無聊”並不是一個需要緊急關注的問題。但是“無聊”從不會一開始就出現。相反，無聊是隨著時間悄悄地混了進來，並在最不可能的時刻給了我們當頭一棒。
這就是為什麼我們要很早就營造一種文化來解決這個問題，把你從曾經的無聊中解救出來（手指交叉！（校注：西方祈求好運的一種方式，將食指和中指交叉））。
太久；別學
導致程式設計師感到無聊，最普遍和顯而易見的原因就是專案拖得太久。
我在第一份工作就直接地體驗了這種無聊。我的團隊負責通過便利的 API 準備和提供財務資料。由於專案的複雜度和資料規模，一開始讓人很興奮。我學習了關於高效能的資料分析和 API 的設計。但是一年之後，我們仍然在使用相同的技術維護相同的資料。我已經在某些特殊領域變成了專家。我已經沒啥新玩意兒要學了。
我沒法換組或者換專案，因為這對我們公司意義重大，公司必須讓我呆在原處。我知道這些資料和技術已經好到無法替代，我不能僅僅因為自己想學點兒新東西就改變現有技術。我表達了我的無聊和挫敗感，但是沒用，因此我不得不換個工作。
怎樣避免這種感覺？
在我們團隊，我們試著避免任何人面對相同的程式碼，產品或資料超過三個月。這個時間段有點兒武斷，並且對於一個大公司來說可能也太短了。但是我們漸漸開始贊成這種快速換崗。
為了讓這事兒變為可能，我們發揚了一種全棧文化。我們的任何一位程式設計師都可以對程式碼庫中的任何一部分程式碼進行開發（或者快速學習如何開發）。
另一種避免無聊的方法是不停地討論這些事情。我們每週進行直接開放的一對一討論。如果某個程式設計師開始覺得太安逸了或者太明白了，那他就到了換崗的時候了。
維護遺留程式碼很無聊
當程式設計師花費 90% 的時間改 bug 而不是開發新功能，你就可以判斷出某個專案是否正處於維護模式。
有人會說維護是不可避免的。舊程式碼需要維護。開發軟體就像蓋房子。你需要維護舊房子並且要時不時整修它們，對麼？
如何緩解這個問題？
維護模式通常是不良的技術決策連同缺乏勇氣的結果。
當某個一成不變的大型程式碼庫擁有複雜的依賴就需要額外的維護工作。相反，一個設計良好的微服務架構有更好的擴充套件性。當一個微服務出錯的時候，你可以替換它。你可以從頭用不同的語言或技術重寫這個微服務。這種方法，你會學到新的東西而不是給遺留程式碼打補丁。同時如果你的架構現在還不允許你這樣做的話，你可以逐步的改善它，並在這個過程中學習一些新的開發技巧。
微服務策略是解決“無聊”的維護工作這一問題的方法中的一種。有些地方會創造一些智慧工具來讓維護工作變的更加有效和有趣。一個極端的例子就是 Facebook 處理他們龐大的 PHP 程式碼庫。他們在 PHP 之上構建了自己的編譯器和自己的型別語言（ Hack ），讓維護更容易同時提升了開發人員的體驗。我懷疑這不能完全“解決”遺留問題，不過這肯定讓工作聽起來更有趣些。
複製／貼上很無聊
程式設計無它，唯手熟爾。
在我之前的一些任務中，我寫了很多很爛的程式碼。比如，我曾經編寫 Groovy 和 Python 指令碼來做資料整合。這些資料非常複雜，有很多不一致的結構，不允許太多的自動化。因此我不得不寫很多程式碼，我的同事們還猜我學了不少東西。
但是事實並非如此，為什麼？
因為我 50% 的程式碼（為了誇張起見）是直接從 Stack Overflow 上覆制／貼上的。而且另外 40% 是從別的指令碼中扒下來的。要麼是我同事的，要麼是我自己的。這就變成了重複。一點創意都沒有或者啥也沒學著。
我們是怎麼試著緩解這個問題的？
作為一個團隊，我們注意不同開發寫的不同型別的程式碼。我們在程式碼審查，同步和回顧的時候做這件事兒。如果某人花了一週時間寫了沒有創造力的程式碼，我們會試著瞭解這是為什麼？
有時，問題的根本就是技術。我們可能做了比應該做的更多的指令碼處理或配置工作。在這種情況下，我們新增了更多的自動化。另些時候，是出於複製／貼上的原因。在這種情況下，我們會平攤這種無聊的工作來搞定它。
內部工具常常讓人無聊
作為開發者，我們樂於開發一些定製工具來解決特定問題，因為創造新東西令人興奮。同樣，建立私人訂製的解決方案要比重複使用現成的方案更加酸爽。但是學習一個專屬的工具可比學習一個流行的開源技術要沒勁差不多十倍。
為啥？
因為你不能和你的朋友聊起它；你不能吹牛說你懂這玩兒；你不能在 Hacker News 上讀到它的訊息；你不能在黑客馬拉松上使用它；你不能在自己的祕密專案中使用它。
但是很多公司都會陷入自己親手創造的，做一些沒有價值的新玩應兒的陷阱。換句話說：他們解決了一個短期的挫折，卻不料這東西會在將來引起更大的麻煩。
我在之前的工作中直接體驗到了。我被迫使用公司自家做的 DSL 來完成大資料的整合。我學的所有的東西只不過是另一種類 SQL 語言（我刻意誇張了）。我可能更喜歡使用和學習一種像 Spark 那樣的底層開發技術。我可能會投入十倍精力更加投入其中，雖然我的程式碼會因此膨脹到現在的兩倍，但是我依然會有五倍的生產力。（我算的可能不太準，但你能領會我的精神！）
什麼樣的文化能避免這個問題？
我們試著側重於開源技術。如果我們能重用一些相關的和令人興奮的開源技術，我們就會使用它。我們並不排斥前沿技術。只要一個開源技術變得足夠成熟，我們就會拋棄自己寫的程式碼並取而代之。當我們自己的程式碼變得足夠通用，我們就把它開源。
我們偶爾也會犯錯。比如：我們曾經使用了一段時間 agenda.js 來安排後臺工作，因為這個庫時髦且令人興奮。但後來陷入了麻煩之中，所以我們轉去使用一箇舊的，更穩定的技術（好用而且陳舊的計劃工具！）。同樣，我們並不後悔經歷這些，因為那是一段寶貴的學習經驗。
變為程式猿很無聊
另一個普遍引發程式設計師感到無聊的原因是疏於對人的管理。更具體的說就是：從上到下，對開發人員進行蠻橫管理。
那些擁有高尚目的的管理者，經常會無意中使用這種管理方式。特別是當一個專案進行的不順利，或者截止時期迫近的時候。壓力之下，一個自然的反應就是試著減少討論，最少的頭腦風暴，並且不由分說地明確告訴大家應該做什麼。僅僅是為了節省時間把事情做完。
一個聰明的管理者沒有必要因為這件事兒心懷意亂；事實上，很多人（偶爾）會很喜歡被告訴具體應該做什麼的這種簡單。當然，假設這是一種感覺合適的方式。
然而有一種隱藏的代價。
在寫程式碼之前明確的知道要寫什麼，將一種智力上的創意過程轉變成一種機械過程；換句話說，那將把一個開發人員變成程式猿。
更重要的是，參與專案的開發人員想知道為什麼他們要用這種方式處理事情而不是另一種。當然，除非，那僅僅是想要解決一個緊急問題的無奈之舉或者一個臨時補丁。但是如果一個開發對這些重要的決定漠不關心，那背後的原因就是這個開發準備換一份工作了。
如何避免？
最主要的事情就是需要一種文化來鼓勵公開討論。需要一個正規的論壇，作為一個團隊來討論，出謀劃策並且計劃我們需要做的事兒。為了保留這樣的文化，團隊中的每個人必須很注意。
當時間越來越緊（或者截止日期正在迫近），學員要勇於表達自己的想法，同時導師要善於聆聽。
平淡的日子讓人無聊
最後但也很重要的一條：按部就班的封閉環境是趣味的殺手。
這並不只針對開發這個角色或科技行業。這適用於很多“幕後”工作。他們每天都面對著相同的辦公室，相同的一群人，相同的文化，相同的角色……甚至在一個快速發展的環境，甚至所有的事情在客觀上都“很好”，人們一面為這個美好時代的來臨感到沾沾自喜，同時也因為這平凡的生活而變得鬱鬱寡歡。
我們怎麼同這種問題作鬥爭
這裡的一個關鍵點就是差異性：僱那些有不同文化和來自不同地域的人（比如：我們團隊現在的六個人有英國人，法國人，俄羅斯人和希臘人）。如果他們中的每個人能帶來不同的文化，那麼每天看到這群人絕對更有意思。
同樣，我們會創造更多的機會來擺脫平淡的日子。
比如，我們一起去參加公開的聚會和黑客馬拉松。我們同樣有一些自己的專案並且會給我們最喜歡的開源工具貢獻程式碼。我們甚至會時不時地幫助團隊做一些非技術的工作（比如招人，市場，物流……）。不是因為我們擅長這個，只是為了做出改變。
我們也組織團隊離開辦公室（比如：祕密電影院）進行每週一次的不在日程之上的“ enkithon ”（這是作者自造的詞彙； Enki 為作者公司的名字， thon 取自黑客馬拉松 hackathon 這個詞的後半部分）。在這些活動中，我們有時一起 Hack 一些東西。有時會頭腦風暴一個新點子。有時候只是一起玩兒英雄聯盟。或者一起去酒館。事實上這美妙之處在於當我們決定一起行動的時候，不到最後一分鐘我們不知道將要做什麼。
這點小小的混亂是我們對抗無聊祕訣中的最後一部分。就像每個食譜一樣，永遠不可能完美。調整劑量，替換食材並反覆試驗。