1. 每年花時間讀兩本關於軟件工程的書
我每次花時間緩慢而認真地閱讀別人推薦的軟件工程書籍時，自身都會得到提升。所謂認真閱讀，我的意思是要做筆記、與他人交談、寫寫畫畫、動手嘗試、回過頭來重新閱讀。
我希望我在成爲開發人員的頭幾年就閱讀與軟件相關的書籍。 但我是在從業第 5 年左右纔開始這樣做的。諸如《C＃深入》，《簡潔代碼》和《Javascript：The Good Parts》之類的書都幫助我提升了技術水平。我並不是在推薦具體的書名——不管怎麼說，其中有些都已經過時了。我的建議是尋找比你現有知識更深入的書籍，可以是關於特定技術或關於軟件工程實踐的著作。
看這些書時我不會一目十行。實際上，我看得很慢。我通常每次坐下來只讀一兩章。看的時候，我會做筆記或把重點劃出來；看完後，我會回顧並經常與他人討論。我也開始寫一些書評放在自己的個人博客。
主要是反思我學到的東西。過去幾年，我養成了這些習慣。這些習慣幫助我以技術經理的身份迅速成長：它們對工程師來說也非常有益。想找推薦書單嗎？這裏是我已經看過的和正在看的 書籍清單。
爲什麼書籍要好過博文、視頻或演講？其實我認爲書籍比其他加起來都要好。無論什麼樣的主題內容，與書籍相比，其他的格式都會流於表面。書籍裏的知識更深入，而且組織良好。像本文這樣的帖子，我只需要花費幾個小時來寫，但是我花費在 我寫的這本關於軟件工程師成長的書籍上 已經將近一年。我認爲讀書可以更緩慢但深入地消化知識。
不要太貪心：每六個月讀完一本書已經很棒了。挑選一本好書，多花一些時間好好閱讀。在讀了一兩本書之後，我還建議你閱讀《如何讀一本書：智能閱讀的經典指南》一書，強烈推薦。
2. 精研你工作中主打的編程語言，學到底層
我剛開始時主要用 PHP，兼寫一點初級 JavaScript。我在大學裏學過 C 和 C ++，都不喜歡。我的第一份全職工作用的是 C＃。我瞭解很多種語言，但是沒有一種語言學得非常好。
兩年後，我開始遇到一些麻煩，在調試 C＃代碼時不得不找高級開發人員幫忙。其中一個總是幫我調試程序的高級工程師，他似乎非常瞭解這種語言，他向我推薦了一本書《C＃深度學習》讓我去看。然後我看了。我一路學到線程、垃圾回收和泛型的工作方式，這些都是底層知識。我花了數不清的時間去了解協方差（covariance）、逆方差（contravariance）和其他艱深的主題。
精研我工作中主打的語言是我做出的最佳決定之一。 在我的第一份工作中，這種研究只是無意爲之的，並且還得靠那位高級工程師指點；但是，這些知識在工作中，以及面試其他工作時都成了一種優勢。在我職業生涯的後期，我有意深入研究新的語言和框架。我是作爲 C # 程序員加入 Skype 的，但是，我們需要改用 JavaScript 和 WinJS。因此，我又深入學習了 JS，並掌握了 WinJS，以至於我可以 在 Pluralsight 上開課。
你懂的語言越多，就越瞭解它們各自的長處和短處。 當我轉移到 iOS 時，我已經精通好幾種語言。Swift 出現時，我簡單關注並參與了語言討論，並 建議添加讀寫反射這項能力 到 swift 的未來規劃中。瞭解了該語言的特性後，就可以更容易地找出讓我的團隊 從 Objective-C 遷移到 Swift 的最佳策略。而且，你知道的語言越多，就越容易掌握新的語言——並且在需要時更輕鬆地深入學習。
3. 多與他人結對編程
我覺得最近結對編程已經過時了。當年我們開始時，長期結對的極限編程、測試驅動開發和 mob 編程都很受歡迎。與人結對之後，我獲得了職業生涯中一些最大的躍升。這些躍升比讀書更重要。
我曾與一位開發人員有過一次難忘的結對編程經歷。他對包括我在內的所有人都進行了嚴格的代碼審查。有一天我受夠了代碼審查工具上的評論，決定不再在上面答覆，而是坐在這些評論者旁邊，要求他們當面向我說明他們的評論。我最終學到了很多東西——同時還告訴他們，我認爲他們的評論不公平。他們注意到了這點，建議我每當有這種情況時就結對編程。然後我就去做了。這位開發人員對性能有所瞭解，我通過跟他結對編程，瞭解到了潛在的性能瓶頸的來龍去脈——然後我教給他們有關可維護性方面的知識作爲回報。
與另一位工程師進行測試驅動開發經歷，是我在結對編程中的另一個美好回憶。我們輪流編寫代碼和測試代碼。我們做了兩天，實現了系統中一個棘手的部分。那次經歷實在令我大開眼界。我們在驗證所有邊界值的過程中，甚至反過來完全改變了實現方法。我們還與該開發商建立了牢固的紐帶並持續了數月之久。
4. 編寫單元測試用例，並在持續集成中運行
高級工程師們經常談論單元測試的重要性。但是單元測試似乎太違反直覺了：爲什麼要花更多的時間編寫看起來很簡單的測試？這是我在某段時間裏對單元測試的看法。
爲了領略單元測試的價值，你需要擁有“啊哈！”時刻——當你編寫的單元測試爲你節省了一天的時間，那就是“啊哈！”時刻。在到達這一步之前，你需要腳踏實地，好好編寫這些測試，並使它們在持續集成中運行。而且，你可能需要持續做上幾個月，纔會得到一個“啊哈！”時刻。
我有兩個這樣的時刻。第一個發生在我爲一個小型在線賭場構建後端引擎（作爲輔助項目）時。該 API 正在管理真金白銀，我因爲害怕犯錯誤，所以用單元測試覆蓋了所有代碼。該項目交付比我預想要晚——部分原因歸咎於測試，它們耗費了很多時間。但是這樣做是正確的。我在合同結束時將項目移交給了客戶，兩年後，他們告訴我，這些測試多次挽救了團隊——如果不是因爲測試失敗，代碼漏洞將會擴散到生產環境中。
我的另一個“啊哈”時刻是在 Web 上構建 Skype。我們在 web.skype.com 上給 Google Hangouts 創造了一個新的競爭對手。我們團隊是一支強大的團隊，擁有完整的單元覆蓋範圍和嚴格的集成測試。進入項目三個月後，工程師決定重構整個項目的結構。這是非常冒險的重構，我們所有人都投票反對這樣做。
那位工程師指出，基於現有的測試覆蓋率，這次重構應該是小菜一碟，只要測試通過，重構就沒問題。我對此表示懷疑。但這正是測試用例的用處。經過爲期一週的重構，他推動了一次巨大的變革……一切都沒有中斷，當時沒有，之後也沒有。所有測試均通過。就在那刻，我意識到了一套強大的測試用例所能提供的安全保障，以及它能夠讓我們不害怕重構的事實。
5. 養成重構習慣並掌握重構工具
多年來，當我與團隊合作時，我傾向於在代碼庫中進行儘可能小的更改。對於我自己的個人項目，我進行了大量的重構——但是我從來不在我不完全掌控的代碼庫上做這種事情。
然後，我在 Skype 遇到了一位工程師，他會不斷進行小型或大型重構。他們都有道理，並且代碼總是變得更好。而且他們從不搞亂事情。他們是如何做到的呢？
當我與他們結對編程時，發現他們非常瞭解自己的 IDE，並添加了用於重構的插件。提取方法、改變量名、提取成常量………他們只需要花一秒鐘。
我意識到，我害怕重構，既錯過了實踐，又錯過了能幫助我重構的工具。 於是當我開始養成每週重構一次的習慣時，我在這兩個方面都提升了。這個習慣後來對我很有幫助——我多麼希望自己在很多年前就開始這麼做啊。
6. 學習良好的軟件工程經驗，這使我獲益良多
在我剛開始做軟件工程師的時候，我曾經被高級工程師唬到了。他們看出了我沒看出來的錯誤，他們知道我不知道的答案。我當時以爲他們比我更聰明，並且接受了這一切。
現在，我已經與許多著名的軟件工程師緊密合作過，並擔任了另外幾位的導師，我發現沒有那麼唬人。最好的軟件工程師會把學到的知識和實際經驗結合在一起——知識，你可以去學；經驗，你需要去實踐。
找機會在不同的技術棧、不同的領域和具有挑戰性的項目裏工作。 我花了七八年的時間才達到我認爲的“高級”水平。我看到有些人加入了像 Uber 這種高成長性的公司，三四年就達到了。這中間的區別是什麼？這些人從事具有挑戰性的項目，力求跟上週圍其他人的步伐，並經常在中途更換團隊，重新開始。他們自願參與新項目，並在團隊中率先嚐試新技術。雖然我最終還是成爲了這樣的人，但那是後來的事，不是在最初的幾年中。
7. 把所學教給他人
學習某些東西，最好的方法是把它們教給別人。我是很偶然發現這一點的。在 2010 年，我開始在.NET 和 Windows Phone 用戶組中 做演示。我的演講效果不佳，但是我僅在準備階段就學到了很多東西。
現在，當我想學好東西時，就會報名參加了一次公開討論。 加入 Uber 一年後，我提出做一個演講，介紹在 2017 年 Uber 如何大規模推出後端更改。當時，我還不完全瞭解我們是如何做到的——在那之前，我主要從事移動開發，並管理一個移動團隊。通過演講，我別無選擇，只能學習所有細節。我這樣做的壓力很大：大約有 100 個本地開發人員報名要來聽我的演講。
許多其他人也說這種方法很有效——Shawn“Swyx” Wang 是 #LearnInPublic approach 的傑出代表。他的成長故事遠比我的經歷令人印象深刻：改行後在四年裏做到 Netlify 和 AWS 的高級工程師職位，並 撰寫了一本 關於他學習經歷的書。教別人你只會得到好處。你不僅可以通過教學來學到東西，而且還可以幫助和啓發他人。
而且我認識的所有經驗豐富的模範開發人員，都是合格的老師和導師。越早開始回饋和教導，就會越自然而然地成爲這樣的開發人員。