【我們為什麼挑選這篇文章】身為一個做過不少工作的人，我非常理解每一間公司的入門工作都必然是枯燥、繁複的。對於管理者來說，他很難理解為什麼這些基層勞工不能理解公司這些基本業務的重要性，反而覺得自己在做一份不重要的工作。
但我認為這也是一個非常重要的學問，這篇文章不只要給工程師，也應該要給所有的管理者。（責任編輯：林子鈞）
作為一個開發者，我幹同一份工作的時間不會超過兩年。
每一份新工作都是一次職業的飛躍，而且在我們這個行業中，高頻跳槽本來就很常見。但是我前任，前前任，前前前任，前前前…任雇主對於我的辭職並不開心。有些甚至試圖挽留我，但是我已經厭倦了，我真心無法繼續留下來了。
（免責聲明：我很幸運地生活在 工程師 供不應求的地方，不過後來我發現換工作並不總是一個很好的選擇！）。
我現在是 Enki 的聯合創始人和 CTO 。我負責工程文化。我的部分工作是要確保我們的開發人員永遠不會像我過去那樣覺得工作無聊枯燥。
在我的團隊的共同努力下，我們制定了防止程式師感到無聊枯燥的策略，並應用到公司裡。由於這一策略到目前為止一直運作良好，所以在這裡我想和大家一起分享。
在 Enki 公司，我們可以放肆地衝鋒具有挑戰性的問題。為很多有趣的事情寫代碼，解決大量有趣的謎題。因此，「無聊」並不是一個迫切的問題。甚至剛開始的時候，你完全找不到它的蹤跡。但是， 隨著時間的流逝，無聊會像藤蔓一樣漸漸爬滿大樹，然後在最糟糕的時刻擊垮你 。
這就是為什麼我們要建立一種拯救無聊的文化來儘早解決這個問題的原因。
時間太長；學不到東西
開發人員感到無聊枯燥最常見和最明顯的原因是，項目的持續時間過長。
我在我第一份工作中就親身經歷了這種體驗。我們團隊的任務是通過一個便捷 API 來準備和提供財務資料。一開始因為資料的複雜性和規模，令我非常興奮。同時我從中也學會了如何高性能地分析資料和 API 設計。但是 一年以後，我們依然工作于完全相同的資料集，用著完全相同的技術 。我只是成為了某個特定方面的「專才」，也沒有什麼可以學習的新內容。
我無法改變團隊或項目，因為對於公司而言，這種重複性的枯燥的任務是有意義的。並且由於我熟知資料和技術而無法換到其他崗位。我沒有理由只是為了學習新的東西而去更換現有的技術。在我表明了我的枯燥和沮喪之後，因為問題依然沒有解決，所以我選擇了跳槽。
如何預防無聊和枯燥感？
在我們的團隊中，我們嘗試著 不讓任何人從事相同的代碼、產品和資料集超過三個月 。三個月的時間是我們任意定的，或許對於規模較大的公司而言，顯得太短了點。但是我們主張快速轉換。
為了做到這一點，我們提出了一個全棧文化。我們每一個開發人員都能夠工作於（或者可以很快學會）代碼庫的任何部分。
另一個預防枯燥的方法是經常性地討論。我們每個星期都有直接、開放、一對一的討論。如果 開發人員開始覺得過於舒服或已經熟能生巧了，那麼就到了轉換工作的時候 。
維護遺留代碼很無聊
當專案處於維護模式，即開發人員 90% 的時間都花在了修復 bug ，而不是開發新功能的時候，你可以報告給我們——正式或非正式的方式都可。
有人會說，維護是不可避免的。舊代碼需要支援。建造軟體就像蓋房子。你需要維護的老房子，並時常翻新。是這樣的嗎？
是的，但又不是。 問題的關鍵是態度 。
我曾經有一個導師，他對此抱著一種玩世不恭的心態。他將無為當作理所當然。他總是說，軟體發展工作就是這樣的；假如生活強姦了你，那就躺著享受吧。
如何避免呢？
維護模式有時是糟糕的技術決策加之缺乏勇氣才導致的結果。
大型，整體式的，依賴關係複雜的代碼庫往往需要額外的維護工作。與此相反的是，架構良好的微服務基礎結構就顯得較為靈活。當 微服務出現故障的時候，你可以更換它。你可以使用不同的語言或技術從頭開始重寫 。這樣你就可以學到新的東西，而不是簡單地修補舊的代碼。如果你的架構還不允許這麼做，那麼你需要採取步驟來改進它，並在此過程中學習一些開發技能。
微服務策略只是解決「枯燥」維護問題的方法中的一個。還有一個措施是構建智慧工具，使維護變得更加高效和樂趣。這方面的一個極端例子就是，Facebook 對他們那個龐大的 PHP 代碼庫做的事情。他們在熟練掌握 PHP 的基礎上構建了自己的編譯器和自己的類型語言（Hack），既方便維護，又提高了開發體驗。雖然我懷疑 Facebook 依然沒有完全「解決」遺留問題，但聽上去它讓工作變得更有趣了。
複製 /粘貼很無聊
還有就是編碼，編碼，還是編碼。
在我以前的一些工作中，我寫了很多收效甚微的代碼。例如，我曾為了資料整合寫過 Groovy 和 Python 腳本。資料很複雜，有許多不一致的模式，這使得大多數地方無法做到自動化。因此，我不得不寫大量的代碼，而我的同事因此認為我學到了很多東西。
但其實我並沒有學到很多。為什麼？
因為 50％（沒有計算過，純粹是誇張手法！）的代碼是從 Stack Overflow 直接複製/粘貼來的。還有 40％ 則複製/粘貼自其他腳本。無論是我同事的腳本，還是我的，都是如此。 很多很多代碼都是重複性的。很少涉及創造和學習 。
那麼對此我們又是怎麼做的呢？
作為一個團隊，我們要關注其他人寫的代碼類型。我們會審查，同步和回顧代碼。如果發現有人一個星期都沒有生產創造性的代碼，那我們就會去查看原因。
有時，問題的根源在於技術。 我們可能比我們應該的做了更多的腳本和配置工作 。在這種情況下，我們會增加自動化。不過，很多時候，是因為我們基於某種原因做了太多的複製/粘貼工作。在這種情況下，我們會共同承擔這個枯燥的工作以便於儘快完成。
內部工具通常很沒意思
作為開發人員，我們希望 創建定制的內部工具來解決具體問題 ，因為創造新事物總是令人興奮不已。此外，打造定制的解決方案常常比重複利用現有的解決方案更清潔。但學習專有工具要比學習流行的開源技術無趣多了。
為什麼？
因為你不能跟你的朋友交流專有工具；它成不了你吹噓的資本；你不能在ㄩHacker News 上看到它的身影；你不能在程式設計馬拉松中使用它；它在你秘密的業餘項目中也毫無用武之地。
但是，很多企業陷入創造的陷阱——他們 所創造的東西反而會帶來更多的煩惱 。換句話說：他們解決了一個短期的挫折，從長期來看卻會導致更多的挫折。
我對此深有體會。在我曾經的一份工作中，對於大規模資料集成，我被約束必須使用公司製造的 DSL 。在我看來，它就是另一種類似於 SQL 的術語（誇張手法）。我更喜歡使用和學習低級的開放式技術，例如 Spark。如果沒有這種限制的話，我的效率能高 5 倍都不止（請不要糾結這個數字，領會精神！）。
什麼樣的文化可以預防這種情況呢？
我們應該 儘量偏向於開源技術。勇於面對最前沿的技術 。毫不留情地拋棄自訂代碼，只要有開源技術成熟到足以取代這些自訂代碼。而當我們自己編寫的代碼變得夠格通用的時候，開放源碼。
偶爾我們也會犯錯。例如，曾經有一段時間我們使用 agenda.js 庫來安排我們的後端工作，因為它看上去既現代化又鼓舞人心。但是最後，它反而讓事情變複雜了，所以我們只能回頭用一個舊的更可靠的技術（略顯古老的 cron！）。儘管如此，我們也沒有後悔用它試驗，因為這是一個寶貴的學習經驗。
做一隻工程師很無聊
令開發者無聊的另一個常見原因是 糟糕的人力管理 。更具體地講是從上而下，獨裁地管理開發人員。
自認為目標遠大的主管有時候會使用這種管理風格而不自知。特別是當一個項目不會進展良好，或截止期限將至的時候。在壓力的作用下，獨裁統治會成為一種自然反射——討論時「一言堂」，不接受集思廣益，沒有經過辯證和解釋就直接告訴大家去做什麼。目的就是為了節省時間，儘快完成工作。
不過很多被管理的員工也不一定會生氣：事實上，有些人還很享受直接被告知要做什麼。當然，告知的方式得合適。
不過，這裡還有一個隱藏成本。
你在開發人員寫代碼之前就準確告知了他們該如何編碼，將這個智力和創造性的過程變成了一個機械的過程：換句話說，就是將開發人員訓練成了程式猿。
除非是駭客在攻克邊界情況，或是，程式需要做一個臨時補丁，否則參與的開發人員總是希望能瞭解「為什麼」他們要採取這種做事方式而不是另一種。當一個開發人員不再關心重大決策以及決策背後的原因的時候，也是他準備換工作的時候。
如何避免這種情況？
鼓勵公開討論的文化 。一個用於討論，制定戰略和計畫的定期論壇是一個團隊所必須的。為了保持這樣的文化，每個團隊成員都應該保持警惕。
特別是當舉步維艱的時期（或最後期限正在逼近的時候），學生需要說出他們的心聲，而導師需要仔細聆聽。
做一天和尚撞一天鐘很無聊
最後但並非最不重要的一個原因： 一個封閉的環境中會成為樂趣的絕對殺手 。
這在開發領域或高科技產業並不罕見。也適用於幾乎任何辦公室工作。每天都在同一間辦公室，面對同樣的人，沐浴同樣的文化，做同樣的工作……即使是在一個高速發展的環境下，即使所有情況客觀都是「好」的，大家也會對這些好的地方習以為常，然後開始對那些不那麼好的部分悶悶不樂耿耿於懷。
那麼我們該怎麼戰勝它呢？
關鍵因素是多樣性： 雇用不同背景和不同來源的人 （例如目前我們團隊的 6 個人就來自於英國，法國，俄羅斯和希臘 4 個不同國家）。如果團隊中的每一個人都能會我們的文化帶來新鮮要素，那麼即使每天面對同樣的人也會變得有趣，也會變得不那麼難以忍受。
同時，我們努力創造走出去的機會。
比如，我們會去公共場合聚會，會一起去參加程式設計馬拉松。我們都有自己業餘項目，並致力於最喜歡的開源工具。我們甚至時不時地會幫助其他團隊承擔技術含量不那麼高的工作（如招聘，行銷，分銷…）。不是因為我們擅長這些，而是為了能有一個變化。
我們還組織團隊搞活動（例如 Secret Cinema），每週舉辦一次不預定日程的「enkithon」活動。有時候，我們會一起過把駭客的癮。有時候，我們會頭腦風暴一個新點子。有時候，我們會沉溺于玩英雄聯盟。甚至我們還一起去泡吧。不到最後一秒我們自己也不知道要去做什麼，直到我們共同決定。
我們對抗無聊和枯燥的方法或許還不成熟，還有點混亂。但就像食譜一樣，每一份食譜都不能自稱是絕對完美的。調整用量，更換配料，反復練習才能精益求精。
延伸閱讀
地表最強大數據系統學習法：想變成數據科學家、工程師就看這篇！
想學做無人車的工程師注意！Google 工程師教你從零開始學「無人駕駛技術」
招到超強工程師，要怎麼讓他們留下來？Stack Overflow 營運長：你有多需要他們，就要有多尊重
（本文經合作夥伴 碼農網 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈编程是枯燥的，除非……〉。）
你對製作這些科技趨勢內容有興趣嗎？ 想從 TO 讀者變成 TO 製作者嗎？ 對內容策展有無比興趣的你，快加入我們的編輯團隊吧！ TechOrange 社群編輯擴大徵才中 >> 詳細內容 意者請提供履歷自傳以及文字作品，寄至 jobs@fusionmedium.com 來信主旨請註明：【應徵】TechOrange 職缺名稱：您的大名