一个工作感悟
1 什么感悟
程序员的leader一定不能脱离代码。即使不写，对团队项目的了解，也要到了解具体代码细节的程度。
2 曾经自己的谬误
leader的精力，有很多要放在给团队争取更好的项目资源，抵御不必要的外部压力上。说穿了，就是给自己的下属「选择工作内容」，这个过程也是很费神的。作为leader, 承担了这些工作，就已经没办法再有时间精力投入到编码工作中了。
3 我自己现在的看法
别说是管理几个人，十几个人的leader, 就算是管理几十人，上百人的技术负责人，只要他的团队还是一个纯粹的技术团队，这个人就不能脱离「代码」这个团队的核心工作内容。
4 为什么
4.1 首先，长期脱离代码，人会对技术缺少敬畏
很多基层的程序员，会有「我宁愿自己的领导完全不是技术出身」的心声。完全不是写代码出身的人，反而会因为写代码这件事对他的「神秘性」，理解团队提出的困难，尊重技术人员的意见，而曾经做过技术工作而又长时间脱离编码工作的人，会天然的有一种自信：「我不懂这些东西，只是因为我没有去学，如果我去学，我一定分分钟掌握」，由此，会认为团队的很多困难，只是「下属加班还不够多」，「投入的人力还不够多」，犯「既然一个女人10个月才能生一个孩子，那我投入10个女人就能一个月生孩子」这样愚蠢的错误。
4.2 进而，无法判定「资源」的价值
尤其对于基础技术团队而言，选择任何一个方向去发力，往往都意味着以「年」为单位计算的深耕，这种深耕后，才能做到有所积累，对于业务具备一定的不可替代性。
而脱离代码的人，一篇公众号文章，一个短视频，都可能让他产生一种「这就是未来」的错觉。
因为他不能评估一件事情，意味着多大的编码量和编码难度，做成以后能多大程度证明团队的产出对业务的价值。
导致的结果是，团队会承接很多「业务线领导提的」或者「兄弟团队无暇开发」的工作。在各种无关联的项目上横跳，很忙，但是不聚焦，无积累。
而一线写代码的人，则会对领导产生一种「不唯实，只唯上」的看法，团队凝聚力会骤减。
4.3 更进一步，无法抵御外部压力
可以说这个世界上不存在在任何环境下都能完美运行没有bug的代码。但是bug严重程度有轻有重。有的，可能只影响极少数的特殊设备特殊用户，有的可能是真的大面积影响业务的在线运营。
当缺陷被反馈到基层的时候，不接触代码的leader，是不能评估这种严重程度的。举个例子，某用户在一种非常小众的设备上运行app出现错误，投诉从客服转到研发团队。可以想见，了解团队代码在兼容性所做工作的完成度的leader，能够准确判定缺陷影响面是个例，可以对这种不严重的缺陷作出「排期处理」，「下版本修复」这样的决策。而不了解的，恐怕只能以「线上反馈无小事」这种道理，来打断团队正常工作，让下属加班解决了，压力几乎是直接透传到一线，毫无缓冲。
而实际上，编码工作需要思维的持续性，频繁被打断对开发效率影响是非常高的。在这种模式的领导下，这个团队的开发工作不可能具有高持续性，长期来看，就是对产出的严重影响。
5 总结
脱离代码的程序员leader, 其实无法做到leader的本职，「争取资源」「抵御压力」，进而也更无法做到「带领团队每个人进步」。
技术人员的领导，就应该懂技术，然后才是会领导。因为，他本身就是技术人员的一部分，然而他脱离了技术，这本身就是荒谬的。