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

　　網(wǎng)上有很多文章建議開發(fā)經(jīng)理要么完全不寫代碼，要么最多花 30% 時間在代碼上。

　　但問題是，太過關(guān)注開發(fā)經(jīng)理需要寫多少代碼，反而忽略了開發(fā)經(jīng)理為什么要寫代碼。

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

　　很多優(yōu)秀的開發(fā)經(jīng)理曾經(jīng)也是工程師。然而，工程技術(shù)領(lǐng)域在不斷發(fā)展，作為開發(fā)經(jīng)理，需要與時俱進才能保持對團隊的同理心。

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

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

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

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

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

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

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

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

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

　　因此，開發(fā)經(jīng)理的另一種“編碼”方式就是完全不寫代碼。

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

　　修復小 bug

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

　　但它需要閱讀與 bug 相關(guān)的代碼，并需要一個有效的開發(fā)環(huán)境。

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

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

　　雖然團隊專注于構(gòu)建優(yōu)秀的產(chǎn)品，但仍有很多機會改進用于設計優(yōu)秀產(chǎn)品的工具。通過自動化改進這些工具或開發(fā)新的內(nèi)部工具為工程師和開發(fā)經(jīng)理提供了發(fā)揮影響力的絕佳機會。

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

　　我們現(xiàn)在都在使用他的方法對我們的產(chǎn)品進行性能監(jiān)控和產(chǎn)品使用監(jiān)控。

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

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

　　1. Google 腳本

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

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

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

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

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

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

　　2. JIRA

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

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

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

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

　　3. Slack

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

　　去年，我創(chuàng)建了三個 slackbot：

　　Buggy——用于創(chuàng)建、搜索和分配 JIRA 問題;

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

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

　　4. 檢查器

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

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

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

　　5. 公司內(nèi)部黑客馬拉松

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

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

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

　　三、什么時候可以認為開發(fā)經(jīng)理寫的代碼夠多了?

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

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

　　我不認為它有一個正確的答案。這要取決于每個經(jīng)理自己，他們需要確定他們在激勵團隊構(gòu)建優(yōu)秀產(chǎn)品時是否具有足夠的同理心。

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