我花了很多时间为开发经理提供建议，很多刚走上开发经理岗位的新手总是问我：“我应该写多少代码？”
网上有很多文章建议开发经理要么完全不写代码，要么最多花 30% 时间在代码上。
但问题是，太过关注开发经理需要写多少代码，反而忽略了开发经理为什么要写代码。
一名优秀的开发经理意味着你的优先考虑事项是管理以及与团队成员互动。你需要培养管理技能，而我认为最重要的是同理心。同理心意味着你需要从工程师的角度看待问题。
很多优秀的开发经理曾经也是工程师。然而，工程技术领域在不断发展，作为开发经理，需要与时俱进才能保持对团队的同理心。
因此，不要问“我应该写多少代码”，而应该问“我在什么情况下可以写代码”。
在 Coursera，我们的开发经理就是这种方法的最佳实践者。这样做不仅让我们可以“保鲜”我们的工程技能，同时又提升了对团队工程师的同理心。
什么情况下不要写代码 有时候，回答一个棘手问题的最好方法是回答反面的问题，比如“在什么情况下我不应该写代码？”。
如果人是开发经理的首要任务，那么通过代码塑造一个伟大的工程团队需要更多地关注测试、监控、代码评审、设计文档等。
完成这些任务所需的时间和空间只有全职工程师才有。如果开发经理去写代码，同时又期望其他人能够完成其他繁重的工作（测试、调试、文档、评审、监控、维护等等），那么开发经理将失去激励伟大工程团队的能力。
开发经理不应该在团队的关键路径上写代码。虽然这看起来似乎有所限制，但也带来了新的机会。
什么情况下要写代码
1.代码评审
编程活动包含了 10％的编码和 90％的设计、沟通、测试、阅读代码等。
因此，开发经理的另一种“编码”方式就是完全不写代码。
代码评审有助于建立团队同理心，同时还可以加强编程技能，并建立对产品更好的理解。代码评审要求评审人员能够阅读和理解代码——可以说是伟大工程师最重要的技能之一。
2.修复小 bug
有时候，开发经理有机会卷起袖子修复一些小 bug。与代码评审一样，修复这些 bug 不需要写大量的代码。
但它需要阅读与 bug 相关的代码，并需要一个有效的开发环境。
开发经理应该要十分谨慎，避免引入新的 bug，并在修改完 bug 后进行测试，但要尽量避免修复团队最近引入的 bug。
开发经理应该在存在巴士因素（bus factor，团队成员被巴士撞伤会影响项目进度，指某些事情只有某些人会做就会成为项目的风险点）的项目上这么做，或者负责处理那些老 bug 或琐碎的问题，因为这些问题只会消耗已经负担过重的团队成员的时间。
虽然团队专注于构建优秀的产品，但仍有很多机会改进用于设计优秀产品的工具。通过自动化改进这些工具或开发新的内部工具为工程师和开发经理提供了发挥影响力的绝佳机会。
例如，Nick Dellamaggiore（Coursera 的基础设施负责人）注意到，工程师使用了大量样板代码来监控事件管道中的事件。他希望减少这些样板代码，并避免为每个新监控器重新部署服务。后来，他做到了，甚至超出了期望。
我们现在都在使用他的方法对我们的产品进行性能监控和产品使用监控。
但是，如果这些工具变得非常流行且不可或缺，那么维护和开发新功能可能会成为开发经理未来的负担。为了避免这种情况，开发经理需要将工具交给新主人。
开发经理可以尝试构建更好的工具，帮助团队更好地完成工作，而不是寻找管理任务以外的事情！作为开发经理，可以通过代码来改进或自动化很多任务。
1. Google 脚本
几个季度前，我过了一遍之前所有的事故分析报告，从中识别出事故发生的趋势，并确定我们在跟进预防性问题方面究竟有多大的实力。
我们的事故分析报告太过分散，而且从每个报告中复制数字数据是件非常耗时且无聊的事情。
为了给我自己以及其他开发经理减负，我开发了一个 Google脚本。现在，工程师只需填写一个Google 表格，回答一组标准问题，就可以自动生成事故分析报告，同时将有价值的指标填入中央电子表格。
这样不仅改进了事故报告的分析工作，我还从工程师那里听说，他们花在填写事故报告上的时间更少了。
最近，Priyank Chodesetti（学习体验团队的开发经理）也写了一个Google 脚本，用于自动化团队sprint 回顾过程。自从他发布了这个脚本以后，sprint 回顾的参与度得到了很大的提升。
2. JIRA
在 Coursera，我们使用 JIRA 进行 bug 跟踪和 sprint 计划。
Jerry Charumilind（学习体验平台团队负责人）汇总了一份关于我们团队在解决 ticket 方面的有效性报告。
虽然 JIRA 可以做很多事情，但很难通过内置插件来提取历史数据。不过，借助 Python 和非常有用的 matplotlib，Jerry 直观地向我们展示了我们的团队在这方面做得有多好。
最近，Jerry 又写了一个自动化脚本，可以向问题所有者发送有关问题时效性和优先级的通知。
3. Slack
slackbot 为开发经理提供了一个写代码的机会，同时还可以提高团队的工作效率（或娱乐性）。
去年，我创建了三个 slackbot：
Buggy——用于创建、搜索和分配 JIRA 问题；Foody——用于查询我们的午餐和晚餐菜单；Booky——用于搜索 gitbook 上的工程文档。
4. 检查器
伟大的工程实践也可以从编程中受益。Mustafa Furniturewala（学习体验团队的开发经理）在他希望改善团队测试文化时就遇到了这种情况。
在 Coursera 评审代码时，我们会自动执行 linting，阻止不遵循编码样式指南的代码提交。Mustafa 写了一个脚本，强制要求所有新组件至少包含一个单元测试。
开发经理因此可以花更少的时间在手动检查代码提交上，并花更多的时间深入思考如何激励团队进行更好的单元测试和集成测试。
5. 公司内部黑客马拉松
在 Coursera，make-a-thon（我们的黑客马拉松版本）为开发经理提供了绝佳的写代码的机会。在过去的三个季度中，几乎每个开发经理都参与其中。在上一个 make-a-thon 中，Richard Wong（Coursera 工程总监）因为他的项目能够自动从视频脚本生成音频而斩获了最佳表现奖。他的现场演示非常精彩！
一些开发经理喜欢参与宠物项目、副业或甚至是开源项目（例如，我在维护不是很流行的 emailjs ）。这些项目为他们提供了编写大量优秀代码的机会。
外部工作为开发经理提供了有趣的编写代码的机会，与此同时，企业应该考虑采用更全面的方法来鼓励开发经理抽出时间来编写工作相关的代码，特别是鼓励健康的生活工作平衡。
什么时候可以认为开发经理写的代码够多了？我已经建议开发经理在哪些情况下可以写代码，当然，这并不是一个完整的清单。好的开发经理可以通过这些方法来为他们的团队建立同理心。
开发经理在适应了这些写代码的场景后，现在就可以更好地回答之前的问题：何时以及需要写多少代码。
我不认为它有一个正确的答案。这要取决于每个经理自己，他们需要确定他们在激励团队构建优秀产品时是否具有足够的同理心。
最近，我的一位工程师在调试她发现的 bug 时向我求助。我们花了大约 20 分钟阅读代码，并尝试各种输入，最后找到导致 bug 的根本原因。当我的团队很乐意找我寻求帮助时，这些互动告诉我，我写的代码已经够多了。
