极客视点
极客时间编辑部
极客时间编辑部
113240 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/03:51
登录|注册

技术Leader是否应该写代码?

讲述:丁婵大小:1.75M时长:03:51
网上有很多文章建议开发经理要么完全不写代码,要么最多花 30% 的时间在代码上。但问题是,太过关注开发经理需要写多少代码,反而忽略了开发经理为什么要写代码。
一名优秀的开发经理意味着你的优先考虑事项是管理以及与团队成员互动。你需要培养管理技能,而这其中相当重要的一点是同理心。同理心意味着开发经理需要从工程师的角度看待问题。
很多优秀的开发经理曾经也是工程师。然而,工程技术领域在不断发展,作为开发经理,需要与时俱进才能保持对团队的同理心。
因此,不要问“我应该写多少代码”,而应该问“我在什么情况下可以写代码”。如果你不知道该问题的答案,还可以从反面来看待这个问题,比如“在什么情况下我不应该写代码?”。
如果人是开发经理的首要任务,那么通过代码塑造一个伟大的工程团队需要更多地关注测试、监控、代码评审、设计文档等。
完成这些任务所需的时间和空间只有全职工程师才有。如果开发经理去写代码,同时又期望别人能够完成其它繁重的工作,如测试、调试、文档、评审、监控、维护等,那么开发经理将失去激励伟大工程团队的能力。
所以开发经理不应该在团队的关键路径上写代码。虽然这看起来似乎有所限制,但也带来了新的机会。
那么开发经理什么时候可以写代码呢?有如下情况。
1. 代码评审
编程活动包含了 10%的编码和 90%的设计、沟通、测试、阅读代码等。因此,开发经理的另一种“编码”方式就是完全不写代码。
代码评审有助于建立团队同理心,同时还可以加强编程技能,并建立对产品更好的理解。代码评审要求评审人员能够阅读和理解代码,所以,这是开发经理必须具备的技能之一。
2. 修复小 bug
与代码评审一样,修复小 bug 不需要写大量的代码。但他需要阅读与 bug 相关的代码,并需要一个有效的开发环境。
开发经理应该十分谨慎,避免引入新的 bug,并在修改完 bug 后进行测试,但要尽量避免修复团队最近引入的 bug。
此外,开发经理应该在存在巴士因素(bus factor,团队成员被巴士撞伤会影响项目进度,指某些事情只有某些人会做就会成为项目的风险点)的项目上这么做,或者负责处理那些老 bug 或琐碎的问题,因为这些问题只会消耗已经负担过重的团队成员的时间。
虽然团队专注于构建优秀的产品,但仍有很多机会改进用于设计优秀产品的工具。通过自动化改进这些工具或开发新的内部工具为工程师和开发经理提供了发挥影响力的绝佳机会。但是,未来避免维护和开发新功能可能会成为开发经理未来的负担,开发经理需要将工具及时交给新主人。
开发经理可以尝试构建更好的工具,帮助团队更好地完成工作,而不是寻找管理任务以外的事情。作为开发经理,可以通过代码来改进或自动化很多任务。
最后,开发经理在适应了这些写代码的场景后,就可以更好地回答之前的问题:何时以及需要写多少代码。对于这个问题,其实没有一个正确的答案,这取决于开发经理个人,他们需要确定他们在激励团队构建优秀产品时是否具有足够的同理心。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • Loulan 翟怀楼
    我认为至少应该参与代码评审,二者都没有的领导,通常会擅长其他方面。这是一个侧重性的东西。
    2
  • galen
    技术leader的基础是"技术",并且在整个团队的管理过程中离不开技术因素。管理先不论,但如果没有过硬的技术,很难服众,有时需要出方案或选定方案,这个时候,就会出现很尴尬的局面……如果没有很牛逼的管理水平,又把技术荒芜的差不多了,只懂一些跟宏观的东西(吹水嫌疑很大)…… 对个人长期发展而言不是什么好事
  • 文洲
    业务代码可以不写,要了解,架构代码要写还要熟悉,领导团队跟上业务需求
  • 李春恒
    会写ppt就行了。
  • 加菲猫
    技术Leader是否应该写代码?写与不写是一种博弈关系,很难说的清楚,场景不同,说法不同,不能用简单的写或是不写来评判,要看公司性质,文化以及技术Leader本身等等原因
  • Panda
    Tech leader 应该写代码
收起评论
显示
设置
留言
6
收藏
58
沉浸
阅读
分享
手机端
快捷键
回顶部