Mentoring without taking over the keyboard

When someone is stuck, rewriting their code feels kind. It is also how they stay stuck. The skill they need is not the diff. It is the next decision.

I ask for the intent first: what should a user be able to do, and what already works. Then we look at one failure path together. Scope the session to a single outcome.

Reviews work the same way. Lead with the behavior that is wrong or risky, then the pattern, then nits. If everything is a nit, they will not know what mattered.

Pairing is useful when the blocker is navigation: where does this live, which API, which test. It is a poor default for every ticket. People grow when they leave the call with a map, not a merged branch they cannot explain.