我花了很多時間為開發經理提供建議，很多剛走上開發經理崗位的新手總是問我：“我應該寫多少代碼?”

　　網上有很多文章建議開發經理要么完全不寫代碼，要么最多花 30% 時間在代碼上。

　　但問題是，太過關注開發經理需要寫多少代碼，反而忽略了開發經理為什么要寫代碼。

　　一名優秀的開發經理意味著你的優先考慮事項是管理以及與團隊成員互動。你需要培養管理技能，而我認為最重要的是同理心。同理心意味著你需要從工程師的角度看待問題。

　　很多優秀的開發經理曾經也是工程師。然而，工程技術領域在不斷發展，作為開發經理，需要與時俱進才能保持對團隊的同理心。

　　因此，不要問“我應該寫多少代碼”，而應該問“我在什么情況下可以寫代碼”。

　　在 Coursera，我們的開發經理就是這種方法的最佳實踐者。這樣做不僅讓我們可以“保鮮”我們的工程技能，同時又提升了對團隊工程師的同理心。

　　一、什么情況下不要寫代碼?

　　有時候，回答一個棘手問題的最好方法是回答反面的問題，比如“在什么情況下我不應該寫代碼?”。

　　如果人是開發經理的首要任務，那么通過代碼塑造一個偉大的工程團隊需要更多地關注測試、監控、代碼評審、設計文檔等。

　　完成這些任務所需的時間和空間只有全職工程師才有。如果開發經理去寫代碼，同時又期望其他人能夠完成其他繁重的工作(測試、調試、文檔、評審、監控、維護等等)，那么開發經理將失去激勵偉大工程團隊的能力。

　　開發經理不應該在團隊的關鍵路徑上寫代碼。雖然這看起來似乎有所限制，但也帶來了新的機會。

　　二、什么情況下要寫代碼?代碼評審

　　編程活動包含了 10%的編碼和 90%的設計、溝通、測試、閱讀代碼等。

　　因此，開發經理的另一種“編碼”方式就是完全不寫代碼。

　　代碼評審有助于建立團隊同理心，同時還可以加強編程技能，并建立對產品更好的理解。代碼評審要求評審人員能夠閱讀和理解代碼——可以說是偉大工程師最重要的技能之一。

　　修復小 bug

　　有時候，開發經理有機會卷起袖子修復一些小 bug。與代碼評審一樣，修復這些 bug 不需要寫大量的代碼。

　　但它需要閱讀與 bug 相關的代碼，并需要一個有效的開發環境。

　　開發經理應該要十分謹慎，避免引入新的 bug，并在修改完 bug 后進行測試，但要盡量避免修復團隊最近引入的 bug。

　　開發經理應該在存在巴士因素(bus factor，團隊成員被巴士撞傷會影響項目進度，指某些事情只有某些人會做就會成為項目的風險點)的項目上這么做，或者負責處理那些老 bug 或瑣碎的問題，因為這些問題只會消耗已經負擔過重的團隊成員的時間。

　　雖然團隊專注于構建優秀的產品，但仍有很多機會改進用于設計優秀產品的工具。通過自動化改進這些工具或開發新的內部工具為工程師和開發經理提供了發揮影響力的絕佳機會。

　　例如，Nick Dellamaggiore(Coursera 的基礎設施負責人)注意到，工程師使用了大量樣板代碼來監控事件管道中的事件。他希望減少這些樣板代碼，并避免為每個新監控器重新部署服務。后來，他做到了，甚至超出了期望。

　　我們現在都在使用他的方法對我們的產品進行性能監控和產品使用監控。

　　但是，如果這些工具變得非常流行且不可或缺，那么維護和開發新功能可能會成為開發經理未來的負擔。為了避免這種情況，開發經理需要將工具交給新主人。

　　開發經理可以嘗試構建更好的工具，幫助團隊更好地完成工作，而不是尋找管理任務以外的事情!作為開發經理，可以通過代碼來改進或自動化很多任務。

　　1. Google 腳本

　　幾個季度前，我過了一遍之前所有的事故分析報告，從中識別出事故發生的趨勢，并確定我們在跟進預防性問題方面究竟有多大的實力。

　　我們的事故分析報告太過分散，而且從每個報告中復制數字數據是件非常耗時且無聊的事情。

　　為了給我自己以及其他開發經理減負，我開發了一個 Google 腳本。現在，工程師只需填寫一個 Google 表格，回答一組標準問題，就可以自動生成事故分析報告，同時將有價值的指標填入中央電子表格。

　　https://gist.github.com/eleith/d91e2199e3ac622a0c7f8937a4794428

　　這樣不僅改進了事故報告的分析工作，我還從工程師那里聽說，他們花在填寫事故報告上的時間更少了。

　　最近，Priyank Chodesetti(學習體驗團隊的開發經理)也寫了一個 Google 腳本，用于自動化團隊 sprint 回顧過程。自從他發布了這個腳本以后，sprint 回顧的參與度得到了很大的提升。

　　2. JIRA

　　在 Coursera，我們使用 JIRA 進行 bug 跟蹤和 sprint 計劃。

　　Jerry Charumilind(學習體驗平臺團隊負責人)匯總了一份關于我們團隊在解決 ticket 方面的有效性報告。

　　雖然 JIRA 可以做很多事情，但很難通過內置插件來提取歷史數據。不過，借助 Python 和非常有用的 matplotlib，Jerry 直觀地向我們展示了我們的團隊在這方面做得有多好。

　　最近，Jerry 又寫了一個自動化腳本，可以向問題所有者發送有關問題時效性和優先級的通知。

　　3. Slack

　　slackbot 為開發經理提供了一個寫代碼的機會，同時還可以提高團隊的工作效率(或娛樂性)。

　　去年，我創建了三個 slackbot：

　　Buggy——用于創建、搜索和分配 JIRA 問題;

　　Foody——用于查詢我們的午餐和晚餐菜單;

　　Booky——用于搜索 gitbook 上的工程文檔。

　　4. 檢查器

　　偉大的工程實踐也可以從編程中受益。Mustafa Furniturewala(學習體驗團隊的開發經理)在他希望改善團隊測試文化時就遇到了這種情況。

　　在 Coursera 評審代碼時，我們會自動執行 linting，阻止不遵循編碼樣式指南的代碼提交。Mustafa 寫了一個腳本，強制要求所有新組件至少包含一個單元測試。

　　開發經理因此可以花更少的時間在手動檢查代碼提交上，并花更多的時間深入思考如何激勵團隊進行更好的單元測試和集成測試。

　　5. 公司內部黑客馬拉松

　　在 Coursera，make-a-thon(我們的黑客馬拉松版本)為開發經理提供了絕佳的寫代碼的機會。在過去的三個季度中，幾乎每個開發經理都參與其中。在上一個 make-a-thon 中，Richard Wong(Coursera 工程總監)因為他的項目能夠自動從視頻腳本生成音頻而斬獲了最佳表現獎。他的現場演示非常精彩!

　　一些開發經理喜歡參與寵物項目、副業或甚至是開源項目(例如，我在維護不是很流行的 emailjs)。這些項目為他們提供了編寫大量優秀代碼的機會。

　　外部工作為開發經理提供了有趣的編寫代碼的機會，與此同時，企業應該考慮采用更全面的方法來鼓勵開發經理抽出時間來編寫工作相關的代碼，特別是鼓勵健康的生活工作平衡。

　　三、什么時候可以認為開發經理寫的代碼夠多了?

　　我已經建議開發經理在哪些情況下可以寫代碼，當然，這并不是一個完整的清單。好的開發經理可以通過這些方法來為他們的團隊建立同理心。

　　開發經理在適應了這些寫代碼的場景后，現在就可以更好地回答之前的問題：何時以及需要寫多少代碼。

　　我不認為它有一個正確的答案。這要取決于每個經理自己，他們需要確定他們在激勵團隊構建優秀產品時是否具有足夠的同理心。

　　最近，我的一位工程師在調試她發現的 bug 時向我求助。我們花了大約 20 分鐘閱讀代碼，并嘗試各種輸入，最后找到導致 bug 的根本原因。當我的團隊很樂意找我尋求幫助時，這些互動告訴我，我寫的代碼已經夠多了。