技术管理者应不应该写代码？

我相信所有新晋的技术经理，都做过Team的工期紧张，自己加班动手写Code的事情，这种事情我自己也没少干过，事实上，偶尔我自己仍然会在critical的项目上写一些代码。相信不少同志们还引以为荣，并且不少技术管理的书上，对于技术管理人员是否应该去写代码也有不同的观点，有些认为不应该写，有些认为一定要写一点避免脱离群众外行指挥内行。我之前也一直犹犹豫豫有时候写点有时候逼着自己不写，但是黄易山在Quora上的这个回答，最终还是让我有了“还写砍手”的自我提醒。

理性上，我完全同意黄易山的观点，写工具是可以的，但是在deadline下写项目代码是对团队和个人都长期不利的，虽然也许短期内对自己的KPI有利。但是过去克制不住的愚蠢和冲动时不时让我冲到critical的项目上写一两个模块，但是每次反思，其实我知道这样对整个团队的效率，以及我自己的成长没有太大帮助。事实上，从这些项目中技术经理个人是得不到成长，还不如写点工具对自己的帮助大，原因就是为了进度压力，技术经理去写代码只能是重复自己已经做过的事情。而写代码本身是需要大片完整时间的，会占用掉大量你本来应该做的事情的时间。

也请认识我的朋友们监督我，如果还看到我在critical项目中冲进去写很多代码，阻止我一次请杯咖啡。

成为一个经理之后，你如何继续保持你的技术能力？

黄易山，一个前技术总监

作为一个足够大的团队的经理，你不应该继续写代码。我辅导过许多新晋的技术经理，我总是告诉他们 —— 当一个团队大于~4个人的时候，他们不应该再去写代码并且要抵制自己写代码的冲动。

原因在于，当你的团队遇到死命令的时候（比如，交付日期），一个年轻的经理很可能会被诱惑退回到他/她的舒适区中去解决问题。那就是，相较于做困难的(并且在时间上看来是很有风险的)更好地组织，激励团队，以及不管什么需要他们去做的“经理的工作”，他们立刻卷起袖子，熬夜加班，通过自己写代码来将项目完成。之所以这很糟糕是因为当像这样的艰难时刻出现的时候，恰恰是一个新的经理需要学习如何 有效地管理，并避免退回去使用他们的旧的技能的时候。如果他们诉诸于使用他们的技术能力来帮助他们的团队，他们永远不会学会变成一个卓有成效的经理。 这是一个那些前工程师是否最终成长为一个好的经理的至关重要的分界点。

除此之外，保持你的技术能力是非常简单明确的。

第一件事就是你真的不需要太担心失去你的优势。如果你过去干得不错，你不会像你想象地那样生锈的。在管理岗位上呆了2年+之后（并且担心这个问题），我加入了另一个公司并且重新回到了一个直接写代码的角色上，我发现非常奇怪地是，我的技术能力 进步了。如果你是一个深入参与技术的技术经理，显然从一个更广的团队层面思考软件管理是有助于将通用的概念在一个更高的层面上组织起来的，并对回过来进行个人实践是有帮助的。另一方面，我并不知道如果你在管理岗位上呆上比如10年之后这一点是否仍然还是对的。

第二种方法就是写代码。但是，你不能为有交付期限的关键项目写代码。那就是说，你不应该为你的团队“需要”来贡献代码。这就时我在本文早先部分的答案——对于你的团队需要交付的项目，你应该通过 更好地管理来提供贡献，而不是写代码。取而代之的是，你应该写一些内部工具或者为非关键项目写代码（也许是另一个团队的非正式的架子）。这些可以和那些有最后期限或者关键业务项目一样在技术上非常复杂，所以你无需担心你无法从合适的技术和算法中得到经验。或者，你可以在家里的空闲时间里写无关的技术项目。这是我第一次当经理时候选择的方法，在我的休息时间，我创建了一家创业公司并且学了一门新语言，以及关于可扩展性和数据库的许多东西。

所以，你可以用你一直用的方法来保持你的技术能力，写代码。只是 不要为你的团队写代码。