TA Duties

TA responsibilities for Prof. Reed's Courses

Here is a list of things I would like TA's for my courses to do. Some of these things will not apply in all cases, as the course requirements vary.

  1. Design short (~ 3 questions) multiple-choice student lab quizzes using Blackboard. Quizzes should be given at the beginning of each lab and should be closely be based on the assigned readings. If a student did the reading and paid attention, they should be able to get full credit. Quizzes should be able to be done 5 minutes. Quiz grades should be graded out of 10 points.

  2. Grade Programs

    • Programs should be graded out of 100 points using the guidelines given in the course syllabus and the criteria we will have discussed ahead of time. If a program is written well, don't be afraid to give a score of 100.

    • When you are grading programs, first grade 3 or 4 of them and bring them by my office so that I can give you feedback in regards to what I am looking for in each assignment.

    • In grading programs you must compile and run the executable from the course account, and provide specific written feedback connected to specific lines of student code. Students must know specifically why points were deducted.

    • When grading programs you must also run programs through Moss, the cheating detection system (or some similar system). More details on MOSS are given below.

  3. Programs and quizzes must be graded and recorded in the grades spreadsheet within 1 week of getting them. Updated grades should be posted every week.

  4. Grades information will be kept in an online shared spreadsheet.

  5. Keep 4 office hours / week & appointments with students. Have two hours on the day of your lab (sometime after your lab if possible), and two hours some other day. As much as possible, these hours should be on different days and times than those held by the Professor or by other TAs for the same course.

  6. Attend a weekly half-hour meeting with the professor and other TA's in the course. At this meeting we will discuss grading criteria for programs, as well as quizzes and topics for the following week.

  7. Attend midterm and final exams to help monitor the class. This is not necessary for classes smaller than 50 students.

  8. For introductory programming classes, be willing to give a lot of help, even suggesting specific code. Some students need more than just general suggestions in their first couple of programming classes.

  9. Regularly monitor the Piazza discussion board, answering student questions.

Instructional Labs

There are two “modes” in lab:

      1. Lecture: only 1 person talking at a time. Sign of success: it is quiet & students are listening. You should only use this mode at most to give a brief explanation at the beginning of lab.

      2. Lab: everyone talking at once, students working with a partner taking turns being driver and navigator. Start with the left student being the driver, then switch every 10-15 minutes.

      3. Sign of success: it is noisy and students are all engaged, working on the task at hand.

For hands-on teaching labs, a lab activity outline should be posted 24 hours ahead of time and should have a summary of what the lab is about as well as sample code, links for further help and some ideas of the type of questions that may be asked. This way students can generally prepare, even though they do not yet have the detail to do the actual lab. Then on the morning of the lab you should post the partially-completed on-line code for students to download and complete.

Each lab activity should have multiple stages to it, corresponding to the lab grades students can receive:

0: Did not show up or refused to work with a partner (unless TA gave permission for them to work alone)

1: Participated, but just got the most basic part to work

2: Participated and substantially completed assigned example

3: (Extra Credit) Completed the advanced part of the assignment

Labs should be designed so that almost everyone can get 2 points, but few will get 3 points. Only one of the students should submit the lab, with both of their names on it. In an ideal world you grade the labs on the spot as you walk around the room, and don't have to go back and grade them afterwards.

Instructions on using Moss to compare student-submitted programs

MOSS detects partial logical similarities between student programs using MOSS.

In order to use Moss, you first need to get a Moss account number, and then assign that number to the "userid" on line #167 of the moss script file downloaded from the webpage: http://theory.stanford.edu/~aiken/moss/ At the bottom of that page see moss.pl as an example of the moss script, except the userid is not valid.

  1. Register for a Moss account number:

Send a mail message to moss@moss.stanford.edu. Use "Moss Account" in the subject line to get the script with your userid in it. The body of the message should appear exactly as follows:

registeruser

mail username@domain

where the last bit in italics is your own email address.

  1. Get the script ready to run and the files in place to be graded:

    1. Paste the script into a file called moss.pl

    2. Change permissions: chmod ug+x moss.pl

    3. Download the source code for the project to be graded, placing it in the same folder as the moss script. Extract any zipped folders.

  2. Run the moss script to evaluate the C++ programs that are in that same folder. Type the following from the command line:

perl moss.pl -l c -b skeleton.c *.c *.cpp

where the -l option specifies the programming language, and -b option names a base file (e.g. skeleton.c). When a base file is supplied, the program code that also appears in the base file is not counted in matches. So, if you provide some sample code for students, you can put the sample code file as the base file.

Alternatively, after the moss script (moss2) has been downloaded, put all the files in a folder, put the MOSS script in that folder, and from a Unix command line prompt run:

moss2 -cc *.c

In this case the -cc means the "C/C++" language. You may need to open script in an editor and look for the list of languages and their options.

The Moss sever will then check all the program files supplied and show the results link when it is done. This usually takes 30-60 seconds depending on the number of files supplied.

Additional MOSS instructions [thanks to Aditia Mallavarapu]

To run the script, in the folder at the terminal type in the following:

./moss.pl -m 10 -n 50 -l cc -c 'prog1uic Iteration i' -d */main.cpp

where the options are:

-m : specifies maximum number of matches

-n: option determines the number of matching files to show in the results

-l cc: indicate language is c++

-c : option supplies a comment string that is attached to the generated report

-d directory where the files are. Here we are matching main.cpp from every folder.

If you are including the solution (in a folder called solution, for instance) you should call the solution code itself main.cpp

The script itself comes with instructions as well, in case you have further questions.