程式設計是枯燥的,除非……

2017-07-23    分類:程式設計師人生、首頁精華1人評論發表於2017-07-23

本文由碼農網 – 小峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃

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

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

(免責宣告:我很幸運地生活在程式設計師供不應求的地方,不過後來我發現換工作並不總是一個很好的選擇!)。

我現在是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”活動。有時候,我們會一起過把黑客的癮。有時候,我們會頭腦風暴一個新點子。有時候,我們會沉溺於玩英雄聯盟。甚至我們還一起去泡吧。不到最後一秒我們自己也不知道要去做什麼,直到我們共同決定。

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

譯文連結:http://www.codeceo.com/article/coding-is-boring-unless.html
英文原文:Coding is boring, unless…
翻譯作者:碼農網 – 小峰
轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊。]

相關文章