開發經理是否應該寫程式碼？
我花了很多時間為開發經理提供建議，很多剛走上開發經理崗位的新手總是問我：“我應該寫多少程式碼？”
網上有很多文章建議開發經理要麼完全不寫程式碼，要麼最多花30%時間在程式碼上。
但問題是，太過關注開發經理需要寫多少程式碼，反而忽略了開發經理為什麼要寫程式碼。
一名優秀的開發經理意味著你的優先考慮事項是管理以及與團隊成員互動。你需要培養管理技能，而我認為最重要的是同理心。同理心意味著你需要從工程師的角度看待問題。
很多優秀的開發經理曾經也是工程師。然而，工程技術領域在不斷髮展，作為開發經理，需要與時俱進才能保持對團隊的同理心。
因此，不要問“我應該寫多少程式碼”，而應該問“我在什麼情況下可以寫程式碼”。
在Coursera，我們的開發經理就是這種方法的最佳實踐者。這樣做不僅讓我們可以“保鮮”我們的工程技能，同時又提升了對團隊工程師的同理心。
什麼情況下不要寫程式碼
有時候，回答一個棘手問題的最好方法是回答反面的問題，比如“在什麼情況下我不應該寫程式碼？”。
如果人是開發經理的首要任務，那麼通過程式碼塑造一個偉大的工程團隊需要更多地關注測試、監控、程式碼評審、設計文件等。
完成這些任務所需的時間和空間只有全職工程師才有。如果開發經理去寫程式碼，同時又期望其他人能夠完成其他繁重的工作（測試、除錯、文件、評審、監控、維護等等），那麼開發經理將失去激勵偉大工程團隊的能力。
開發經理不應該在團隊的關鍵路徑上寫程式碼。雖然這看起來似乎有所限制，但也帶來了新的機會。
什麼情況下要寫程式碼
程式碼評審
程式設計活動包含了10％的編碼和90％的設計、溝通、測試、閱讀程式碼等。
因此，開發經理的另一種“編碼”方式就是完全不寫程式碼。
程式碼評審有助於建立團隊同理心，同時還可以加強程式設計技能，並建立對產品更好的理解。程式碼評審要求評審人員能夠閱讀和理解程式碼——可以說是偉大工程師最重要的技能之一。
修復小bug
有時候，開發經理有機會捲起袖子修復一些小bug。與程式碼評審一樣，修復這些bug不需要寫大量的程式碼。
但它需要閱讀與bug相關的程式碼，並需要一個有效的開發環境。
開發經理應該要十分謹慎，避免引入新的bug，並在修改完bug後進行測試，但要儘量避免修復團隊最近引入的bug。
開發經理應該在存在巴士因素（bus factor，團隊成員被巴士撞傷會影響專案進度，指某些事情只有某些人會做就會成為專案的風險點）的專案上這麼做，或者負責處理那些老bug或瑣碎的問題，因為這些問題只會消耗已經負擔過重的團隊成員的時間。
雖然團隊專注於構建優秀的產品，但仍有很多機會改進用於設計優秀產品的工具。通過自動化改進這些工具或開發新的內部工具為工程師和開發經理提供了發揮影響力的絕佳機會。
例如，Nick Dellamaggiore（Coursera的基礎設施負責人）注意到，工程師使用了大量樣板程式碼來監控事件管道中的事件。他希望減少這些樣板程式碼，並避免為每個新監控器重新部署服務。後來，他做到了，甚至超出了期望。
我們現在都在使用他的方法對我們的產品進行效能監控和產品使用監控。
但是，如果這些工具變得非常流行且不可或缺，那麼維護和開發新功能可能會成為開發經理未來的負擔。為了避免這種情況，開發經理需要將工具交給新主人。
開發經理可以嘗試構建更好的工具，幫助團隊更好地完成工作，而不是尋找管理任務以外的事情！作為開發經理，可以通過程式碼來改進或自動化很多工。
1. Google指令碼
幾個季度前，我過了一遍之前所有的事故分析報告，從中識別出事故發生的趨勢，並確定我們在跟進預防性問題方面究竟有多大的實力。
我們的事故分析報告太過分散，而且從每個報告中複製數字資料是件非常耗時且無聊的事情。
為了給我自己以及其他開發經理減負，我開發了一個Googleofollow,noindex" target="_blank">指令碼 。現在，工程師只需填寫一個Google表格，回答一組標準問題，就可以自動生成事故分析報告，同時將有價值的指標填入中央電子表格。
這樣不僅改進了事故報告的分析工作，我還從工程師那裡聽說，他們花在填寫事故報告上的時間更少了。
最近，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的根本原因。當我的團隊很樂意找我尋求幫助時，這些互動告訴我，我寫的程式碼已經夠多了。