技術領導要不要寫代碼？這是一個問題。

我剛工作的時候就聽說，程序員（那時候還沒有“碼農”的說法）是吃青春飯的，到30歲就熬不了夜寫不動代碼了，所以要盡早轉管理崗。相應的，如果你走上管理路線成了技術領導，自然就不必幹寫代碼這種低級重復的體力勞動了。所以當時自己代碼寫得很多，技術能力增長很快，但總感覺有點別扭。那感覺就像，你能把車開得又快又熟練，最終只是為了能按時到達機場趕上飛機。然後，你就再也不用開車了。

不過無論如何，趕上飛機看來是更高級的選擇，為了它，放棄苦心修煉的車技也可以接受罷。但是等我真正走上管理崗位，才發現事實和我想的完全不一樣。

當時公司的業務增長飛快，支持業務的系統卻是幾年前“一錘子買賣”的外包項目，更要命的是技術團隊的人員組成和工作習慣還處在作坊狀態。從我的角度來看，四下裏全是大坑，填坑的速度慢得讓人著急，在此過程中還經常挖下新坑…… 在我的職業生涯中，我從沒有在那麽短的時間裏寫過那麽多代碼。幾年後大家查提交排名，我的名字仍然第一。好在我的努力沒有白費，系統終於沒有垮掉，順利回到正軌。

當時我身為技術領導，除去招人、定流程、做運維，還花了大量時間寫代碼，這樣的做法是對的嗎？如果是對的，後來我再沒有寫過那麽多代碼，好像也與“不稱職的領導”無緣，甚至還被誇獎過“忍住放手讓下屬去做事，鍛煉了組織”，這又是怎麽回事呢？

很長時間裏我都在思考這個問題，發現大家的說法也大不相同。有人言之鑿鑿“不寫代碼的好領導不是好領導，因為只有自己寫的代碼才心裏有底”，也有人斬釘截鐵“當了領導還寫代碼是對不起公司，公司發給你領導的工資不是讓你敲代碼的”。

大家的觀點水火不容，所以或許這個事情並沒有統一的答案，只有回到具體問題才有答案。我能確定的是，在我當時所處的情況下，自己不寫代碼系統肯定會癱瘓。但是跳出來看，又不能說“領導要寫代碼”就是放之四海而皆準的。所以只能具體問題具體分析，下面說說我的“具體”看法。

首先要確信的是，寫代碼不是丟臉的事情

為了心平氣和地理性討論，我們應當摒棄那些天然帶有強力感情色彩的詞語，比如“碼農”，同樣也要註意摘掉其它的有色眼鏡。在我們所處的時代，再復雜的算法，再精妙的系統，也必須輸入一行行代碼來實現的。這就好比寫文章，文筆再好的人，也得自己一個一個字地把文章敲出來。

其實這個比喻還不是那麽合適，敲鍵盤是個“標準化”的過程，不存在“打字質量”的問題。寫代碼更像“創意”，比如多個程序，有同樣的輸入和同樣的輸出，但是這些程序到底能應付多少異常情況，有多麽穩定，效率差多少倍，離開代碼是很難發現的。正因為程序的質量很大程度上取決於代碼的實現，所以寫代碼是必須的工作環節，寫好的代碼更是非常值得追求的目標。

其次，技術領導不是什麽“高人一等”的角色

軟件的“軟”就在於它是看不見摸不著的，很多時候不能從現實生活中照搬模型，只能靠思維和經驗去把握。技術領導肩負著更大的職責，就應當有更深厚的經驗與更嚴密的思維，才能保證軟件開發的效果。單薄的專業經驗加上發號施令的權力，這樣的組合在其它行業或許能當領導，但在軟件開發行業充其量只能誕生不稱職的技術領導。埃裏克·施密特在《How Google Works》裏面寫道，Google需要的是既有領導才能又有自己實現能力的“創意精英”，我也覺得這種人是技術領導的最佳人選。

既然“寫代碼”不丟臉，“技術領導”也非高人一等，也就沒有必要把兩者對立起來。所以我們不妨放寬視界看看更要緊的問題。

技術領導這個角色，究竟應當幹什麽？

可以肯定的是，技術領導領導的是技術團隊，所以要對整個技術團隊的工作負責。下面我們用簡單的模型來分析技術團隊的工作。

A是很不錯的程序員，寫代碼速度是2，是普通程序員的2倍，代碼質量是1.5，是普通程序員的1.5倍。他對自己的狀態比較滿意，認為“搞開發就得是這樣”。確實，他的生產率是普通程序員的3倍（2×1.5），他也確實很棒。

A的表現獲得上級的肯定，於是升任技術領導，領導3個普通程序員開發程序。如果大家的工作都保持不變，那麽團隊生產率是 2×1.5 + 1×1×3 = 6。

但是A升任領導之後，必然要花很多時間去做寫代碼之外的事情，不再保持“個人貢獻者”的角色。我們假設他花了一半的時間去做其它事情，而代碼質量保持不變，那麽他的生產率降低為 (2×0.5)×1.5 = 1.5，A的生產率下降了很多。

A應當記住，現在自己不是“個人貢獻者”了，所以應當關心團隊的生產率。如果團隊的生產率不變，那麽整個團隊的是(2×0.5)×1.5 + 1×1×3 = 4.5。這幾乎是最壞的情況，技術領導被瑣事纏身無法做出貢獻，團隊的生產效率因此降低。

但是，如果A再減少自己寫代碼的時間到0.8，把省下來的時間用於制定開發規範、砍掉不合理需求、搞活團隊氣氛等等，情況就會不一樣了。假設A的一系列安排，讓其他3個程序員的寫代碼速度提高到1.3，代碼質量提高到1.3。

對很多技術出身的技術領導來說，這種狀態往往不讓人滿意，因為看不上其它程序員寫的代碼，總歸要自己寫才放心。但是，這時候團隊的生產效率卻變成了 0.8×1.5 + 1.3×1.3×3 = 6.27，反而高於最初的6.0。團隊生產率的提高正是公司對領導者的期望與考核標準。所以這個技術領導或許自己不滿意，卻是稱職的。

這個道理我之前在《領導的對象，是人還是任務》中講過。領導的對象既不是單純的人也不是單純的任務，而是以人為媒介，驅動團隊成員去完成更復雜的任務。

所以如果你是程序員出身的技術領導，一定要區分“自己”和“團隊”，你要考慮的不是怎麽讓自己寫得更快更好，而是怎麽讓大家都寫得更快更好。只要你能持續提升整個團隊的生產效率，你就是稱職的，哪怕“看不上”其他人的代碼，也得忍住。

在上面的例子裏，如果你能把剩下3個程序員寫代碼的速度都提升到1.5，代碼質量都提高到1.4，總生產率就有 1.5×1.4×3 = 6.3。這時候技術領導一行代碼也不寫，而且下屬寫代碼的水平仍然趕不上自己，團隊的生產率提高卻是板上釘釘的事實——當然你還有其他辦法，比如優化人員組合引入用生產率與自己相同甚至比自己更高的程序員，這樣的效率更高了。

當然，“一行代碼也不寫”多半是理想情況，許多時候技術領導還是必須要寫代碼的，因為軟件開發終究是手藝活，大家認同的也是手藝。所以很可能會出現下面的情況：團隊很缺某方面的開發經驗或能力，除了技術領導之外暫時沒人能對付；或者某個程序員不服氣或者不理解某個決定，不能用頭銜而只能用代碼來說服和闡釋……

除了這些“必須”的情況，我也主張技術領導“應當”寫寫代碼。軟件開發這個行業還太年輕，層級隔離做不到那麽好，只說不寫是找不到感覺的，而很多技術決策的依據正是這種感覺。所以我每次接手新的項目和團隊，通常都要把代碼全都看一遍心裏才有底，自己提交幾個功能才算找到了感覺。

這樣看來，“技術領導要不要寫代碼”這個問題沒有統一的答案。所以有時候你不得不忍住“讓我來寫”的沖動，有時候你又不得不忍住惡心親自動手。

就我個人而言，我覺得寫代碼而且不願意放棄寫代碼能力的技術領導更可愛。程序員大多是單純的，一起寫代碼，哪怕只寫幾個功能，也會告訴大家“我不是來發號施令的，而跟你們一夥的”。

技術領導要不要寫代碼？