Pairs(2)
CS 100 and Pairs Programming

Overall, we're looking at a likely increase in enrollment in the course, and a decrease in the number of GTAs available to help with Computer Science labs.  Our courses are taught by faculty:  GTAs commonly help with courses that have scheduled labs (probably about 70% of our GTAs), less commonly with programming courses which do not have scheduled labs (about 20% of our GTAs) and non-programming courses such as discrete structures which need homework graders (about 10% of our GTAs).  For the 2007-2008 academic year we had funds for 33.5 GTAs plus some additional tuition waivers so that we could do GTA/GRA splits.  For Fall, 2008, at least 4 of these positions will fund CpE GTAs.  The College of Engineering at UTK has been working with various formulae for the allocation and reallocation of GTAs:  Computer Science (from its time as part of the College of Arts and Sciences) has been generously endowed in terms of GTAs, and it now seems inevitable that the number of GTAs available for CS courses will be substantially less than it is now.  If, say, for Fall, 2009, Computer Science has only 20 GTAs, then the question will arise as to how those GTAs will be assigned.  There are faculty members who are not enthusiastic about having the Computer Science Department teach service courses (such as CS 100), and at this time, CS 100 is the only service course in the College of Engineering (the college has some general-purpose courses such as Engineering Fundamentals 105 that are for engineering students, but which are not intended for students outside the college).  In the past year, CS 100 was allocated 7-8 GTAs for 150-190 students:  I would not be surprised to see an allocation of 5 GTAs for 250+ students in the future, and even that number might be generous.  So this has been one of my motivations towards pairs programming--can we manage more CS 100 labs with  much less GTA support.

My second motivation towards pairs programming in CS 100 has been to create an atmosphere in the labs that is conducive towards retaining the students who are taking the course and in attracting other students as well.  There has, in the past, been a significant drop-off in attendance during the semester, particularly with the labs that involve Python programming.  These are non-majors, and most are not particularly inclined towards learning to program.  Creating their own web pages is enjoyable, but programming has been a problem.  In the past, with students working on their own to do the lab assignments, 3 GTAs were kept steadily busy with 20-30 students raising their hands with questions.  This does mean that even with 3 GTAs, the response time often left something to be desired.  Laurie Williams has video clips of a lab with only 1 GTA available:  frustration increases to be point of students getting up and leaving the lab when the GTA response time was poor.  I want to do everything I can to avoid such a situation--it's bad for student morale, bad for the course, GTAs, and faculty.  What we have found is that with pairs programming in CS 100, 2 GTAs for 20-30 students in the labs give an excellent response time.  The number of raised hands is perhaps 25-30% of what you might see if all students had to work on their own. 

At this time, the lab for the CS 100 students has 30 PCs running Windows XP.  The machines are not the latest.  CS is primarily a UNIX/LINUX shop:  our servers are LINUX, and there have been some problems running the PCs off LINUX servers (the H drive on the PCs is actually on the LINUX servers).  Login times can be slow--several minutes is not uncommon.  There are issues with web pages (which are on LINUX) since the LINUX servers need protections/privileges set, and Windows XP does things very differently.  At this time we have 3 labs--one for CS 100, etc, with 30 PCs running XP, and the other 2 with 30 machines each running Debian LINUX in Spring 2008 transitioning to Ubuntu for Fall, 2008.  By Fall 2010 we will probably be in a new building, with a single lab with 50 machines.  The labstaff would like to switch the XP machines to Ubuntu--this is something I will have to look at carefully.  There are lots of benefits, but also plenty of drawbacks.  The CS 100 lab has tables with 3 chairs, 3 PCs per table.
This is not the way I would design things from scratch for pairs programming (for the same space, a table with 2 PCs and a table with 4 PCs for each row would be preferable.  It's an inconvenience, but not a crucial problem.    We have a PC in the front for the GTAs and an overhead projector--this is helpful when it comes to demonstrating things in the lab.

Traditional pairs programming involves rotating groups each week, and during the lab, the roles switch at regular intervals between the "navigator" and the "driver".  What I have done is that in the early labs in CS 100 we try to have groups rotate.  My overall goal has been to create a non-threatening atmosphere in the labs--some of the students begin with good computer skills, others are computer-illiterate, and often are embarrassed about asking "dumb" questions.  The latter are the one who need CS 100 the most, but who in the past have often been the first ones to drop out.  Students are usually much more comfortable asking questions (especially "dumb" questions) of other students rather than GTAs or faculty.  So I want an environment where students can interact all over the place--where they can get to know each other, and sit down with almost any other student.   Students do not all start the labs at the same time--some come in early, others drift in late.  We also allow students from other lab sections to join in (with preference given to students who are scheduled for the lab)--sometimes students have a crisis, are sick, etc, and have to miss their scheduled lab.  For Spring Semester 2008 we had 7 2-hour scheduled labs a week, so we try to be as flexible and as congenial as possible.  By the 6th or 7th week, some students regularly have different partners each week.  Some have regular partners whom they feel comfortable with, and a few like to work on their own.  Those who do like working on their own can always at any time join others, talk with others, and get any help they would like.  With students drifting in late, we often see some groups of 3 working together.

My announced policy for Spring, 2008, based on problems during Fall 2007, was to announce on the syllabus that if a team member's name was not explicitly part of the lab (in the documentation, etc), that ALL members of the team (not just the missing person) would lose 10 points on the lab--this avoided the problems on the fall where a student claimed to have been part of a team, but their name was not on the lab--we spent too much time dealing with such headaches.

We do not require regular switches between "driver" and "navigator" (in part because the login process can be maddeningly slow at times).  We have found, nonetheless, that the team members all seem to actively participate.  One of my assignments--lab 1, actually, which starts after only 1 classroom lecture--is to have the students start their web pages.  There are no joint webpages (unlike, say, Excel labs):  each student designs his/her own web page.  But they work in pairs (a few triplets) and so each will be at his/her machine, talking back and forth with their partner, concentrating first on one person's work, then the other.  One student, for example, has found some nice background patterns at a web site and the other student (who has been experimenting with solid-color backgrounds) joins the first in deciding what might look good on a web page.  So here, in lab 1, one student cannot do most of the work:  both will need to produce web pages to turn in.  The interchange of ideas is crucial, starting with lab 1.