Who is my partner?

Goto this website (up by Monday Sept 29) and type in your UCSD PID (Starts with A) and you will be shown the name and email address of your partner for CSE8A. We recommend that you contact them ASAP and arrange to meet no later than Wednesday, Oct 1.

How do we do this?

Pair programming means that two people will work together, simultaneously, at ONE machine and collectively write a program. So you need to meet your partner, introduce yourself, and find some time in your schedule each week where you can work together (probably in the basement lab, B260) on the homework assignments.

Before the first homework assignment (PSA2) you should try to find a minimum of 10 hours to work together. That is, you should find and schedule 10 hours each week you are both available and scheduled to work on the assignment. PLEASE find some time BEFORE the day that the homework is due. You should visit this page to report the hours you and your partner will work together. Specifically, you should have some time scheduled on Thurs and Fri of each week (not just Monday and Tuesday).

What assignments are to be done in pairs?

Not PSA1. All of the others unless otherwise announced.

No really, how do we do this?

When you get together to program, you start with one person "driving" (using the keyboard) and one person "navigating" (sitting right next to the driver and watching and advising about what is going on). You should switch roles every 10-20 minutes. I suggest you get a watch with a timer on it and set it to go off every 15 minutes.

There should be a LOT of talking going on. The goal is that BOTH of you completely understand why you are developing the code that you are and how it works. You'll need to know this to pass your interview.

The navigator plays an especially important role in pair programming. One of the reasons pair programming is more productive in industry is because of the navigator. The navigator is freed from the cognitive load of typing and managing the editor. The navigator is repsonsible for managing the high level decisions about where this code is going, and thinking ahead to whether the current code will really lead the team to the final desired destination (e.g a solution to the posed problem). Additionally, the navigator can often catch small mistakes as they happen -- maybe a mistyped variable, a missing semicolon, a forgetten variable declaration. These small mistakes can often be fixed easily at the time you make them, but if you wait to catch them later (at compile time, for example), they may take longer to find and fix.