Handbook for TAs working in the labs

Where to find course materials

General Notes

• Remember where the students are coming from.  If they are beginning 139 students, they may not have seen tools like StringTokenizer or printf.  When providing help, keep their perspective in mind.
• Help them to develop good coding practices.  Help with adding debugging statements.  Make sure that they have examples of what the program is supposed to do.  Make sure that they can articulate what they want their solution to do.  
• Recommend using the standards, and in particular, help them to do appropriate naming and indenting.  These will make their work easier, but they don't know that yet.
• NEVER TOUCH THE MOUSE OR KEYBOARD!  If you really need to type, ask the student to get up so that you can figure out what is going on.  Once you do, restore the program to the state before you started typing.

Lab Time

• You should sit in such a way that you can see the students.  Usually, TAs will sit at one of the workstations in the back of the room.  
• Your priority is answering questions the students might have.  While you can surf the web or check mail, your time in the lab really belongs to the students. You should do nothing during lab that will be distracting to the students.  
• If you don't know the answer to a question, don't hesitate to ask the instructor.  We understand that some of you are new and only just out of 159.  We usually will answer a TA question before going on to the next student.
• If you are new, watch what your instructor is doing and how they go about helping students.  Generally, we try to guide a student to figure the answer out themselves, asking them leading questions or pointing to something in the book.
• Don't let one student monopolize your time.  If it's busy, take the "One question and done" philosophy.  It's good to let the students spend some thought time on their own while they try to get it.  
• Be on time.  The instructor may go over general information and it's important to hear what they say so you can reinforce it when you get questions.
• If you can, check out the lab for the day before arriving in the lab.  If you see something that needs clarification or correction, let the pertinent instructor know.  This will save confusion in the lab.

Consulting Time

• Many days, the lab will be quiet.  On those days, you should try to code the programming assignments fclass.  This way you will have a good idea about ways of approaching the problem and can anticipate where the issues will be for the students.
• Put your name on the board and the class you represent.  That way, students will know who to try to find.
• Don't assume that students see the solution the same way that you do.  Help them to find solutions based on what they are thinking.  That means asking questions and listening.
• If they are having trouble designing solutions, you can help them walk through the design process.  Let them talk and write notes on the board.  Help them to see holes and flaws in their design (if there are any).  
• Don't code for them.  You can work with them as they are developing the code, but as they begin to code, walk away and let them work things out.  Help again if they get stuck.
• Watch out for unauthorized work between students.  In such cases, remind them of the rules with respect to PAs.  If it continues to be a problem, let their instructor know what's going on.  
• If the lab is busy, go to the "Take a number" system.  That way, you don't have to try to keep track of who's next and you can be fairer to the students.
• If the lab is busy, you must limit your time with each student.  Help a student with the immediate problem, then move on.  Don't let them ask questions about several different parts of the program.  Help them with the first one, and tell them that they should get that working before worrying about the next question.
• Always, encourage them put in appropriate debug statements to see what's going on in the code.  Most beginning students do not know where to look for the errors.  This is something that we really need to work with them on.  It's easy to tell them where the program has erred...it is harder to teach them how to figure that out for themselves.
• Be on time.  If you are going to be late, see if another TA can cover for you until you arrive.  Students get frustrated when they truck all the way over to the lab, only to find it empty.
• If you must miss a consulting session, try to find another TA to cover for you.  While you must keep to less than 10 hours per week, most of you will have some slack in those schedules.  Switch days, or simply take an extra session.  You do not need to let the instructors know of those other arrangements.
• If you must miss a consulting session and cannot find another TA to cover for you, see your instructor so that we can alert students or put a note on the door or Canvas. Use Piazza as well to alert students. If you miss because of an emergency, let your instructor know as soon as possible that you cannot come in or could not come in.
• Consulting hours adhere to JMU closings.  So, if school is cancelled due to weather or other circumstances, the lab will also be closed.

Timesheets

• Ms. Laycock will send reminders out when your timesheets are due, usually right at the 15th and last day of the month.  Be sure to bring those to your instructor for signature and get those into her office on time.  It is very difficult for her to process multiple timesheets for an individual student.  
• Keep track of your time.   Don't try to remember after the fact, because you might wind up shorting yourself for the extra time that you may have had to spend in the lab.  

Submit issues

• If there are issues with the submission system, get in touch with the instructor as soon as you know there is a problem or suspect there is a problem.  For the Linux submit, there are things we can look at remotely that may help identify the problem.  See Nancy Harris for Linux submit issues.