Show your reasoning: thinking aloud when mentoring a developer

An experienced developer shares their screen, opens three tools, changes a query and fixes a slow page. The colleague watching has seen the steps. They still do not know why those were the steps worth taking.

That missing explanation matters. It is difficult to reuse a method when you have only seen its conclusion.

Thinking aloud makes some of that reasoning available to another person. Used carefully, it can turn a debugging demonstration into a mentoring conversation where both people can inspect the choices being made.

The UK Defence connection

Metacognition means noticing and examining your own thinking. A January 2024 Centre for Army Leadership discussion paper by Major Munish Chauhan explores this subject and describes thinking aloud as a way to make thought processes visible.

The technique has roots beyond the military, including education and psychology. This article is inspired by that leadership discussion, which represents its author’s views. The debugging session below is my adaptation for tech mentoring.

A practical tech example

For example, a developer is helping a junior colleague investigate a slow dashboard in a test environment. The page takes several seconds to display its data. The junior colleague suspects the front-end framework because that was the cause of a previous problem.

Rather than immediately opening the database tools, the mentor explains which possibilities they are considering and what evidence would distinguish them. They agree to investigate one request together, using approved test data and keeping credentials and customer information out of the shared view.

How to put it into practice

1. Agree what the session will teach

Purpose: Give the learner something specific to practise.

Choose a learning goal such as separating browser time from server response time. Ask what your colleague already knows and what they would like explained. Make it clear that questions and pauses are welcome.

Use a manageable task with room to explore. A live incident may require focused coordination and fast action; save the mentoring walkthrough for a suitable environment and time.

2. Explain the decision before the click

Purpose: Connect each tool to the question it answers.

The mentor might say: “I can see the page is slow, but that does not tell me which part is slow. I’m checking the browser’s network panel to see how long the data request takes.”

Then describe the observation: “The request spends most of its time waiting for a response. That makes me want to inspect the server request before changing the rendering code.” Explain unfamiliar terms as they arise.

Keep the narration selective. Your colleague needs the question, evidence and next choice, rather than a running commentary on every mouse movement.

3. Make uncertainty and changed assumptions visible

Purpose: Demonstrate how to revise an explanation.

Suppose the mentor expects a slow database query but the recorded query completes quickly. They can say: “That result does not support my first explanation. I’ll check what else happens during the server request.”

A later trace might show a repeated call to another service. Treat that as a lead to investigate, rather than instant proof of the cause. Explain what additional measurement would help.

Invite a different interpretation: “What else could explain the wait?” Leave enough space for an answer before supplying your own.

4. Hand over the reasoning

Purpose: Let the learner choose and explain a next step.

Ask your colleague to investigate a similar slow request. They can describe the question they want to answer, the tool they would use and the result that would change their mind.

Offer prompts before taking over: “Which part of that is an observation?” or “How could you compare those explanations?” If they get stuck, reduce the task to one decision and work through it together.

Do not make fluent narration a test of technical ability. Offer a written sketch, a diagram or quiet thinking time before discussion, according to what helps the person learn.

5. Capture a method they can reuse

Purpose: Make the next investigation easier to start.

Finish by asking your colleague to explain the approach in their own words. Record the reasoning pattern and a useful example, rather than copying a long sequence of clicks.

Agree a follow-up task where they can try the method with support available. At the next check-in, ask which evidence helped and where they needed a different approach. Confidence should grow alongside an understanding of when to seek help.

A record you can use

What to try next

In your next mentoring session, pause before opening a tool and explain the question you expect it to answer. Then invite your colleague to choose the next question.

If you are the person learning, you can ask for this directly: “Can you explain what made you choose that check?” You deserve access to the reasoning as well as the finished solution.

Source: Centre for Army Leadership, Leadership Insight No. 48: Exploring Metacognition (January 2024). The tech examples and working tools are Coded Female adaptations.