写到第二行，组长又来改了

一个程序员刚写完第一行，组长说：“不对，应该这样。”

第二行刚敲下去，组长又改口：“这块也别这么写。”

这不是我经历过的现场，而是最近一篇公开文章里的假设。原文想说明，脑力劳动需要自己试错；如果每一步都被打断，执行者很快就会放弃思考，等着那个声音继续报答案。

我读到这里，想到的不是“管理者都该闭嘴”，而是技术团队里很容易混在一起的三件事：代码评审、结对协作和逐行遥控。

代码评审发生在一个相对完整的改动之后。评审者可以指出风险、约束和遗漏，作者仍要解释自己的判断，再决定怎么改。

结对协作是两个人事先同意一起推进，驾驶者和观察者可以交换位置。它的重点是共同解决问题，不是谁永远坐在副驾驶上发口令。

逐行遥控就不同了。任务名义上交给了一个人，过程判断却始终握在另一个人手里。写的人不必再理解为什么，只要猜下一句口令。最后即使代码能跑，责任也变得含糊：方案是谁的，错误又该由谁承担？

管理者想插手，往往不难理解。他可能真的更有经验，也可能已经看见一条会踩的坑。可“我现在能纠正”不等于“我现在纠正最划算”。

一次被提前拦住的错误，省下的是眼前几十分钟；一次自己跑测试、看报错、解释取舍的过程，留下的是下次还能使用的判断。两者不是永远二选一。涉及数据丢失、生产事故或安全边界时，当然要立即叫停。可普通实现分歧如果也按事故处理，团队只会越来越依赖那个随时在线的人。

我更愿意在动手前把三件事说清楚：结果怎样算通过，哪些边界不能碰，做到哪一步再一起检查。其余过程先让承担结果的人走完。

下一次又想在第二行伸手时，可以先把意见记下来，等到约定的检查点再看。如果对方已经自己发现并修掉，说明这段路没有白走；如果没有，再讨论为什么。帮助不必消失，只是从接管每一步，改成在真正需要的位置出现。

资料：

来源