工程经理应该（有时候）写代码
每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/
最近几个晚上，一位医疗科技公司担任工程经理的开发者花时间为 OneBusAway iOS 应用完善实习生所开发的行程规划功能。他做的不是代码评审或架构指导，而是亲自用 Swift 语言编写代码，处理 UI 中的边缘情况，并修复当用户输入一个非常长的目的地名称时才会出现的布局问题。
这些工作，正是传统管理建议中认为一个工程经理不应该做的事情。按照行业普遍的看法，管理者如果还参与写生产代码，可能会造成流程瓶颈，削弱团队的自主性，或回避构建组织能力的更重要任务。对这些观点，他基本认同。
但五年前相比，他现在确实写得更少了，而偶尔“下场写代码”的经历却带来了超出某次 PR（Pull Request）范围的深远价值。在他兼职参与的 OneBusAway 项目中，这种亲身编码的实践反而成为了他保持与软件开发核心联系的重要方式。
了解代码 ≠ 了解编码
评审代码和编写代码的区别，就如同“知道某事”和“真正理解某事”的区别。在评审中，他可以识别架构问题、提出更好的抽象建议、指出明显的 bug。但那毕竟是在评估他人对一个问题的解决方案——而不是他自己与问题之间的博弈。
当他亲自修复 UI 中的布局 bug 时，那种调试 iOS 的 Auto Layout 约束、梳理整个视图层级、寻找导致文本截断的唯一限制条件的过程——这种脑力与经验的投入，是仅靠评审无法获得的。他重新感受到了“把问题解决干净”的满足感。
经验重构了管理者的预期
这类“下场实操”的体验，也显著重构了他作为管理者的判断力。例如，在评审中轻描淡写地建议“加一个 loading 状态”，与亲自实现那个 loading 状态时面对的三种错误场景、UI 动画衔接、用户快速切换标签页等复杂性，完全是两码事。
正是这些亲手处理细节的经历，让他更能体会 polish（打磨）所需的努力，也因此在日常工作中更加合理地评估时间成本、与团队沟通质量标准、并对产品方那种“打磨不需要额外时间”的假设做出有力回应。
side project 是练兵场
相比他日常负责的医疗产品系统，OneBusAway 应用的 stakes（风险）较低。如果他不小心引入了 bug，可能会让用户不便，但不会影响职业生涯。这种容错空间让他得以尝试一些从未使用过的 Swift 语法，或测试在生产医疗软件中不敢贸然使用的架构模式。
掌握“边界感”：别做瓶颈
他说，管理者必须清楚区分哪些是“保持敏锐”的实践，哪些会演变成组织的阻碍。例如：
-
✔️ 在实习生离开后打磨功能细节 —— 完全没问题
-
❌ 成为团队中唯一能部署版本的人 —— 必然是瓶颈
-
✔️ 修复一个副项目的 UI bug —— 好
-
❌ 因为不信任团队而跳入关键路径的开发 —— 坏
他并不是主张经理人应该花大量时间编码。实际上，这类投入通常应控制在 5%-10% 的时间内，而且最好发生在不会阻碍他人进展的上下文中。
偶尔写代码是保持认知更新的方式
一个彻底远离代码的工程经理，久而久之会让自己的“软件开发心智模型”停留在自己最后一次编码时的状态。然而，工具在变，框架在变，环境在变——偶尔动手写写代码，是对这种演进最直观的同步方式。
即将发布的行程规划功能，功能核心由实习生实现，而他补齐了那最后 20%，让这个功能不仅能用，而且“像样”。
这 20% 花的时间，出乎意料地多。而他，也因为这段亲身参与的经历，在日常管理工作中变得更加敏锐与明理。