As a tutor, should I encourage exploration at the risk of incorrect information?

Question

I am a junior undergraduate computer science student at a small engineering school. For the last term I have been paid as a teaching assistant for one of the more difficult courses in the CS curriculum. Because this is a small school, that means that I am basically a public tutor in our CS labs for about 10 hours a week and occaisonally help grade exams and assignments. I took the class earlier this year and did very well, but I am in no way an expert on the topic.

The largest part of the course is to write a small interpreter in Scheme. The students are given a starting point and are told conceptually how to implement most of the interpreter in the lectures, but the actual implementation is left fairly open. Because of this, there are quite a few valid ways to implement any given part of the project, and I do not think I could possibly learn all of them without dropping out of school to make this my full time job. The difficult part is that the advice I give to any given student depends heavily on how they have completed the interpreter thus far, and so I sometimes have low confidence that my ideas are correct.

I don't see a great way to avoid this without telling them to do it the way I did it when I took the class. I think that a strong point of the course is getting students to think about programming in different ways, and suggesting that my way is the best way seems to very directly contradict that. I also have low confidence in most of the students to tell me that I am wrong as they generally come to me at least a little bit confused in the first place.

As a paid assistant for our computer science department, should I encourage different solutions at the risk of incorrect solutions, and potentially at the risk of other students' grades? Or should I encourage solutions I am confident in at the risk of throwing out good ideas?

In the former case I don't feel like I am helping students in the same way that any of them are hoping for, but in the latter case I think I could just as well be replaced by a solution manual. I would like to nudge in the right direction as much as possible, but I don't always know exactly which direction is the correct one given several different thousand line projects in a single day.

Answer 1

Short version:

Encourage them, definitely encourage them.

Long version:

First of all I have to say that I am not familiar with Scheme, so in my answer I will assume an arbitrary coding project. Now, you have to consider that coding, especially a bigger project, is much more than just typing the code. As you said the class is quite difficult, I assume the students to have some experience already, so they should know it. Here, they can learn all the things that matter: A structured plan on what they want to code, good documentation of the code, time management, etc. Be honest about what you can and cannot do, tell them that you will not look at a few 100 lines of messy code to find an error. Tell them for you to read their code and to look for errors in there, they should properly document it such that it is readable and understandable to an outsider. Tell them to differentiate between logical questions ("how to solve this problem?") and implementation questions ("I have this idea/algorithm, but I don't know how to call function XXX, which I need to implement it." ). Not only will this help you with helping them, it will also help them to look at their problems more structured. If a student comes to you and simply says "I don't know how to do this, tell me please." then don't just tell them how you did it. Take a little time to make a plan (on paper first maybe?) together with them of how this part of the program might look like, how to best do it, then let them implement it. If they run into problems with the implementation itself, they can come back again.

The same should go for errors in the program: You should not be the one to run tests, to do simulations or to input special cases in every last function to find the error. Tell and teach the students how to find errors, show them how to (if possible) narrow it down to a single function, maybe to a single part of this function (a good documentation of what a function or a code fragment is supposed to do helps here). In most cases they will find the error themselves, feel happy and motivated and go on. If they still can't find it, well, at least they can show you the wrong output that function F generates and you can take it from there and point them in the right direction.

It would be nice if I could stop my advice here, but unfortunately there is still one more point: motivation. The above might work well with a motivated student who knows what he is doing, who sits down at home to work on it and comes to you for help if needed. However, this is not the only kind of student. There are also students who are in the course just for a passing grade, who don't go to the lectures, who just want a step by step instruction on what to do to not fail and don't want to put any effort at all. If you don't have any of these in your class then congratulations, consider yourself lucky. But if you want to try an approach as I sketched above, you should consider such students in the plan and should think of what to do with them: Do you just tell them what to do? Do you let them fail the class? These points should be discussed with the instructor, as he or she might have own ideas on what to expect of the students. You should not just act on your own, especially if you might fail some lazy students you need his consent. After deciding on a plan together, make it public to the students, tell them exactly what you expect of them to do on their own before they come for your help, how they should properly prepare their project for you to be able to answer efficiently.

Answer 2

If a student is implementing an approach that you are not able to confirm as sound or not likely to be successful, then you should direct that student to the professor's office hours (and you should give the professor a heads-up).

When a student approaches you with a debugging or other straightforward question in lab, you can take the opportunity to ask him or her, "Have you checked with Prof. X, to make sure you're headed in the right direction?"

If you were a graduate teaching assistant, I would go farther. I would say that you should anticipate these multiple approaches and, early in the semester, think about how you would respond to the variety of student questions, not hesitating to use the professor as one of your resources in your prep work.