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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　修復(fù)小 bug

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

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

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

　　開發(fā)經(jīng)理應(yīng)該在存在巴士因素(bus factor，團(tuán)隊(duì)成員被巴士撞傷會影響項(xiàng)目進(jìn)度，指某些事情只有某些人會做就會成為項(xiàng)目的風(fēng)險(xiǎn)點(diǎn))的項(xiàng)目上這么做，或者負(fù)責(zé)處理那些老 bug 或瑣碎的問題，因?yàn)檫@些問題只會消耗已經(jīng)負(fù)擔(dān)過重的團(tuán)隊(duì)成員的時(shí)間。

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

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

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

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

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

　　1. Google 腳本

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

　　我們的事故分析報(bào)告太過分散，而且從每個(gè)報(bào)告中復(fù)制數(shù)字?jǐn)?shù)據(jù)是件非常耗時(shí)且無聊的事情。

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

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

　　這樣不僅改進(jìn)了事故報(bào)告的分析工作，我還從工程師那里聽說，他們花在填寫事故報(bào)告上的時(shí)間更少了。

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

　　2. JIRA

　　在 Coursera，我們使用 JIRA 進(jìn)行 bug 跟蹤和 sprint 計(jì)劃。

　　Jerry Charumilind(學(xué)習(xí)體驗(yàn)平臺團(tuán)隊(duì)負(fù)責(zé)人)匯總了一份關(guān)于我們團(tuán)隊(duì)在解決 ticket 方面的有效性報(bào)告。

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

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

　　3. Slack

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

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

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

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

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

　　4. 檢查器

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

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

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

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

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

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

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

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

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

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

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

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