在工做中學習

原文；Learning at work

做者：Julia Evans

談點：學習是一件沒有盡頭的事，雖然在工做中不少時候被淹沒在沒玩沒了的需求裏面，加班是常態，或許不少人不知不覺放棄學習的心思。這篇文章中提到的一些方法我很贊同，不少點也是個人作事方式，這裏也但願全部人都能找到適合本身的學習方式。

在 Twitter 上我提了一個問題，「你是如何花時間用於自身學習」（這個推文)，這些回答有一些相同之處：

• 閱讀博客文章
• 去參加業界大會
• 讀書
• 在洗碗時看一些演講
• 在一些不那麼重要的項目裏運用你想要學習的技術

這些方法都挺管用的。爲了我的職業發展，在工做以外花時間學習新技能是很是廣泛的事，在這方面我也有很多經驗。

另外一方面，我知道有一些很厲害的程序員在工做以外徹底不寫代碼。因而我開始思考，若是你想變得更牛，但又不想工做以外花太多額外時間要怎麼辦？

這些是我以及在 Twitter 上的朋友提到的一些觀點，而且都是能在工做時候作的事情。

不要學習工做以外的編程語言/框架

這一點聽起來有些消極，但確實仍是頗有用的。對於學習編程語言，個人觀點是：

• 我很熟悉幾種編程語言（python，scala，ruby）
• 學習新的編程語言須要至關長的時間
• 我不想把空閒時間花在上面

最近我在作一些 Go 方面的工做，還挺有趣的，我也喜歡作這件事。可是又以爲在上面花費太多我的時間，因此顯得不是那麼有趣了。經過編寫代碼學習編程，閱讀別人的代碼掌握一些模式，而後本身審查代碼，然而這些都不是必須的，由於徹底能夠在工做中去作這些事情。

選擇一些能夠從中學習的項目

這些是我在過去三年學到的一些東西：

• Scala/Ruby/Go
• hadoop/mapreduce/scalding
• 如何使用 Java 併發庫，以及如何配置一個 Java 程序
• 關於各類 AWS 服務的工做原理
• 不少機器學習的東西
• 網絡/ CDN / TLS 如何工做
• docker/容器/rkt/kubernetes
• 服務發現 / DNS / jenkins

一個關於如何選擇項目的例子：若是在工做使用一個不能很好並行的程序，這時候問題就來了。我能夠選擇去問寫這個程序的人爲何不使用並行編程，可是若是我也很想學習一下並行編程的話，就能夠本身去完成這件事。因此後來我就 學到了如何在 Java 中使用線程池。

我只爲此工做了幾天，但卻所以學到了新東西。

如今我正在從事 Kubernetes 相關的工做，當時選擇它並非由於能夠在這裏面學到不少東西。可是我確實學到不少有關分佈式系統的東西，還在工做中使用 Go 語言，我以爲這很很棒。

當人們說像「嘿，咱們使用 X 技術，須要有相關經驗的人才能在這裏工做」時，這其實至關愚蠢。如今我在網絡/ puppet / kubernetes / docker / AWS 上花了不少時間，在這項工做以前沒有任何相關工做經驗。

觀察那些高級人員是如何作事的

我會觀察那些我敬佩的人在工做中的作事方式，而後嘗試模仿他們或者是向他們尋求建議。例如，當 Cory 加入時，我注意到，在引進新技術的時候，他會這樣作：

• 找到另外一個有相似問題須要解決的團隊
• 與他們合做，確保技術真正解決問題

如今我正在開展一個新項目，一直在考慮這些工做能夠幫到誰以及如何幫助，這樣作就會感受好不少。

閱讀每一個 pull request

在這個主題下引用兩個我很喜歡的觀點：

我在一個小團隊，因此會閱讀全部的 pull request，直到徹底瞭解問題和解決方案

和

我也是同樣！我跟蹤檢查，看看人們如何解決各類問題

事實上，我並無閱讀團隊中的每個 pull request。可是那確實頗有用，經過跟蹤別人在這方面作的工做來學習這個領域的東西。

但我並非能徹底作到。我曾經從事機器學習方面的工做，發現理論也頗有趣，就想跟蹤人們在這方面的狀況，但對我來講有太多要注意的東西。我只能儘可能注意那些比較接近個人東西，像是其中網絡團隊的一些工做。

閱讀源代碼

閱讀我用到的源代碼對我而言是一個大塊頭。瞭解它在內部在作什麼，主要是爲何能夠經過某種方式工做。

這是很重要的一點，也很是重要。不少庫、框架、工具並無很好的文檔，在沒有閱讀源代碼的狀況下根本沒法瞭解其工做原理。

跟進你沒法解決的 bug

有時我會遇到一些本身沒辦法解決的 bug。後來，可能別人會找到解決方法，在這時候，就值得花時間去搞清楚具體的解決方法是什麼，以及他們如何想出來的。

例如，最近有一個我沒有調試出來的網絡問題，恰好有人在上週搞清楚這個問題。如今想想，大概明白形成這個 bug 的緣由，可是我並不清楚他們用什麼工具來獲取調試所需的信息。當我從新開始工做時，必須確保我真的搞清楚這個問題，這樣下次就能夠作得更好。

Jessica Kerr 評論道

每當我在故障排除時，除了解決這個問題，還會更深刻或更普遍地延伸開去。

我也喜歡這個回覆：

有時候，想解決一個與工做有關的問題，但並無真的在實際工做中發生，只是看看我能不能在某方面有所突破。

運用好通勤時間

對我而言，其實並無通勤時間。但不少人提到他們會利用通勤時間來聽播客/閱讀報紙/閱讀有趣的文章。這彷佛是一個很不錯的方式，來作一些你感興趣的事情。

花時間在工做中學習

Twitter上有人說「我但願天天能夠花 1 小時來學習」。個人觀點是，個人工做就是要在工做日中抽出時間來學習東西。像如今我正在工做中使用 Kubernetes，這是一個很複雜的系統須要很長時間才能理解，我得花時間瞭解它是如何工做的。例如，在開始的時候，沒什麼目的地在作集羣測試，只是想了解容器的網絡如何工做的，同時也在項目上取得進展。

這可能對我來講挺容易的，由於個人工做跟別人隔得很遠，沒有人真的知道我具體在作什麼，他們只是關心在大方面作的是什麼。

實際上，若是要是提早多花點時間閱讀，可能效果會更好。就像我剛剛在閱讀 Kelsey Hightower 的「learn kubernetes the hard way」的文檔，讀完不需花太長時間，並且其中有一個關於如何設置一個集羣的很好的點，這樣就能夠很節省我不少時間。

關於這個點，有些人還要想得更遠。好比，個人朋友 Dan 就提到好幾回，說他喜歡在工做中閱讀技術書籍。最初以爲這是一件使人驚訝的事情，但它確實頗有用。事實上，有不少跟我工做相關的書籍，找不到理由爲何不能在工做中閱讀它們。