To make your and your partners time in the lab as productive and pleasant as possible, we strongly recommend that you
Prepare before coming to lab by reading the assignment beforehand, thinking about how to do it, talking it over with your partner and asking questions about it. Then, when you get to the lab, youll be your most productive.
Start early on each assignment. Lab assignments in computer science, more than in most disciplines, are time-consuming; working on a computer until a program works typically takes much more time than work-the-problems assignments. Your team should start a lab as soon as you complete the lab exam associated with the previous assignment; you cant do a week-long lab in just a couple of days. Do not wait until your priority lab meets to begin a lab assignment: all the necessary information for each lab is in this manual. Starting promptly reduces your frustration, since youll have time to ask questions when difficulties arise, and will have sufficient time to finish the lab before the lab exam date.
Pay close attention to detail. Computing, more than many other disciplines, requires precise, literal attention to detail. Take things slowly and deliberately. Wring every bit of information you can out of the assignment description; read the lab exams carefully to know what they require of you.
Remember youre not alone. As you work on your assignments, we encourage you to seek assistance from your partner (obviously!) and from the TAs, the tutors and your colleagues. TAs and tutors will help you with the mechanical details of using the hardware and the software, and they will give you help and hints towards solving the assignments. Be careful, though: if you receive so much help that, in effect, others did the assignment for you, its very likely that you will not have learned enough to pass the lab exam.
Come to lab regularly, even if you or your partner have access to a computer elsewhere. In past offerings of this class, there has been a strong correlation between attendance at labs and passing lab exams without several retakings of it; your interaction with your partner, other students and course staff helps you learn the material more completely and quickly. And it&146s obviously hard to do pair programming in lab if only half the pair comes to lab.
Feel free to experiment. Much of computing is learned by trial and error, trying things out to see what works. (Thats why little kids are so good at it; they learn everything that way.) But adults are often uncomfortable with the error part; they hate to waste time and are embarrassed when they make mistakes. But to learn the practical details, youll have to put that discomfort aside and be willing to experiment. If you are concerned an experiment might foul up your assignment, make a copy of that work before doing the experiment. If the experiment goes awry, you can use your copy to back up to where you were. Be prepared to tell TAs and tutors what youve already tried when you ask for their help. Experiment while working on the assignmentsbut not on the lab exam: you should have things figured out by then!
Don t lose it. Computers can be frustrating; its challenging to communicate with a dumb machine. If you feel like losing your temper (and nearly everyone who works with computers occasionally does), take a deep breath and remember: Its only a machine. Its only an assignment. Its only a class. Someone is available who can help you find a way out of your difficulty (especially if youve started early and left adequate time).
Written by David G. Kay, Fall 1994, and revised, Fall 1995, with excerpts from previous versions
prepared by Norman Jacobson, Julian Feldman, and David G. Kay
Minor revisions by Norman Jacobson, December 1995, December 1996, December 1997
Revised for the Fall 1999 offering of ICS21 by Norman Jacobson, September 1999
Minor revisions by Norman Jacobson, December 1999, June 2000
Minor revisions by Dan Frost, Norman Jacobson, Alex Thornton, September 2000
Minor revisions by Norman Jacobson, March 2002
Revised to reflect pair programming by Norman Jacobson, September 2006
Minor revisions by Norman Jacobson, December 2006
Minor revisions by Norman Jacobson, September 2007