近日，有个话题很热门，就是一线管理人员对不写代码颇有微词，话题具体如下：
针对这个话题不少网友也都有自己的看法，比如
关于一线leader，我也一些自己的看法，抛砖引玉，仅供大家参考：
一线leader是否需要写代码，取决于所在公司和管理的人数。
其实一线管理人员，这个概念很广泛，因为互联网行业的公司其实很多，是否需要写代码，不应该一概而论，而是需要按照实际情况来决定，主要是公司大小和管理的人数来决定的。
如果你身处在一个小型公司，比如几十人的公司，一线主管是当然需要在前线写代码的，其实这种公司请一个人来当leader就是为了掌控某些关键技术的方向，解决关键的疑难问题的。
如果是在一个大公司比如大家所熟悉的bat、tmd，如果你只是管理十几个人，那也是以写代码为主，以管理为辅，这样就能够胜任你所承担的工作。
如果在大公司，一线主管管理人数在三四十人，其实这种公司身为一线技术主管，是需要写代码和管理两种能力都重要，因为大公司一般情况下公司的业务相对比较复杂，如果完全不做技术，只是管理项目，分配任务，那这个领导其实也很难做好管理。
如果在大公司，一线主管管理人数在五十人以上，基本上是以管理为主，但是也需要去看相关工程的代码细节，整体深入理解核心业务情况。
如果在大公司，一线主管管理超过了八十人，那应该是以业务为主，基本上可以脱离代码层面，但是还是需要熟悉整体的技术架构。
大部分大公司的员工本省技术能力都比较强，如果一个只做ppt和分配任务的活，既不能服众也不能深入理解业务，其实一线leader跟上级来汇报的时候也没有办法赢得信任，因为在公司决定一个人的成绩，还是看业绩的，如果你对所管理的业务没升入理解，就没有办法真正的推动和解决所面对的问题，只是根据组内人员的周报和回报来了解基本情况，这样在汇报问题的时候回答更上级的领导的问题，经常只能使用“可能”“应该”等等词语来解释一个问题，这种情况下上级领导很难对你有真正的信任。
作为一个公司非一线的领导，当他分布一个任务的时候，希望后续追问业务进度、细节、和结果时，都是希望得到一个明确的回答，比如在进度上，一般希望得到的上完成30%等等这种可以量化的数字，有时候遇到某个细节问题，大领导会随口一句追问，如果在平时没有深入业务，真正做业务写代码，其实比较难掌握非常详细的情况，这种情况下经常就是只能说“下去查查”，这种回答其实一般大领导都不喜欢。
你怎么看待一线主管的呢？
