“Manager还能不能写Code？”如果你刚从技术开发职位升迁到管理职位，这会是一个在相当长一段时间内非常纠结你的问题。如果你之前技术做得还不错、算是个“高手”，你应该会更加纠结一点，也许每天都在挣扎着：“今天我要写Code吗？”
在深入探讨这个问题之前，先跟大家分享一下我的个人经历吧~ 我在S公司工作已经满5年了。刚加入这个公司的时候，我的职位是Sr. Software Engineer。公司考虑到我较强的技术背景，让我自立门户——我要招聘新人，建立和发展自己的团队。一开始的一段时间里，我单枪匹马，那时当然是要写Code的…后来招了两个人，带着他们一起做，但我仍然担当主力。再后来做一个大一点的项目，又多招了两个人。逐渐地，沟通和协调的工作多了起来，但我仍然坚持写着Code…由于公司内部组织结构调整，原先项目的Ownership要转给别人，原先的团队成员也要合并到其他团队，而我要去建立一个新的团队，负责一个在战略意义上很重要的底层模块的开发工作。招了两个新人，后来再招两个，很快发展出来一个新的四人团队。那时，我仍然写Code…公司再次重组，把基于那个底层模块的应用软件开发团队划给了我，于是下属人数达到了7人。从那以后，我开始慢慢地不写Code了。但我并没有远离Code。我仍然在读Code，在做Code Review…一年以后，公司再次重组，那个底层模块团队划出去了，而我也接受了一项新的使命，着手创建一个将在公司未来发展战略中承担关键作用的Web Service团队...我现在的职位变成了Sr. Engineering Manager。
我现在的状态是：“基本上”不写Code。为什么说“基本上”呢？因为我有时还会参与应用软件开发团队的工作，帮他们一起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了。
