Assisting students with large programming assignments takes too long in class

Question

In university, I was a student in an operating systems programming course in C. Assignment help was offered in tutorials. Students would usually present the tutor(s) with run-time errors and an enormous amount of code. The tutors took 20 minutes to figure out the mess and offer help. In a 50 minute class of 30, most students went neglected, while some scored private tuition. Assignments were large and students were forbidden to view each other's code.

This was a serious problem. What could teaching staff do to address this?

Answer 1

The problem, in my view, is a misplaced assumption that students should never see one another's code and that seeing it would somehow or other "pollute" the student's mind in some way or make grading invalid.

A clear solution, provided that you can give up that assumption, is to have the students work in pairs in the tutorial, giving help and advice to one another. A more radical approach, that I also favor, is to have students work together to develop the code in the first place.

It has been observed (I have seen the video) that when students work together they seldom need outside help and call for tutor help only rarely. When students work alone and wait for the tutor they are mostly idle while waiting.

The reason for this is that, while both students in a pair may have problems, they seldom have the same problems and so can support one another's learning. When a tutor's help is needed, there has already been a deeper analysis of the issue at hand, since there were two minds working on it.

If you worry less about grading, and less about some students "slacking" you can do a better job overall, especially for those who are interested in learning. Students can learn from one another. It isn't essential that they learn only from the instructor.

---

My experience, also, is that when a "better" student helps another, both benefit from the experience. The helper gains deeper insight by having to verbalize an understanding that may be only partly formed.

When abrasive personalities get in the way of pairing, the one that is abrasive needs to learn better behavior in any case if he/she is to be successful in the long run. Instructors need to watch for this, of course, and offer advice as needed.

Answer 2

Smaller Chunks: Students should be working in smaller chunks of code.

• They need to write as small a chunk as possible (one function or even one line of code), then compile, run, and test that. This process should be introduced as early as possible and enforced as much as possible- for the sake of the sanity of everybody involved.

• Students should not be writing an entire application or feature and then having no idea why something isn't working, or why a runtime error is occuring. This is a common pitfall for novices, and it's a habit they need to be broken of as soon as possible.

Debugging: Students should be debugging their code before asking questions.

• When they encounter an error, their first instinct should be to debug their program to get more info about what's going on. Have you taught them how to read a stack trace? How to trace through code with a piece of paper and a pencil? How to use a debugger?

• The goal of debugging is to narrow the problem down to a single line of code, or as few lines of code as possible, that are exhibiting an unexpected behavior. "I tried X, expected Y, but got Z instead" is a much easier question than "this isn't working".

• Debugging is much easier if they're already working in small chunks of code!

Isolating: Students should be isolating their problems into smaller example programs.

• Now that they have the problem narrowed down to as few lines as possible, if they still can't figure it out, then they should be isolating the problem in its own standalone program. This involves starting over with a blank program and only copying over the lines of code that are directly related to the problem.

• Stack Overflow calls this a Minimal, Complete, and Verifiable example. Other places call it a Short, Self Contained, Correct (Compilable), Example. Sending out these links to students might help, but the idea is that they should be coming to the teacher with an isolated example problem, not their whole project.

• This is a much easier process if they're working in smaller chunks and debugging their code!

• This also prepares them for real life, where they'll have to formulate questions for their coworkers, and for Stack Overflow or other online forums.

For example, if a student has written their whole project without testing it, and wants to know why something isn't working, then the answer could be that they need to start over and only add a few lines of code at a time, so they can test it in small chunks like they should have from the beginning. Or if a student wants to know why a function isn't working, then the answer might be to ask them which line of code is behaving differently than what they expected. If they don't know, then it's time for the student to break out the debugger to narrow it down.

It's up to the teacher how strict they want to be about the above rules, but at a bare minimum, teachers should spend some time really explaining the first two points. Coming with a "question" about 100 lines of code that you haven't debugged at all is a non-starter.

Answer 3

It sounds like the students were not really ready for these assignments in the first place. If students are coming with runtime errors (instead of logic errors), then they are not testing their code well as they write. Helping students debug their code is a band-aid on the larger problem that the students do not know how to organize and test their code.

My first choice would be for the professor to offer an emergency session on some basic Software Engineering practices, ideally before the assignment has even begun.

However, if I were in the position of the TAs (and could not modify the assignment), then I would consider the situation a mini crisis, and I would have to act as a First Responder. I would send out an email to this effect:

Dear class,

We have noticed that many students are having trouble with the latest assignment and have been asking for help. That's okay! That's what we're here for.

However, much of the code that we have been seeing has been poorly organized, and as a result, it has become impossible for us to help everyone in a timely manner. In order to help us fix our timing problem (and, honestly, to help you fix your code before you even need to come to us) please make sure that you have placed a comments on the top of each method in your code that contains the following:

1. A short description of what the method is meant to do.
2. A list of all of the test cases you have tried for this method, and an indication of the results returned.

Doing this will help you spot your own errors, and will make it substantially faster for us to help you in case you are still stuck.

Thanks,

The TA Team

Answer 4

As @buffy @BenI said. In addition:

• Allocate shorter time slots.
• Have names in a queue on a white board.
• Students can move up the queue if they help someone else that is in the queue (take there place).
• Have an entry criteria:
  • Able to state:
    • what you are trying to do
    • what you expected
    • what the inputs are
    • what went wrong
  • Code uses good name, and is easy to read. ( Better names are better than better comments. But comments where necessary.)
  • Have them code one thing at a time, and test it: test first.
  • Have them use revision control, and be able to answer “What has changed since the last time it worked?”
  • Stop the class for an emergency mini lesson, if you see several of the same problem.

You may use your time to help them meet entry criteria, or hand them to a minion, or give them a handout. However you will only do this, and not deal with the problem, in this time slot. They must re-join the queue.

Answer 5

The others answers are very good.

I'd like to add to them some practical advice for the tutors.

Raise the standards of what an acceptable questions is. Much like over on Stack Overflow.

If a student presents an error along 500 lines of code that might or might not be the cause they should be told to look for the line of code where the error occurred and ask again, if at that point they still don't understand the nature of the error.

Most will find a solution to the problem on their own this way.

This however would require the students to learn some basic debugging skills. So instead of helping 3 out of 30 students untangling their code, teach all of them basic debugging skills on examples.

It would also require some discipline on the tutor's part, to ignore too broad questions, along with the proper advice to isolate the error.

Answer 6

The tutors took 20 minutes to figure out the mess and offer help. In a 50 minute class of 30, most students went neglected, while some scored private tuition. Assignments were large and students were forbidden to view each other's code. This was a serious problem. What could teaching staff do to address this?

You've inherited the mess that no one else wanted to bother with, and you're stuck with students that don't know how to perform basic debugging and self-testing.

So you can either work on teaching them basic debugging skills, or work with the hands you have available. I would say the choice heavily depends on the students you're working with. You might end up with a class full of people who don't know jack about debugging, or vice versa; YMMV.

You'll anger some of your more advanced students if you spend a day going over just debugging, but if you do it in a way to where your lesson of the day focuses on debugging a kind of obscure issue(s) where error messages prove less helpful, you can show students how to perform basic debugging skills where the error messages aren't the reliable source of truth, forcing you to go line-by-line for in-depth analysis, and likely doing things like cross-referencing documentation.

Do this with class participation and maybe even introduce things as low-level as memory-inspection and traversal, and you'll be surprised how many debugging issues your students will start squashing on their own.

Their co-workers later in life will thank you in-spirit, even if they don't know you :)

ps: If you're in charge of when assignments are due, shoot for either EOD or first thing in the morning, just like work would be. Coding classes that require students to learn a concept and flawlessly code it and turn it in with limited/no help is pretty, um... poorly thought out, especially given the question's original scenario. The only time you're pushing out code that quickly IRL is for emergency hotfixes, which isn't something your school should be expecting as the typical MO for handling assignments.

Answer 7

You should consider "Pair Programming". I know many answers above does talk about working in pairs but the details are important: "Pair programming" has rules of how to do it and is used in the industry and in education.

This article from Khan Academy is a good starting point on how to implement pair programming in the class room

I used to have the same issue as you and pair programming definitely improved the situation significantly. The key to success however is to follow the rules. a) They have to switch at given time b) They have to use one computer c) It is a good idea to have random paining beginning of each class.

When I teach I usually have 35+ students in a lab, when I applied pair programming I was able to assist them better especially when adding the random pairing. They explain to each other and you only end-up needing to help a pair who is stuck.

Funny that this also has proved better than having a lab assistant (if s/he is not my previous student) since in some cases I (and the students) end-up teaching the assistant instead :-)