Things I would do differently next time:

• I tried moving around the lectures to talk about C and numbers, but this put us behind on some of the assignments, so that T.A.s had to lecture about things before I had a chance to cover them in class (assembler directives are one example). These are problems both for labs and for projects with this lecture order.

• One solution is to delay (or replace or drop) the printf assignment, or possibly to shift the projects a week.

• I also tried the Peer Instruction in the 2 of the Review Lectures. I would say it worked well, but it uses up time. Certainly 5 minutes for 1 question. I would try to do this at least once a week. (The model is simple: ask a multiple choice question, force everyone to pick an answer in 1 minute, break into groups of 5 students and discussion for, say, 4 minutes, then vote again, explain the answer, and answer questions.)

• We added a GDB lab. This was very helpful, and perhaps should have been moved up. Students were using printfs before. Perhaps this would help with the ordering of topics problem?

• We modified the simulator project so that people did it in 5 phases, to make it easier to understand pipelining. This worked well.

• The floating point lab was a disaster; it revealed nitty gritty details about C and implicit floating point conversions so it didn't do what you would expect. Need to change!

• I understand there are more interesting measures of network topology, including efficient bandwidth measures by Mary Baker of Stanford. Also a graphical traceroute from somewhere.

• If was hard to coordinate with readers. There needs to be a weekly meeting with as many readers who can make it, where we check progress, look for problems, answer questions.

• For interrupts, just too confusing to go over the details of what MIPS does for interrupts of interrupts. Describe what UNIX does with Interrupt Priority Level, don't explain nesting of K/U,IE bits, don't explain masking of interrupts, don't explain pending interrupts, … . They should understand single level interrupt, what OS does to handle nested interrupts.

• Cheating was more of a problem. I would change all the homework , project, labs parameters/numbers slightly to look for people who copy from old solutions.

• For exams, what to make 4 versions of test with 4 different sets of numbers on some questions, so that IF people cheat (and you have the name/login of people who are near each other), you can have concrete evidence that cheating occurred.

• In the goal of reducing the workload for all CS courses, I think we should consider throwing out one of the projects, one of the labs, and I already dropped some of the homework. Adjust this in the % of class GPA in beginning lecture. Or replace these with some more reflective questions: short essay on, say, computer security, or computer privacy. What ISA is in the CPU of some of popular products? What is role of computer games and violent events in society?

• I would announce the grade breakdown at the beginning of class: 5% per step seems to work: 95% A, 90%A-, …