技术负责人离代码多远比较合适

技术负责人要不要写代码？

这个问题挺容易吵起来。

有人觉得当然要写，不写代码怎么懂系统。

也有人觉得不该写，负责人要看方向、带团队、管交付，不能陷在具体实现里。

我现在觉得，这事不能一刀切。

真正要问的不是写不写，而是离代码多远。

一、完全离开代码，会慢慢失去现场感

如果一个技术负责人太久不看代码，会出现一种问题：判断越来越像从会议室里做出来的。

听汇报，感觉都还行。

看进度，似乎也正常。

但一进代码就会发现，很多问题已经堆在那里了。

接口边界越来越模糊。

异常处理越来越随意。

数据库查询开始复制粘贴。

测试覆盖没有跟上。

这些东西在进度表上不一定看得出来，但在代码里很明显。

有一次我看一个功能的进度，表上写着“后端完成”。但我顺手翻了一下代码，发现几个查询条件都是临时拼出来的，异常直接吞掉，日志里也没有业务 ID。

如果只看进度，这个功能确实完成了。

如果看交付后的维护，它其实还没准备好。

所以技术负责人不能完全离开代码。

你不一定每天写很多，但要能从代码里看出团队现在的真实状态。

二、什么都自己写，也会让团队长不出来

另一边也一样。

如果负责人一直写最核心的代码，团队会很舒服。

难点有人处理，风险有人兜底，进度看起来也稳。

但时间久了，团队就会习惯把复杂问题留给你。

你写得越多，别人越没有机会练。

最后你会发现，自己越来越忙，团队越来越依赖，系统越来越离不开你。

这不是好状态。

负责人写代码应该有边界。

不是为了证明自己还能写，而是为了建立方向、验证风险、给团队一个参考。

三、我觉得有几类代码值得负责人亲自看

第一类，系统关键路径。

比如登录权限、支付、设备数据采集、生产流程、核心统计。这里出问题，影响面大，负责人应该看。

第二类，容易变成长期债务的设计。

比如数据模型、接口边界、异步任务、日志链路。这些东西早期随便一点，后面会很难补。

第三类，团队反复出问题的地方。

如果同类问题一直出现，不要只怪某个人粗心。负责人要看代码，看流程，看是不是标准没有建立起来。

第四类，新人或新模块的第一版。

不是为了挑刺，而是尽早把方向校准。

四、写代码和看代码，不是同一件事

我现在更愿意把时间放在“看关键代码”上。

不是每个功能都亲自写，而是通过 Review、设计讨论、线上问题排查，保持对系统的触感。

偶尔我也会写一些代码。

但通常是写样例、写基础框架、写某个风险点验证，而不是把所有核心实现都揽过来。

比如一个新模块开始时，我可能会和团队一起把目录结构、异常处理、日志格式、几个关键接口先定下来。

后面具体业务逻辑就交给负责的人做。

这样既不会让团队从零猜，也不会把所有实现都变成我的个人作品。

你可以写一段让团队参考的代码。

但不要把自己写成团队唯一能交付复杂功能的人。

五、小结

技术负责人离代码太远，会慢慢失去判断质量。

离代码太近，又容易压住团队成长。

比较合适的位置，可能是这样：

关键路径要看。

关键风险要管。

团队标准要建立。

普通实现要让团队自己完成。

你要保持手感，但不要让团队只剩你的手感。

我觉得比较好的状态，是团队知道你能看懂代码，也知道你不会每一行都替他们决定。

这样 Review 才不会变成审判，编码也不会变成等批作业。

本系列：