Team Leader 究竟要不要写代码？

今天浏览 Medium，看到一篇直接喊出「技术负责人，请停止写代码」的文章，晚间和家属一起坐火车，不禁一起围绕着这个话题进行了一番讨论。

文章中说到，成为一个 Team Leader 最难的是要明白「你不再是一个真正的开发者」了。既编程又管理往往会导致你非常地倦怠，最终两项工作都做不好。

大部分开发任务都需要高度集中和专注，这与团队领导工作相悖。当各式会议、电话持续不断，要去考虑这个代码该怎么写实在是困难得很。

作为 Team Leader，如果你满脑子想的都是刚写的函数，这就很难来回答团队成员或者客户的问题。

要想成为一个好的管理者就意味着必须放弃那些使你效率低下的习惯，即便这包括要放弃写代码。

另一方面，人的精力总是有限的。如果将大量的时间花在了开发上，那么就没有时间再去做身为一个 Team Leader 的工作。这个时候往往会对团队产生负面的影响。

那么对于 TL 来讲，该做什么呢？

1. 六字箴言：「咨询」、「指导」、「协助」；
2. 做 Code Review，帮助团队解决具有挑战性的编程问题；
3. 抬头看路，阅读技术文章，了解最新的技术新闻和趋势，为自己解决一些小的编程挑战，以此来保持大脑的敏锐。

我相信对于许多开发者来说，写代码永远是最纯粹、开心的事情。今日如雷军等已经很功成名就的企业家常常很怀念写代码的日子。但是写了几年代码后，逐渐成为一个技术管理者时，我们往往会变得很难受，因为曾经是一个优秀的独立贡献者，能写出精良的代码，但现在成为了技术管理者，带领着一个团队，离在一线写代码可能就越来越远了。

那么，当你成为 Team Leader，究竟还要不要写代码？

读完 Medium 上的这篇文章，我将这个话题抛给了同为程序员的家属，家属和我分享了他的观点：

Team Leader 根据公司产品的属性可以分为两种 —— 业务型和技术型。

针对业务型的产品，Team Leader 需要更多地去关注业务，这个时候，写代码的工作就需要交给一线的工程师们。这类的产品更多的在于业务需求，对技术能力的要求并没有那么高，是一线的工程师可以搞定的。

这个时候，Team Leader 更多的是去把控业务发展节奏，去帮助一线的工程师合理梳理业务需求及优先级，帮助一线的工程师快速落地并实现产品需求。

而针对技术型的产品，Team Leader 则依然需要去写代码。当然这不仅仅是写代码，整个项目的架构以及技术选型都是 TL 需要核心关注的点。技术发展非常快，TL 需要有很高的学习能力，以及自身在写代码中去验证。

一个好的项目架构都是通过无数的磨炼，经历了无数代码的磨炼，才能练就出来的技术能力。

那么，读到这篇文章的朋友，你有什么观点？欢迎留言我们一起探讨。