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

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

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

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

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

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

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

　　一、什么情況下不要寫(xiě)代碼?

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

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

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

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

　　二、什么情況下要寫(xiě)代碼?代碼評(píng)審

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

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

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

　　修復(fù)小 bug

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

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

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

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

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

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

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

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

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

　　1. Google 腳本

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

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

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

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

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

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

　　2. JIRA

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

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

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

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

　　3. Slack

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

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

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

　　Foody——用于查詢(xún)我們的午餐和晚餐菜單;

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

　　4. 檢查器

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

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

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

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

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

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

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

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

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

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

　　我不認(rèn)為它有一個(gè)正確的答案。這要取決于每個(gè)經(jīng)理自己，他們需要確定他們?cè)诩?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ì)很樂(lè)意找我尋求幫助時(shí)，這些互動(dòng)告訴我，我寫(xiě)的代碼已經(jīng)夠多了。