负责团队之后，我为什么仍然坚持写核心代码

从工程师成为技术负责人之后，一个常见问题是：还要不要继续写代码？

一种观点认为，负责人应该把时间全部用于架构、排期和人员协作；另一种观点则把“保持编码”理解成继续领取大量需求，甚至成为团队里最忙的开发。

我的经验介于两者之间：技术负责人不必写下最多的代码，但应该持续参与最能暴露系统真实约束的代码。

我曾从 0 到 1 组建并负责 6–7 人研发团队，也带过更小的交付团队。在这些经历里，持续参与核心开发并不是因为不愿意授权，而是因为它能让很多管理和技术判断建立在事实之上。

编码是理解系统的一种方式

架构图表达的是我们希望系统如何工作，代码和生产日志呈现的则是它实际上如何工作。

当负责人完全离开实现一段时间，判断容易建立在过时印象上：以为某个模块边界已经清晰，以为一个接口只是增加字段，以为部署流程足够稳定。真正开始修改时，团队才发现隐藏依赖远比预期多。

参与核心代码可以持续校准这些认知。但“核心”不等于“最难”或“最炫技”，而是那些能够揭示系统关键约束的地方，例如：

• 新业务的第一个完整纵切；
• 涉及多个系统的接口契约；
• 支付、订单和权限等高风险逻辑；
• 一次架构迁移的示范模块；
• 难以复现的生产故障。

写过第一条完整链路之后，负责人更容易把后续任务拆成团队可以并行完成的部分。

负责人写代码，不应该成为瓶颈

技术负责人参与实现最大的风险，是所有关键任务都必须等他完成。短期看很高效，长期会让团队失去独立交付能力。

我会用几个原则避免这个问题：

1. 优先写样板，不长期占有模块。 把新模式跑通、记录决策，再让其他成员继续扩展；
2. 选择高信息量任务。 参与能帮助理解系统的问题，而不是把大量重复页面留给自己；
3. 代码从一开始就进入正常评审。 负责人写的代码也要被团队审阅；
4. 确保至少一位成员理解实现。 关键模块不能只有一个人能够维护；
5. 主动退出稳定区域。 一旦边界清晰，就把所有权交给团队。

负责人写代码的目标不是证明自己仍是最强开发，而是降低未知、建立边界、帮助团队更快形成共同理解。

任务拆解必须靠近实现

“开发一个预约功能”不是可执行任务。真正的任务可能包括数据模型、可用时段计算、价格规则、订单接口、支付回调、页面状态和运营后台。

如果任务拆解离实现太远，常见结果是：

• 工作量按页面数量估算，却忽略后端状态变化；
• 前后端各自假设接口，联调时才发现不一致；
• 正常路径很清楚，异常和恢复路径没人负责；
• 任务看似完成，却缺少日志、迁移和发布方案。

保持编码让我能够更早看到这些缝隙。拆解时，我会要求每个任务尽量包含明确输入、输出和验收方式，同时把跨模块风险单独列出。

好的任务应该可以被验证，而不只是被“做完”。

代码评审是建立共同判断，不是找错

如果代码评审只由负责人指出问题，团队会越来越依赖一个人的偏好。更有价值的做法，是把评审变成对设计判断的解释。

例如，与其只说“这里应该抽象”，不如说明：

• 当前重复是否真的会一起变化；
• 抽象之后，调用方需要理解多少概念；
• 错误应该在哪一层被转换；
• 这个边界是否方便单独测试；
• 下一项需求到来时，哪部分最可能变化。

同样，负责人自己的代码也应该接受这样的讨论。团队看到技术判断可以被质疑和修正，才会更愿意表达不同意见。

生产问题需要负责人保持手感

线上故障往往同时涉及业务、代码、数据和部署。技术负责人如果熟悉真实运行链路，可以更快做出优先级判断：先恢复服务，还是先保护数据；应该回滚版本，还是补偿任务；哪些操作可逆，哪些需要等待外部平台。

但这不意味着负责人应该独自处理每次故障。

更好的方式是共同响应，并在事后沉淀：

• 一条可复用的排查路径；
• 关键链路的监控和关联 ID；
• 必要的后台修复工具；
• 明确的回滚与补偿方案；
• 对系统边界的新理解。

故障处理的成果不只是修复当下问题，还应该让下一次响应不再依赖同一个人。

管理和编码不是两份工作

当我参与系统架构、任务协作和生产交付时，编码并不是管理工作之外额外增加的一份个人任务。它是获取信息、验证设计和建立团队标准的一种手段。

真正需要避免的是两种极端：

• 完全离开实现，只通过会议和文档理解系统；
• 承担所有难题，让团队只能等待和执行。

技术负责人的价值，在于让正确的信息流向正确的人，让复杂问题拥有清晰边界，并让团队逐渐具备不依赖负责人也能稳定交付的能力。

我仍然写核心代码，但我希望留下的不是“只有我能维护”的模块，而是一套团队可以继续工作的路径。