How to avoid getting emotionally attached to my students' projects?

Question

I run a workshop with a few students. They often do large projects alone that they inevitably run into trouble with. That's completely normal, it's why they need some help in the workshop.

As the instructor, I usually spot the issue and solution pretty quickly. I try and nudge the student in the correct direction, but they don't always get it. After a while, I become personally invested in the project, and I may end up just implementing the fixes I suggest myself (while they watch), and because they aren't responsible for the implementation, they gain less that than if I had let them do it. This happens especially when I help them with the initial design and architecture of the program, as I end up feeling a little like it's mine too.

How can I make myself pull back a little and not do the work for them?

Answer 1

I think this an essential and main part of teaching programming and cs (and teaching in general). The ability to hold the answer and guide the student to it.

What I do is try to follow the thought process of the student. When working with them to help them find the problem, I ask various questions (usually "what do you thing is causing this?" etc.) and by their answers it's possible to see what sentences would guide them to the solution.

This method works great (that sound out of the sky but it's based on student feedback) as it allows the student to feel that they found it on their own. I find that they also learn to spot issues on their own afterwards.

Additionally, it's worthwhile remembering that you are the instructor, and not the student. And that the project is a student's project, so keeping that in mind often helps with holding back from doing the work yourself.

However when all else fails, showing the students how you might do it could be a last (last) resort. Just be sure to explain every step you're doing, so that the student understands. I cannot express enough how bad this last resort is. But if it gets to that, make sure you're not doing their work, but rather show them something similar

Answer 2

While sometimes it may be hard to step back from a particularly interesting student project, you just have to remember that your role on the project is just as vital as theirs: A teacher. As a teacher, your job is to explain and teach so that they can actually create an implementation. Even though you don't touch the code, the project couldn't be completed without you.

It may also be helpful to step back during the design phase, because if you haven't been responsible for the design, you feel less like the project is your baby. Also, maybe start your own projects. If you are getting engaged in everything that your students do, then maybe you should become invested in some new project of your own to serve as a distraction from what your students are doing.

It is OK it guide the student to a solution, and even guide very closely. It's good to get the student to understand how their code could be better by simply asking questions about them. Questions are good, because they help the students understand what is going on and the help you as a tool to guide them. If you simply confine yourself to asking questions, even very specific ones, like "Why wouldn't you put the code between lines 23 and 27 into it's own method?", because that's better than telling them how to do it or doing it yourself.

It may also be helpful to you to remember that the maintainer of the project will be the student, and so they have to know how it works. If they don't, although the project may look good when it leaves your workshop, it will fall apart because the projects owner won't be able to maintain the code when inevitably it has to be changed.

Answer 3

Perhaps you can remind yourself by thinking of times that someone helped by not helping?

For example, when I was in college (30 years ago), I was struggling with a bug in the Lab (we had computer labs back then) and the TA could clearly see the bug but she did not offer any guidance. Because I knew she saw the problem immediately, I knew it was solvable. Because she didn't say anything, I knew she believed I could find it. It took a while, but I eventually tracked down a simple memory overrun error in C (wrote one past the end of an array on to the next declared variable). Silence is one 'guardrail' that I could go to.

The other extreme would be explaining everything to someone every time they ask. We call that "spoon feeding" and it is awful. The student learns... to be dependent, and I can't think by the end of the day and the other students are about ready to kill because they can't think during class either. This is more like "the third rail" so we won't go there.

I once TAed an introductory programming college class for non-majors. I very quickly learned to spot every kind of error they made. My goal was to stay between the rails: help, but let them learn. It is a difficult dance, and depends heavily on circumstances. Sometimes I give a generous prompt knowing that they are bound to come across the same thing again. I am not so arrogant as to think that I will determine the outcome of their experience.