Demonstrator Guidelines

When you are supervising labs, you are there to help the students with their lab work. Helping does not mean that you complete the exercises for them. In particular:

• Do not make students dependent on you; you are there for emergencies only. In any case, try to train the student so that they can help themselves the next time.
• Explain to them how to interpret error messages from the system, so that they will be able to understand the next one themselves.
• Explain to them how to find bugs in their programs. Sometimes it is inevitable that you will hunt the bug yourself, but even in that case explain how you found it. Both the ability to read error message and to find bugs in programs are important skills that students need to acquire themselves.
• Do not answer questions if you can avoid it! Some students ask questions because they cannot be bothered to read the textbook. Tell them to read it. Some questions are best answered by a question from you, which will cause the student to come up with the answer.

  As an example, suppose a student asks you ``How do I use a 2-dimensional array?''. You could either tell them ``a[i][j]'', or you can ask them "How do you use a one dimensional array?" when they tell you ``a[i]'', you ask them "So how would you change that to become two-dimensional?", in which case 9 out of 10 students find out for themselves.

• Keep an eye on weak students. If you think a student does not have a clue, send them to the lecturer. Do not allow a weak student to plod on, and certainly do not give a weak student part of the solution to the problem.

The students will have an exercise for the lab. Often there are many different solutions, but only few of them are `right', that is, they use the particular style that the lecturer is teaching them. Please make sure that you know the model answer, and that you steer students in the right direction.

Procedures for lab supervision

• Make sure you are there on time, lab sessions start on the hour, not ten minutes past. Stay for the whole session, if it's a very long lab (> 3 hrs) agree with the lecturer and other demonstrators when to take a coffee break.
• Set a good example: don't eat and drink in the lab.
• If you are ill make sure that the lecturer or Departmental Administrator is informed so that we can find a replacement.
• Be pro-active in the Lab. If things are quiet ask students how things are going; many will not always ask you when they encounter difficulties.
• Make sure you don't spend all of your time with one student. Force yourself to go to another student now and then. If a problem is so great that it would take you a long time to explain, simply refer the student to the correct part of the textbook, handout, or the lecturer's office hour(s).
• If you have difficulty finding a bug, ask one of the other supervisors to take over, someone else with a fresh view might find it quickly. You can go on to some other question (don't wait!)
• There is plenty of documentation on the web. Simple questions about C, Haskell, Java are answered on http://www.cs.bris.ac.uk/Teaching/Resources/General/. You will also find an intro to Solaris, C etc.
• If exercises need to be ticked off, make sure that at least one of the supervisors is available continuously near the end of the lab session to mark exercises are finished.
• Document any faults with the SUN Workstations / Linux PCs.
• Ensure the aisles are kept clear of chairs especially around the Fire Exit. To help with this, there will be a minimal number of spare chairs in the lab.