ICS 31/32/33 Lab Tutor Guide
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. You can also keep the instructors informed from the front lines about how the students are doing. Here are some guidelines; please let us know if you think of other things we should add. [You may find this most readable in a narrow browser window.]
- Before the quarter starts
During the first week
- Let the Tutor Coordinators (firstname.lastname@example.org) know right away of any change in your availability or contact information.
- Read these documents thoroughly; they state policies your students (and you) are bound by.
At every lab session
- Check your electronic mail frequently. We will announce meetings, schedule changes, new policies, and so on; your students will suffer if you don't have the up-do-date information. Get into this habit now, and keep it throughout the quarter.
- Meet the TA of your lab section. Make sure he or she knows that you're the official lab tutor and (if you have a split assignment) when you'll be there.
- Be on time. Students depend on having you there at the scheduled time. And don't cut out early.
- 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. Don't guess about assignment requirements; if you're not sure, check before giving students a definitive answer. This also models good behavior for students by showing them how to ask for clarifications.
- 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 unfriendly to tell a student, "I'm not even supposed to be here now," even if it's technically true. You may be able to do your own work with fewer interruptions in the Open Lab (ICS 364).
- 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. We don't want students to be able to say, "We couldn't get anything done in lab because we had to wait an hour to talk to the tutor." (Avoid even joking about things like only paying attention to the cutest students; some people won't take it as a joke.)
- Give students help, not answers. It's fine to tell people how to solve system-related problems or how language features work, 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 the web for reference, 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. Your class may expect students to use a "design recipe," writing out a function signature (input types and return type), purpose statement (docstring comment), and examples (in the executable form of assert statements) before they write any code; if so, tell them you can't help them if they haven't followed the design recipe first (though of course you can answer any questions they have on how to follow the design recipe).
- Encourage students to follow pair programming for assignments that require it: two people, one computer, one driver, one navigator, switch roles regularly. Make sure the partners are talking and changing roles, and that the less experienced students don't just sit quietly and watch. If they don't get into this pattern right at the start, it will be much harder to get them to do it later. If you see a pair member who seems disengaged, that's a cue that you can intervene to provide some help.
- Help students solve problems using what they already know. Especially in Python, there may be some advanced language feature or library function that solves the problem in a snap. But the goal is to promote their abilities with the basic features covered in class and the textbook. Covering advanced features too soon places too great a cognitive burden on the students.
- Find out what the students are supposed to know. To help students use what they already know (or are supposed to have learned), you have to know what that is. Most instructors have published course notes or a schedule keyed to a textbook; it's part of your job to keep up with these so you don't inadvertently tell the students something they're not ready for. A key principle of teaching introductory programming is that you can't teach everything all at once—you have to leave some things out or cover them later. It's the instructor who gets to decide what the schedule is, and the TAs and tutors need to be aware of those decisions and support them.
- 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 TAs and tutors need to make this clear to students, by explaining it in section 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 with their partner.
- Encourage students to post course-related questions on Piazza if you can't answer the question in person. With luck, they might get an answer before the lab session is over.
- Let the TA know, at least at the end of each session, what topics students are having trouble with.
- If you suspect cheating or other major infractions of University rules, contact the TA directly with as much hard evidence as you can; you should not attempt to handle academic dishonesty issues yourself.
- If an emergency keeps you from attending your scheduled lab sections, send Email to your section's TA and the tutor coordinators (email@example.com) as soon as you are able. We hope that real emergencies don't happen to you; your own midterms and class projects are not emergencies and we expect tutors to plan around their other normal acadmic obligations.
- 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.
- Post answers to students' questions on Piazza if you'd like to, but keep these points in mind:
- The whole class will read your response, including students who are less far along than the questioner (and those who are farther along). Be careful that your specific answer doesn't create more confusion among other students; qualify your answer so that it applies to the specific question.
- Stop short of posting actual solution code on Piazza. It's okay to correct a single line or two and it's okay to give examples of helpful techniques (in a context that's related to but not the same as the assignment). But students shouldn't be able to copy and paste whole solutions to problems out of Piazza.
- Unless you're pointing to something that already exists in writing (on the syllabus, in Email to the class, on assignment pages), never make any comments about the likely contents of an exam or about how scores or grades will be assigned. That's up to the TA (for the lab assignments) or instructor, and it's important that the instructional staff speak with a single voice on these issues. Don't assume that everything will be the same this quarter as it was when you took the class.
- Keep in touch with the tutor coordinators in person or electronically, even between meetings of ICS 193 if something notable comes up. The ICS 193 forum on Piazza.com is a fine place to do this. 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, firstname.lastname@example.org