“Manager還能不能寫Code？”如果你剛從技術開發職位升遷到管理職位，這會是一個在相當長一段時間內非常糾結你的問題。如果你之前技術做得還不錯、算是個“高手”，你應該會更加糾結一點，也許每天都在掙紮著：“今天我要寫Code嗎？” 在深入探討這個問題之前，先跟大家分享一下我的個人經曆吧~ 我在S公司工作已經滿5年了。剛加入這個公司的時候，我的職位是Sr. Software Engineer。公司考慮到我較強的技術背景，讓我自立門戶——我要招聘新人，建立和發展自己的團隊。一開始的一段時間裡，我單槍匹馬，那時當然是要寫Code的…後來招了兩個人，帶著他們一起做，但我仍然擔當主力。再後來做一個大一點的項目，又多招了兩個人。逐漸地，溝通和協調的工作多了起來，但我仍然堅持寫著Code…由於公司內部組織圖調整，原先項目的Ownership要轉給別人，原先的團隊成員也要合并到其他團隊，而我要去建立一個新的團隊，負責一個具有戰略重要性的底層模組的開發工作。招了兩個新人，後來再招兩個，很快發展出來一個新的四人團隊。那時，我仍然寫Code…公司再次重組，把基於那個底層模組的應用軟體Team Dev劃給了我，於是下屬人數達到了7人。從那以後，我開始慢慢地不寫Code了。但我並沒有遠離Code。我仍然在讀Code，在做Code Review…一年以後，公司再次重組，那個底層模組團隊划出去了，而我也接受了一項新的使命，著手建立一個將在公司未來發展戰略中承擔關鍵作用的Web Service團隊...我現在的職位變成了Sr. Engineering Manager。 我現在的狀態是：“基本上”不寫Code。為什麼說“基本上”呢？因為我有時還會參與應用軟體Team Dev的工作，幫他們一起Fix Bug。但這些工作是無關痛癢的，比如修改一下字串，更正一些簡單的邏輯，等等。我是做C++開發出身的，而他們用C# .NET做應用開發。這個客觀因素讓我失去了在項目中的技術領導地位，因此我不參與早期的開發工作單位，也輕易不會修改他們的代碼。我曾經非常糾結是不是要學一下C#，以便於對項目有更好的掌控。但我最終沒有那麼做。因為我有一個很好的團隊支撐我的工作。同時我也想驗證一下，如果我在項目中沒有技術高手的角色，我是否一樣能夠帶領好團隊把項目做成。事實證明，我可以！ 很多從技術開發崗位轉過來的Manager都陷在Code裡面不能自拔。為什麼會出現這樣的情況呢？寫Code何來如此大的誘惑呢？我覺得，都是慣性惹的禍！寫Code確實是有成就感的，而且這種成就感能夠以過去擅長的方式輕鬆獲得…其實，這是個陷阱！你要明白，當你做了Manager之後，你的職責發生了很大的變化。自己寫不寫Code並不是最重要的，重要的是要把項目做成。公司高層在把一個項目交給你的時候，他們關心的是你是否能夠帶領你的團隊按時交付產品，而並不關心誰在寫Code；他們更多地看的是結果…而為了保證項目成功，Manager有太多的事情要做了！如果你在早期給自己安排了大量的開發工作單位，結果又來不及做，阻礙其他團隊成員的進程乃至整個項目的進程，等到那時再匆匆忙忙地把任務轉交給別人，估計接你工作的人心裡感覺並不好。“你拉屎，別人給你擦屁股…” 曾經在LinkedIn.COM上看到一個高管這樣評價另一個高管：“…He's a brilliant and versatile executive that is not afraid to get his hands dirty with coding, if necessary. ”看到了吧！在老美眼裡，如果你作為一個管理員還在寫Code，那會弄髒了你的手… 綜合我個人的經驗，在保障項目利益的前提下，Manager可以寫Code，但應該盡量不要寫。作為Manager，應該多多考慮培養團隊成員，發揮團隊的力量去把項目做好。別讓自己像以前一樣扮演“英雄”的角色。既然已經選擇了管理這條路，那就要對自己的選擇時刻保持清醒的認識，好好地沿著這條路走下去。如果你曾經是技術高手或專家，現在要做的，恰恰是要把這個光環摘掉… “今天我要寫Code嗎？”其實，問題應該是“我有時間寫Code嗎？”“如果寫了Code，我能保證不成為項目的Blocker或者Risk嗎？”這裡沒有標準答案。因為每個人的個人情況和面對的項目情況都不一樣。不過，我仍然可以總結一下，給新手們一個參考：
1. 如果你的團隊成員只有4-5人、甚至更少，你可以寫Code。這樣可以讓你跟你的團隊成員更加親近。
a. 如果你寫Code，盡量不要呆在關鍵路徑上。多多考慮培養團隊成員，給他們足夠的成長空間。
2. 如果你的團隊成員超過了5人，你盡量不要寫Code了。因為你在開發階段的時間是無法保證的。
3. 如果你同時負責兩個或兩個以上的產品，而且產品之間的功能差別還很大，那你也不要寫Code了。
