How to stop being The Oracle

Question

When I did customer service for an application I was developing, I found that most of the time, if I did NOT answer the phone, the user would figure out their problem and learn more than if I did answer. Some people would just call up any time the slightest thing happened, if I kept answering.

With students, when I am in class and they are working on coding assignments, the same thing can happen: they will ask any old question that pops in to their head because I am sitting 5 feet away (usually trying to grade assignments or prepare to lecture). Sometimes the questions are quite elementary. Other times, it amounts to structuring a complex If-Else or something that they could do, but they have difficulty with. The only 'help' I can give is to explain how it should function. They learn that way, but then I become the Oracle.

I do often deflect questions or look at the problem they are having to know that it is something I have taught and then say I need them to work at it a bit more, but this seems to happen a lot. If I was not there, they would be forced to work it through themselves. Is there a way to encourage the students to be more independent, because I have not found it yet.

Answer 1

Rubber Duck Debugging.

A few years ago we bought a bunch of cheap rubber ducks. Students with questions have two options. They can either ask their neighbor or explain to the duck what they're trying to do. If the duck didn't help, then they can ask me.

I've moved to a different school since then and haven't bought any ducks. I really need to buy some ducks.

Answer 2

(You didn't say what ages your students are, so this answer is necessarily a little nonspecific. There is also an article here that you may find helpful.)

First and foremost: don't expect total victory in this regard. Your students ask you because it is frustrating to be stuck, and it is perfectly natural to try to find the quickest path out of frustration.

If you want them to take another approach, you may find it worth your time to invest some actual classroom time in teaching how to debug. One way is to get "stuck" while coding in front of the class, and then go through the process of debugging it. Very carefully model the behaviors, then stop, and ask the students to reflect.

"Why didn't I just ask the teacher for help? Oh, right, I AM the teacher. So, why didn't I just give up? What strategies did I actually use to uncover the bug?"

A second approach could be to celebrate very visibly when a student debugs on their own.

"Hey everyone, so-and-so was just stuck, but he didn't let that stop him. So-and-so, can you tell the rest of the class how you went about solving your problem? What did you try? How did you do it?

If this happens semi-regularly, and you continually emphasize fix-up strategies, you may make some meaningful headway.

A third approach, which is more forceful, is to use a page (like this or this) with multiple timers. Students who have a question for you don't necessarily get you. Instead, you simply set a timer. (Having a second monitor display to a projector would help with this approach.) Only if the timer reaches 5 minutes and the problem still isn't solved can they ask you for help.

Answer 3

Students will act according to the habits they have built up. The one they have isn't terrible, but you can work to improve it. This answer won't save you much time, initially, but if you can change the habit then everyone wins.

When asked a question you need to find a way to get them to respond first, somehow. There are various possibilities. The classic way is mentioned elsewhere here - ask them what the tried already. Their response needs to come before yours. If they have nothing to say, just tell them to think about it until they have a failed solution they can discuss, preferably along with the reason it doesn't work, as they view it.

But a simpler and more devious solution is just to turn it around. When asked "How can I do wxyz?", respond as follows: "If I just asked you the same question, how would you begin your answer?" They don't need to say much, just the beginning. It may be enough to trigger their own knowledge, but it may also help you see their block and give them a minimal hint to continue.

The keys here are "you (i.e. student) first" and "minimal hint".

If they know that you won't save them a lot of thought and work that they can do themselves, maybe they will be more proactive about their own solutions, but the habit needs to be built. Work on that part.

---

Let me note that the problem expressed in the question can arise in a variety of contexts, not just students working in a lab. The solution isn't really to help them learn how to debug, but rather, how to think. Especially, how to work through any problem as it occurs.

Answer 4

It sounds like you don't want to deflect them when they need help but would like them to become more self-directed and learn to solve the "easy" stuff themselves. One teaching technique that I have found useful for this, no matter the subject, is questioning.

It is relatively easy (once you become practised with it) and allows you to help the student as well as encourage them to think for themselves and become more self-driven over time. (Yes, there are always exceptions.) Essentially, as the term suggests, it involves asking the student to provide answers by asking useful questions, thereby teaching them how to work it out for themself.

How you apply it (in your own style, that is) is something you need to discover, but it can be from the simple:

Student: What's a string?

You: Do you remember when we covered types like strings, integers, booleans...? (you've given them a context and the chance to make some connections)

Student: Aaahhh.... Oh yeah, never mind.

Or maybe they have a mental blank, or missed that class:

Student: Nope.

You: (Count to at least 5 before you say anything to give them time to think.) You know what an integer is? (Yes/no/maybe) So...?

And if they genuinely don't know:

You: A string is ...

And you've covered more than they asked and (hopefully) they feel they've learnt something and not made fun of.

Or for structuring a complex If-Else:

Student: How do I do ...?

You: Have we done one of these before? Yes? Do you have the example there? So, this is like a question, if something then something otherwise - that's else ... So, what's the if part in what you have there? And then...?

It takes practice, and can work well. With this I've had student feedback that ranged from, "I really like the way he teaches us how to figure stuff out", to, "He never answers any questions." So YMMV. But by being positive and helpful you both get more out of it than by deflecting or just telling them the answer.

Answer 5

The best thing they can learn from you is not a memorized answer - it's the process by which you solve problems. Instead of giving them the answer, instead of telling them to go find the answer themselves, walk them through the process of solving the problem, step-by-step. It takes more of your time initially, but they'll be stronger coders over time.

For example, "How do I sort a list?" Of course, there are many possible solutions, but pick one consistent with their level of understanding and with the class. Then, walk them through it. "What if the list just had two elements?" "What if we repeatedly broke the long list into smaller lists?" Or something along those lines, depending on the way you approach the solution.

Answer 6

Think through how you debug, and try to make it as explicit as possible. Make up a check-list. When students ask you for help, quiz them about what they did regarding the items on the check-list. "Did you look up the documentation?" "Did you write up your best guess and run it, even if you thought it would fail?" "Did you look for an example of code that does something similar?" "Did you check what the shape and contents of your variables are?" etc. Have them work through their problems with each other.

Other times, it amounts to structuring a complex If-Else or something that they could do, but they have difficulty with. The only 'help' I can give is to explain how it should function.

If you try hard enough, in many situations you will be able to give them other help. Ask them to explain their thinking, what the code so far does, what happens with a sample input, etc.

Answer 7

I tell my students if they want to ask me more than one question a day, I am going to start asking them two questions before I answer them. 1) What have you tried. 2) Who else have you asked. If they cannot answer those two questions, then they are not ready to have their own question answered. It makes it harder for them to get away with using you as a crutch, and 90% of the time they try something and figure it out on their own.

Answer 8

Set up a class forum for your students

It's a pretty standard thing for online courses that there is some form of online many-to-many communication platform that students are required to participate in as part of their grade. I've had to do it on two or three occasions, and while I hate it, it's what takes the place of "class participation" in the brick-and-mortar classroom setting.

I suggest setting one up (they're pretty cheap and easy to manage, and you can wipe it between years pretty much at the click of a button; heck you might even want to look into Stack Overflow Channels). You don't have to make participation mandatory, but you can tell your students "if you need help with a problem, post on the class forums. Browse other student's questions and help them out." If it isn't mandatory, you can offer a few points of extra credit.

The number of times I've written up a problem and gotten ready to post it to Stack Overflow (or other online community) I've realized "Dang, what an idiot I am" and solved my own problem.

It's a variant of Rubber Duck Debugging, which Ryan Nutt has already answered with, but in the case that simply trying to explain the problem it isn't solved, its there for anyone to answer. Just don't forget to look through the board yourself and answer a few questions. ;)

Answer 9

Randomly be "too busy with something" for a few minutes, but say you'll get back to them. Then set a timer, and then check with them some number of minutes later. Reward them (somehow, depending on age group, etc.), publicly if possible, if they figured out all or part of the solution themselves.

This allows you to provide help (for issues where you really are the expert "oracle") while also giving random intermittent reinforcement (the best kind) for them figuring out the problem themselves. (Note: this works for co-workers as well as students.)

Answer 10

I have been considering the issue of educating programmers for years, and discussed it with others. My personal experience of learning programming was that over 4 decades, I learned along with the changes in computer science and technology. So when I need to learn something new (in order to teach it) like C# and ADO.Net and the massive complexity of Visual Studio, I have a lot of context for each thing I learn. It all makes some sense to me, sooner or later.

But taking adults who have never programmed at all, and plopping them in front of Visual Studio, then teaching them C# via Console mode programs, then Object Oriented principles, then Windows programming, then ADO.Net, with databases design and SQL woven in, in one year... I think that probably this is a very steep road for anyone. It took me 40 years to get here (although I did other things in the meantime), and I wonder if we have grown our 'stack' of technologies so high that most ladders no longer reach the entrance? A colleague says that in the near future, only the "whiz kids" will have any hope of becoming programmers. I reply that AI will make it all obsolete anyhow, so no worries.

In light of that, I face a choice when I teach: answer questions about scenarios bristling with options, techniques, procedures, practices and tools, or let the student probably waste a lot of time and get very frustrated to no good end. I usually just point to the appropriate places on their screens and explain the steps (again) hoping that with repetition, they will get it. I don't know what else to do in this situation. What worked when I was a TA of an intro programming course for non-majors 30 years ago would be useless today.

Answer 11

It's very simple but it make your students hate you. Ask them to do it on their own, using the materials you provided in class. For each question that they ask you, deduct a point. If they care about their grade, they will try to ask you as few questions as possible or will seek help from each other, both beneficial outcomes.