How to Be a Good Lab Tutor
  

Your work as a lab tutor for first-year students in ICS can make a big difference: You can help them learn the material, lessen their frustrations, and make their lab experience a positive and productive one. Here are some guidelines.

Before the quarter starts

Give your e-mail address to the instructor of the course you're tutoring for. That's the best way for you to get course announcements, so you can stay informed about what's happening in class.

During the first week

Check your e-mail at least daily for announcements of meetings, schedule changes, new policies, and so on. Get into this habit now and keep it throughout the quarter.

At every lab session

Be on time. Students depend on having you there at the scheduled time.

Make yourself available to the students: Even if the students all seem busy, don't read your own e-mail, don't IM your friends, don't make cellphone calls, don't do your own classwork, because students will hesitate to interrupt you. When you're in the lab, you should circulate around and help students, not simply wait for them to call on you. Don't get so deeply involved in conversations that you don't notice when students need help; you should cruise around the room at least once every five minutes. Whenever you're in the instructional lab, you should be prepared to answer students' questions courteously, even if you aren't officially on duty at that time. It's insulting to tell a student, "I'm not even supposed to be here now," even if it's technically true. You may be able to work with fewer interruptions in the Open Lab (ICS 364).

Be prepared to answer students' questions. Presumably you already know the subject matter, but you must also know the assignments. The only way to do that effectively is to read them carefully in advance and, where possible, try to work them out. If a student asks whether something is important or required, you want to be certain that you're giving the right answer (and check with the TA or instructor if there's a question that the assignment writeup doesn't answer clearly): If you give a wrong answer on something like this, the student may be graded down, and that's not a happy situation.

Give students help, not answers. It's fine to tell people how to solve system-related problems, but you should lead them to their own solutions of programming and CS problems. They shouldn't become dependent on you; they should learn how to use manuals, extra print statements, and execution traces for themselves. Be pleasant but ruthless about this. Students will beg you for a quick-fix answer, and it's easier for you just to give it than to point them towards finding the solution themselves. Nonetheless, resist the temptation, because students will come to expect you to fix their problems for them. In the long run, that hurts both them and you.

Don't feel guilty if you can't immediately identify the student's bug. While most of us can see bugs quickly for the early, trivial assignments, that may lead students to expect (unrealistically) that we'll always be able to find and fix their problems at a glance. Of course nobody can do that for significant programs, and tutors need to make this clear to students, by explaining it and by encouraging them to find their own bugs by adding extra print statements and tracing their code. (You may have to show some students how to do this step by step the first time; not everybody knows how to debug instinctively.) If a student objects to the painstaking work involved in such tracing, remind them that they can minimize the need for it by spending more time in the design phase.

Remind students to prepare for lab by reading and thinking about the assignment beforehand; they should be ready to work when they sit down at the machine.

Spread yourself around to everyone rather than concentrating on just a few. If many people want you at once, leave the current person with a task to do independently while you make the rounds. Make sure each student gets at least "first aid" help so they can get back to work; after that, feel free to spend more in-depth time with students who need it. (Avoid even joking about things like only paying attention to the cutest students; some people won't take it as a joke.)

Encourage students to follow pair programming for assignments that require it: Two people, one computer; one driver, one navigator; switch roles regularly. If you see a pair member who seems disengaged, that's a cue that you can intervene to provide some help.

Encourage your students to send e-mail about course-related questions that you can't answer on the spot. With luck, they might get an answer before the lab session is over.

Other advice

Students with no previous experience often feel intimidated by the more experienced students, especially in the early weeks when they still need to learn the system and they see the experienced students furiously typing away. Be sure to encourage the novices to start early and ask questions; reassure them that their difficulties are normal and help foster their feeling that they can complete the work and do well.

Very experienced students have other problems: Often they think they can wait until the last minute to complete assignments; this may be true for the first few assignments, but significant programs take substantial time, even for people who understand the concepts. Experienced students also may not be used to following rigid specs imposed by someone else. Recreational programmers can just change the requirements, but our students have to solve the hard problems rather than working around them.

Tutors can't be paid for any work they do until their employment paperwork has been completed, approved, and processed; check with Carol Rapp (rapp@ics.uci.edu) for the precise date. Tutors should submit their time sheets to the instructor for signature. It's particularly important that your time sheet reflect any days you missed or showed up late; if your time sheet claims time you weren't actually there, the university thinks you're trying to cheat it out of its money and gets seriously upset. Tutors are hourly employees; we try to keep the hours per week consistent, but there may be fewer assigned at the start of the quarter and more near the end or near important due dates. Tutors aren't guaranteed a specific minimum number of hours; you get paid for the hours you are actually assigned and actually work.

Keep in touch with the instructor in person or electronically. Let us know how things are going, and especially if anything's going wrong. It's much easier (and more effective) to correct problems early, before they get out of hand. Lab tutors especially are on the "front lines" dealing with students' difficulties; we need to know what those difficulties are.


David G. Kay, kay@uci.edu