第134期 | 技术 Leader 是否应该写代码？
池建强
讲述：池建强大小：5.71M时长：06:14
你好，这里是卖桃者说。今天跟你聊聊技术 Leader 是否应该写代码的话题。
之前，极客视点栏目编译过一篇 Medium 上文章，主题也是工程经理（技术 Leader）应不应该写代码，看来这个问题是国内外共通的。
国外经常把技术团队负责人叫做 Engineering Managers，国内就五花八门，比如 CTO、技术总监、研发总监、技术经理、技术组长、P8、P9 等等，差不多都是技术团队负责人的意思，只不过团队大小，各不相同。
那技术 Leader 是否应该写代码呢？这个问题特别容易被极端化。唯技术论会觉得这是个问题吗？当然要写，不写代码还算什么技术 Leader？而另一个极端就是技术领导写什么代码？你要成就团队才行啊，团队做出了成就，你才会变得更强，否则当什么 Leader？
网上也有很多文章建议技术经理要么完全不写代码，要么最多花 30% 的时间在代码上。但问题是，太过关注技术经理需要写多少代码，反而忽略了他们为什么要写代码。
一名优秀的技术经理意味着你的优先考虑事项是管理以及与团队成员互动。你需要培养管理技能，而这其中相当重要的一点是同理心。同理心意味着技术经理需要从工程师的角度看待问题。
很多优秀的技术经理曾经也是工程师。然而，工程技术领域在不断发展，作为技术经理，需要与时俱进才能保持对团队的同理心。
因此，不要问“我应不应该写代码”“我应该写多少代码”，而应该问“我在什么情况下可以写代码”。如果你不知道该问题的答案，还可以从反面来看待这个问题，比如“在什么情况下我不应该写代码？”
一般来说，通过代码塑造一个伟大的工程团队需要更多地关注测试、监控、代码评审、设计文档等诸多方面。而完成这些任务所需的时间和空间只有全职工程师才有。如果技术经理去写代码，同时又期望别人能够完成其它繁重的工作，如测试、调试、文档、评审、监控、维护等，那么技术经理将失去激励伟大工程团队的能力。
所以技术经理不应该在团队的关键路径上写代码。虽然这看起来似乎有所限制，但也带来了新的机会。
那么技术经理什么时候可以参与到代码中来呢？我想这些场景可以参考：
1. 代码评审
编程活动包含了 10％的编码和 90％的设计、沟通、测试、阅读代码等。因此，技术经理的另一种“编码”方式就是完全不写代码，取而代之的是积极且深入的参与这些流程。
其中，代码评审有助于建立团队同理心，同时还可以加强团队编程技能，并建立对产品更好的理解。代码评审要求评审人员能够阅读和理解代码，所以，这可以说是技术经理必须具备的技能之一了。
2. 修复小 bug
与代码评审一样，修复小 bug 不需要写大量的代码，但它需要技术经理阅读与 bug 相关的代码，并需要一个有效的开发环境。
技术经理应该十分谨慎，避免引入新的 bug，并在修改完 bug 后进行测试，但要尽量避免修复团队最近引入的 bug。
3. 巴士因素
此外，技术经理还应该关注巴士因素的项目。Bus Factor，就是指团队成员被巴士撞伤了，就会影响项目进度，因为有些事情只有他能做。这是个风险点。技术经理要去关注这种的风险，必要时扑上去救火。
4. 处理老旧的 bug 或琐碎的问题
这是需要技术经理关注的另一个场景，因为这些问题只会消耗那些已经负担过重的团队成员时间。
5. 构建工具
团队一般会专注于构建优秀的产品，技术经理可以去组织和构建一些用来改进流程和提升效率的工具。通过改进这些工具或开发新的内部工具为工程师提供更好的服务，也可以提升自己的技术影响力。但是，要避免维护和研发新功能成为你的新负担，在一定的时候，要将工具及时交给新主人。
技术经理可以尝试构建更好的工具，帮助团队更好地完成工作，而不是寻找管理任务以外的事情。作为技术经理，可以通过代码来改进或自动化很多任务。
最后，技术经理在适应了这些写代码的场景后，就可以更好地回答之前的问题：何时以及需要写多少代码。
对于这个问题，其实没有一个正确的答案，这取决于技术经理的个人素质。技术强一些，还是管理好一点，亦或是对产品和业务的敏感度更高些，都会决定这个技术经理对待代码的态度。
无论如何，把事情做成，才是最重要的，而不是自己写了多少代码。
好，今天的话题就先聊到这儿，这是卖桃者说第一季的倒数第二期啦。卖桃者说，明天见。
（编辑：成敏）
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《卖桃者说》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
- 大响马但是如果上司非得要求你写代码呢？我的上司研发总监是个老一代程序员，他就认为我写代码之外的工作没太大意义。
池建强回复: 看你自己的职责，工程师当然主要是写代码了。如果是个 Leader，上司认为你写代码之外的工作没有意义，那这个 Leader 也没有设置的必要。
1 
ipofss不会停更吧，极客时间从第一版我就开始用，卖桃者说从第一期就开始听池建强回复: 不会
leslie这事儿怎么说都可以都有理：简单的说可能只写核心的或者关键的代码，就如文中所说的10-30%-工具与攻关；剩下基本上是框架/结构的设计与指定、代码审核、技术文档的编写、代码规则的指定以及指导新人/成员方向70-90%吧。关键就是把当下这段时间的事情和团队成员一起顺利完成：就这么简单。池建强回复: 你说的也有道理
2
雷霹雳的爸爸可以不写，不能不会，这样才能做到该出手时就出手吧8
熊斌得写 技术这玩意儿 学到理论后重在实践，如果各种架构理论聊得头头是道，没有实践过，就会像赵括一样，纸上谈兵，害人害己3
张明云我的想法也是这样，只有踩过坑了才对这个观点有更深刻的认识。 技术leader 要写代码，不在前线久了会导致失去对技术的判断。但不要写迭代中的代码，因为你不可能全身心投入到编码过程中，因为杂事多可能会拖项目的后腿。可以做一些对项目有价值但又不影响进度的编码类工作，比如指标优化、编写效率提升工具等。1
Geraint才发现，我竟然干着技术经理的活。😂 虽然我就是一个普通的开发1
Sam_Deep_Thinking能不能写一篇领导应不应该陪加班？我遇到过很多领导，都有陪加班，也遇到过一大早走人，隔天早上问进度和风险，但是又不能提供解决方案，只是会喊口号，（使命必达）。1- flower女技术总监兼产品经理，一行代码不会写，怎么办，立刻退休否？
小斧对于这个问题，其实没有一个正确的答案，这取决于技术经理的个人素质。技术强一些，还是管理好一点，亦或是对产品和业务的敏感度更高些，都会决定这个技术经理对待代码的态度。 无论如何，把事情做成，才是最重要的，而不是自己写了多少代码。
收起评论