You are sitting with someone who is stuck. You can see it. The problem is four lines above where they are looking, it is obvious to you, and you could fix it in ninety seconds. Your hand is already drifting toward the keyboard, or toward the button that requests control of their screen.
Leave it alone.
The moment you take over, three things happen at once. The problem gets solved, which is the only one you notice. They stop thinking, because there is no longer anything for them to think about. And they learn that when things get hard, the way out is to wait for someone more senior to arrive. That third one is the expensive part, and it compounds.
What works instead is a ladder of hints, and you climb it slowly.
Start with the area. I would look at how that value gets set. Then the tool. Have you put a breakpoint there, or printed it just before the call. Then the question that points at the gap. What do you think that variable holds at this point. Only if you are genuinely out of time do you give the answer, and even then say it out loud rather than typing it, so their hands are the ones that move.
Between rungs, be quiet. Ten seconds of silence feels like a minute when you already know the answer, and almost every person will start thinking out loud if you simply wait. Most of the value you provide in these sessions is the waiting.
There are real exceptions. Production is down, or the demo is in twenty minutes. Then take it, say clearly that you are taking it because of the clock and not because of them, and book fifteen minutes the next day to walk back through what you did. The rescue and the lesson can be two separate events.
One more thing. When they type slowly, or take the long route, or use a tool you would not have used, say nothing. Sighing at somebody's editor is a small act that costs you a surprising amount of trust.
You are not there to remove the struggle. You are there to keep it productive.
– Asael Shinder
