Mary Rose Cook

What I do when a student asks for help

For the last three months, I’ve been working at Makers Academy as a programming coach.

I spend part of my time working with students who have asked me for help. My goal is for the student to learn to learn. To improve my ability to help with this, I wrote down a process that I follow. The process has changed as I’ve learnt more. Here’s the latest version:


  1. Map the student’s request for help to one of the underlying problems:
  2. Apply one of the suggested solutions:
  3. Ask the student for feedback on my help.

Problems underlying a request for help

The student doesn’t have a clear problem explanation

The student wants a concrete piece of information

The student doesn’t know how to implement a piece of functionality

The student doesn’t know how to implement a piece of functionality, and neither do I

The student wants my opinion on their idea

The student wants an intro to a topic

The student has a bug they should be able to solve on their own

The student has a bug they don’t have the background knowledge to fix on their own

The student has a bug for which I can’t predict the likely cause

The student has a bug that will take them a long time to fix


Suggest the escalation process

  • Make the student feel held first. Then suggest the escalation process. (This link isn’t publicly accessible, I’m afraid. It points to an internal Makers Academy document. The document describes a process that helps the student help themselves. It suggests: gathering words to describe the problem, Googling, talking to a pair programming partner, and asking on the student Slack channel.)

Help the student clarify their explanation of their problem

  • Maybe ask them questions to clarify their request for help.

  • Maybe use 5 whys.

Suggest they Google it

  • Make the student feel held first. Then suggest they Google their problem.

Suggest the debugging process

  1. Tighten the loop. This means following the flow of execution to find the line of code that’s causing the bug.

  2. Get visibility (aka p everywhere). This means using stdout or a debugger to see the current state of the program.

Suggest reading material

  • Suggest a blog post. Or suggest a pill [an internal document that gives a condensed introduction to a topic].

Identify and train a developer skill

For example: diagramming, delegating behaviour, breaking classes into single responsibilities, debugging asynchronous code, 5 whys, falsifying assumptions, following the flow.

  • I can identify a skill that’s lacking by looking at how the student makes their request, how they’ve tried to find the problem and what solutions they’ve tried.

  • To set the student’s expectations, name the skill I’m going to help them train. Suggest they employ the skill to solve the problem. Name the skill at the end of the session to help them remember to use it.

  • Figure out how open the process should be. Maybe the first time that I suggest diagramming, I’ll need to walk the student through it. But, in the future, I should be able to give less detailed support.

Identify and train a developer behaviour

Solve their problem

  • If the student has a really tricky problem that will delay them for a long time, it’s often better to just solve it for them so they can get going again. Whilst keeping the process efficient, try and make it as open as possible. Try and explain how I know to try the things I’m trying.


Feeling held

  • Reassure the student that I’ve heard and understood their request. Reassure the student that I care about them and their request. This may involve explaining why I’m not giving them the answer.

Open process (vs closed)

  • An open process is one that helps the student to learn more than a closed process. For example, letting the student type, rather than typing myself, or saying “can you use the filter function for that?” rather than “type dot f i l t e r …”.

Subscribe to my newsletter to hear about my latest work