How to prevent dictating the solution when tutoring

Question

My girlfriend is currently in her final year in college, and is following a first-years programming course, learning C++. The class is graded partially from homework exercises. She is struggling with them, mostly at a point "I don't know where to start" or "I don't know how to approach this." So I try to help her with that, but I don't want to end up doing her work for her.

One recent example was the introduction of classes in C++. They were supposed to create a class that simulated game of life. After pointing her to representing the world as a boolean matrix (array of arrays), the thing she got stuck on was printing the world (or a part of it) in the console.

So there are a couple of questions she might have:

• How do I do X? How do I create an instance of a class? How do I define a member variable?

These are all questions that would be easy to look up. As such I am hestitant to rightout give the answer.

• How would I approach this? How do I print the world? cout << world; prints the pointer, so what should I do instead? How do I account for the edge of the world?

If I were to directly answer these questions, I would essentially be making the assignment myself. So this is not something I want to do.

So instead I try to ask pointed questions, questions that should put her somewhere closer to the solution.

How can we print things to the console? In which direction does the cursor move? So where do we want to start reading from world?

I find it hard however to ask these questions clear enough to not get a puzzled look, but also vague enough to not flat-out give the answer.

Afterwards, I feel like I have essentially dictated the entire assignment. Additionally, I feel that if I were to delete the entire assignment, she would struggle very much to reproduce all of it on her own.

Question

How can I improve my help in such a way that I don't end up doing the assignment for her?

Answer 1

After I wrote what is below, I realised that most, but not all, of it is for her. Your role is to help her take on this practice, to stop her jumping ahead, and to slowly get her asking herself the questions.

Separate algorithm design and coding.

Help her to separate, designing the algorithms and programming. It is too much to learn a language and to learn to program at the same time (Even if the language is not C++).

To do this try physical and paper activities. E.g. for displaying the world. Walk it out. She is the cursor, see walks the path of the cursor placing sheets of paper (characters), on the floor.

Break the task up

• We need a 2d world. I don't know how to do that, but I think I could do a 1D world, and I think I could then build on that to make a 2D world. So I will create a model for a 1D world, and write a display method for it.
• Let me change the values in the model, does it display correct?
• What if I change the model after it is displayed? it should change the display. So do that.
• Now let me try 2D.
• That is the display (output part) done.
• That next.
• …

Ask these questions. On each question don't look ahead (don't try to do too much at a time). Get her asking herself what the next step is.

In general start with the output, then the input, then the process. (on more complex systems, you will not do all of the output first. You would do repeat { output, input, process }.

The difference between an expert and a novice is not that the expert can keep complex ideas in her head, but that they do one thing at a time, so only keep one thing in their head.

Summary

Repeat this 4 step process

• repeat until complete
  • Thing about what to do next e.g.
    • First it compiles but does nothing
    • Second displays 1 line of world.
    • …
  • Use a physical activity to design the algorithm e.g.
    • Embody the cursor.
    • Use a checkers board, or other objects to model the model.
  • Decide what done looks like (for this iteration only: e.g.
    • program compiles,
    • Computer displays -----*-----)
  • repeat until done {Write code, test}

Answer 2

Your strategy of asking questions, rather than just answering them is probably the right approach. But I would ask some questions first about her situation in general. This seems to be quite early for an assignment that has some complexity, both for understanding the requirements and for putting together a solution.

Is she missing some prerequisite that is either formally required or assumed? Is the prof making assumptions about the students that may not be valid? Is this her first introduction to programming?

Perhaps she just lacks some background that is needed here. You might need to take her back to some fundamentals about programming and thinking algorithmically. Solve some simpler problems with her where you can give more guidance as it isn't directly related to the course. You can also, in such a scenario, help her take a large problem and break it down into smaller problems that can be solved more or less independently as is done in Agile Software with product backlogs. Breaking down a problem into do-able parts is usually very productive.

It is also possible that you are the wrong person to tutor her. Personal relationships can get in the way of teaching. Perhaps she just depends on you too much and would do better if some other friend helped.

But in general, I think that asking questions is likely the correct approach. But one line of questions you might consider is "What have you tried so far?" and "Why did it fail?". You might learn a lot about what is blocking her, but more important, it may cause her to focus more on what she is doing and why.

You can also discuss how you would approach finding the answers to the questions she has. Where you would look and what you would do with the results.

Of course, C++ is a difficult language to master and has many pitfalls for the beginner. Even Bjarne Stroustrup once said that with "C" it was easy to shoot yourself in the foot, but with "C++" you could blow your whole leg off. If this is an issue, focus on the simplest and most straightforward aspects of the language so that the complexity doesn't become a burden early on.