編程是枯燥的，除非……

作為一個開發者，我干同一份工作的時間不會超過兩年。

每一份新工作都是一次職業的飛躍，而且在我們這個行業中，高頻跳槽本來就很常見。但是我前任，前前任，前前前任，前前前…任雇主對于我的辭職并不開心。有些甚至試圖挽留我，但是我已經厭倦了，我真心無法繼續留下來了。

（免責聲明：我很幸運地生活在程序員供不應求的地方，不過后來我發現換工作并不總是一個很好的選擇?。?。

我現在是Enki的聯合創始人和CTO。我負責工程文化。我的部分工作是要確保我們的開發人員永遠不會像我過去那樣覺得工作無聊枯燥。

在我的團隊的共同努力下，我們制定了防止程序員感到無聊枯燥的策略，并應用到公司里。由于這一策略到目前為止一直運作良好，所以在這里我想和大家一起分享。

在Enki公司，我們可以放肆地沖鋒具有挑戰性的問題。為很多有趣的事情寫代碼，解決大量有趣的謎題。因此，“無聊”并不是一個迫切的問題。甚至剛開始的時候，你完全找不到它的蹤跡。但是，隨著時間的流逝，無聊會像藤蔓一樣漸漸爬滿大樹，然后在最糟糕的時刻擊垮你。

這就是為什么我們要建立一種拯救無聊的文化來盡早解決這個問題的原因。

時間太長；學不到東西

開發人員感到無聊枯燥最常見和最明顯的原因是，項目的持續時間過長。

我在我第一份工作中就親身經歷了這種體驗。我們團隊的任務是通過一個便捷API來準備和提供財務數據。一開始因為數據的復雜性和規模，令我非常興奮。同時我從中也學會了如何高性能地分析數據和API設計。但是一年以后，我們依然工作于完全相同的數據集，用著完全相同的技術。我只是成為了某個特定方面的“專才”，也沒有什么可以學習的新內容。

我無法改變團隊或項目，因為對于公司而言，這種重復性的枯燥的任務是有意義的。并且由于我熟知數據和技術而無法換到其他崗位。我沒有理由只是為了學習新的東西而去更換現有的技術。在我表明了我的枯燥和沮喪之后，因為問題依然沒有解決，所以我選擇了跳槽。

在我們的團隊中，我們嘗試著不讓任何人從事相同的代碼、產品和數據集超過三個月。三個月的時間是我們任意定的，或許對于規模較大的公司而言，顯得太短了點。但是我們主張快速轉換。

為了做到這一點，我們提出了一個全棧文化。我們每一個開發人員都能夠工作于（或者可以很快學會）代碼庫的任何部分。

另一個預防枯燥的方法是經常性地討論。我們每個星期都有直接、開放、一對一的討論。如果開發人員開始覺得過于舒服或已經熟能生巧了，那么就到了轉換工作的時候。

維護遺留代碼很無聊

當項目處于維護模式，即開發人員90%的時間都花在了修復bug，而不是開發新功能的時候，你可以報告給我們——正式或非正式的方式都可。

有人會說，維護是不可避免的。舊代碼需要支持。建造軟件就像蓋房子。你需要維護的老房子，并時常翻新。是這樣的嗎？

是的，但又不是。問題的關鍵是態度。

我曾經有一個導師，他對此抱著一種玩世不恭的心態。他將無為當作理所當然。他總是說，軟件開發工作就是這樣的；假如生活強奸了你，那就躺著享受吧。

如何避免呢？

維護模式有時是糟糕的技術決策加之缺乏勇氣才導致的結果。

大型，整體式的，依賴關系復雜的代碼庫往往需要額外的維護工作。與此相反的是，架構良好的微服務基礎結構就顯得較為靈活。當微服務出現故障的時候，你可以更換它。你可以使用不同的語言或技術從頭開始重寫。這樣你就可以學到新的東西，而不是簡單地修補舊的代碼。如果你的架構還不允許這么做，那么你需要采取步驟來改進它，并在此過程中學習一些開發技能。

微服務策略只是解決“枯燥”維護問題的方法中的一個。還有一個措施是構建智能工具，使維護變得更加高效和樂趣。這方面的一個極端例子就是，Facebook對他們那個龐大的PHP代碼庫做的事情。他們在熟練掌握PHP的基礎上構建了自己的編譯器和自己的類型語言（Hack），既方便維護，又提高了開發體驗。雖然我懷疑Facebook依然沒有完全“解決”遺留問題，但聽上去它讓工作變得更有趣了。

復制/粘貼很無聊

還有就是編碼，編碼，還是編碼。

在我以前的一些工作中，我寫了很多收效甚微的代碼。例如，我曾為了數據整合寫過Groovy和Python腳本。數據很復雜，有許多不一致的模式，這使得大多數地方無法做到自動化。因此，我不得不寫大量的代碼，而我的同事因此認為我學到了很多東西。

但其實我并沒有學到很多。為什么？

因為50％（沒有計算過，純粹是夸張手法?。┑拇a是從Stack Overflow直接復制/粘貼來的。還有40％則復制/粘貼自其他腳本。無論是我同事的腳本，還是我的，都是如此。很多很多代碼都是重復性的。很少涉及創造和學習。

那么對此我們又是怎么做的呢？

作為一個團隊，我們要關注其他人寫的代碼類型。我們會審查，同步和回顧代碼。如果發現有人一個星期都沒有生產創造性的代碼，那我們就會去查看原因。

有時，問題的根源在于技術。我們可能比我們應該的做了更多的腳本和配置工作。在這種情況下，我們會增加自動化。不過，很多時候，是因為我們基于某種原因做了太多的復制/粘貼工作。在這種情況下，我們會共同承擔這個枯燥的工作以便于盡快完成。

內部工具通常很沒意思

作為開發人員，我們希望創建定制的內部工具來解決具體問題，因為創造新事物總是令人興奮不已。此外，打造定制的解決方案常常比重復利用現有的解決方案更清潔。但學習專有工具要比學習流行的開源技術無趣多了。

為什么？

因為你不能跟你的朋友交流專有工具；它成不了你吹噓的資本；你不能在Hacker News上看到它的身影；你不能在編程馬拉松中使用它；它在你秘密的業余項目中也毫無用武之地。

但是，很多企業陷入創造的陷阱——他們所創造的東西反而會帶來更多的煩惱。換句話說：他們解決了一個短期的挫折，從長期來看卻會導致更多的挫折。

我對此深有體會。在我曾經的一份工作中，對于大規模數據集成，我被約束必須使用公司制造的DSL。在我看來，它就是另一種類似于SQL的術語（夸張手法）。我更喜歡使用和學習低級的開放式技術，例如Spark。如果沒有這種限制的話，我的效率能高5倍都不止（請不要糾結這個數字，領會精神?。?。

什么樣的文化可以預防這種情況呢？

我們應該盡量偏向于開源技術。勇于面對最前沿的技術。毫不留情地拋棄自定義代碼，只要有開源技術成熟到足以取代這些自定義代碼。而當我們自己編寫的代碼變得夠格通用的時候，開放源碼。

偶爾我們也會犯錯。例如，曾經有一段時間我們使用agenda.js庫來安排我們的后端工作，因為它看上去既現代化又鼓舞人心。但是最后，它反而讓事情變復雜了，所以我們只能回頭用一個舊的更可靠的技術（略顯古老的cron?。?。盡管如此，我們也沒有后悔用它試驗，因為這是一個寶貴的學習經驗。

做一只程序猿很無聊

令開發者無聊的另一個常見原因是糟糕的人力管理。更具體地講是從上而下，獨裁地管理開發人員。

自認為目標遠大的主管有時候會使用這種管理風格而不自知。特別是當一個項目不會進展良好，或截止期限將至的時候。在壓力的作用下，獨裁統治會成為一種自然反射——討論時“一言堂”，不接受集思廣益，沒有經過辯證和解釋就直接告訴大家去做什么。目的就是為了節省時間，盡快完成工作。

不過很多被管理的員工也不一定會生氣：事實上，有些人還很享受直接被告知要做什么。當然，告知的方式得合適。

不過，這里還有一個隱藏成本。

你在開發人員寫代碼之前就準確告知了他們該如何編碼，將這個智力和創造性的過程變成了一個機械的過程：換句話說，就是將開發人員訓練成了程序猿。

除非是黑客在攻克邊界情況，或是，程序需要做一個臨時補丁，否則參與的開發人員總是希望能了解“為什么”他們要采取這種做事方式而不是另一種。當一個開發人員不再關心重大決策以及決策背后的原因的時候，也是他準備換工作的時候。

如何避免這種情況？

鼓勵公開討論的文化。一個用于討論，制定戰略和計劃的定期論壇是一個團隊所必須的。為了保持這樣的文化，每個團隊成員都應該保持警惕。

特別是當舉步維艱的時期（或最后期限正在逼近的時候），學生需要說出他們的心聲，而導師需要仔細聆聽。

做一天和尚撞一天鐘很無聊

最后但并非最不重要的一個原因：一個封閉的環境中會成為樂趣的絕對殺手。

這在開發領域或高科技產業并不罕見。也適用于幾乎任何辦公室工作。每天都在同一間辦公室，面對同樣的人，沐浴同樣的文化，做同樣的工作……即使是在一個高速發展的環境下，即使所有情況客觀都是“好”的，大家也會對這些好的地方習以為常，然后開始對那些不那么好的部分悶悶不樂耿耿于懷。

那么我們該怎么戰勝它呢？

關鍵因素是多樣性：雇用不同背景和不同來源的人（例如目前我們團隊的6個人就來自于英國，法國，俄羅斯和希臘4個不同國家）。如果團隊中的每一個人都能會我們的文化帶來新鮮要素，那么即使每天面對同樣的人也會變得有趣，也會變得不那么難以忍受。

同時，我們努力創造走出去的機會。

比如，我們會去公共場合聚會，會一起去參加編程馬拉松。我們都有自己業余項目，并致力于最喜歡的開源工具。我們甚至時不時地會幫助其他團隊承擔技術含量不那么高的工作（如招聘，營銷，分銷…）。不是因為我們擅長這些，而是為了能有一個變化。

我們還組織團隊搞活動（例如Secret Cinema），每周舉辦一次不預定日程的“enkithon”活動。有時候，我們會一起過把黑客的癮。有時候，我們會頭腦風暴一個新點子。有時候，我們會沉溺于玩英雄聯盟。甚至我們還一起去泡吧。不到最后一秒我們自己也不知道要去做什么，直到我們共同決定。

我們對抗無聊和枯燥的方法或許還不成熟，還有點混亂。但就像食譜一樣，每一份食譜都不能自稱是絕對完美的。調整用量，更換配料，反復練習才能精益求精。