The Manager Changed the Second Line Again

A developer finishes the first line of code. The manager says, “No, do it this way.” The second line appears, and the manager changes it again.

This is not something I am presenting as my own experience. It is a hypothetical scene from a public essay I recently read. The essay argues that knowledge work requires room to make and correct mistakes. When every step is interrupted, the person doing the work soon stops thinking and waits for the next answer.

What caught my attention was not a broad claim that managers should stay silent. It was the way three different practices are often mixed together: code review, pair work, and line-by-line remote control.

Review is not remote control

Code review usually happens after a coherent change exists. A reviewer can point out risks, constraints, and omissions. The author still has to explain the reasoning and decide how to revise it.

Pair work is an agreement to solve a problem together. Driver and observer can switch roles. The point is shared problem-solving, not a permanent passenger issuing commands.

Line-by-line control is different. The task is formally assigned to one person, while every process decision remains with another. The implementer no longer needs to understand why. The job becomes predicting the next instruction. Even if the code runs, responsibility becomes blurry: whose design was it, and who owns the failure?

Choose the intervention point

A manager may genuinely have more experience and may already see a trap. But “I can correct this now” does not automatically mean “correcting it now is the best trade.”

Preventing an ordinary mistake may save minutes today. Letting someone run a test, read the error, and explain a trade-off can create judgment that survives into the next task. This is not an absolute rule. Data loss, security boundaries, and production incidents justify immediate intervention. Treating every implementation disagreement like an incident merely makes the team dependent on one always-available person.

I would rather define three things before work begins: what result counts as done, which boundaries cannot be crossed, and where the next checkpoint is. The person who owns the result gets to travel the path between those points.

The next time the urge to rewrite the second line appears, the manager can record the concern and wait for the agreed checkpoint. If the developer has already found and fixed it, the learning was real. If not, there is now something concrete to discuss. Help does not disappear. It moves from taking over every step to appearing where it is actually needed.

Source: Why does more control make a partner weaker and a child perform worse?.