| Home | Syllabus | Assignments | Resources | Piazza |
CS161 Survival Guide
Or, How to Write an Operating System. And Live.
By Nick Murphy and other Survivors
In this course you will write an operating system. While such an undertaking is inherently time-intensive, past students will generally agree that it is an extremely rewarding experience. The following includes five simple steps the TFs, in consultation with previous students, have devised to help you survive the semester, do well, and stay on good terms with the course, your TFs, and life in general.
Step One: Initialization: Balance your schedule
We won't lie to you: this course takes a lot of time, probably more than any other CS course you're likely to take. As such, it's probably a bad idea to take four other graduate CS courses, play varsity ping-pong, run a shelter for homeless chihuahuas, and write the next great Finlandian epic at the same time. You are the best judge of your own abilities, but keep in mind that previous students generally report that the course can take as much as 30-40 hours a week at its worst. While you may often find yourself spending less time than this on CS161, you should expect this kind of workload on occasion. Also be aware that any estimation of this sort is very rough and highly dependent on the working style of the individual student. There may be some students who can get away with spending significantly less time than this on their assignments.
Step Two: Initialization: Pick your partner
You will complete most of the assignments in CS161 in pairs. It behooves you, therefore, to pick a partner with whom you will be comfortable spending a fair amount of time over the coming semester. While you can and should work independently on some aspects of these projects, most of your time will be spent working in pairs. As such, make sure you:
Step Three: Design: Envision the future.
One of the aspects of CS161 that you may not be used to is the dependence of each assignment on the previous ones. The end point of any given assignment will form the beginning of the following one, and as such you will have to live with the design decisions you make in future assignments. It is not uncommon to end up having to rewrite subsections of your code from previous assignments to suit the needs of your current assignment. As such, try to make your code easily modifiable and expandable so as not to pigeonhole yourself into writing an increasing number of egregious hacks into your operating system. This implies everything from thoroughly commenting your code so that it makes sense to you later on, to dealing with all error conditions, to making sure that your design has not been created around a special case that may evaporate with subsequent assignments. If you find that your design decisions have become utterly untenable, you may use a solution set as a starting point for any given assignment, but remember that doing so usually implies taking the time and effort to learn a complex piece of code written by the TFs that may make less intuitive sense to you than your own designs. You obviate the need to endure such a hardship by making good design decisions and using your own code.
Step Four: Implementation: Break it on down.
These assignments are large and complex. They are purposefully vague so as to force you to come up with and implement your own designs. As such, one of the essential strategies for dealing with each assignment is to break it down into more manageable sub-tasks. After you have flushed out your design to your (and your TF's) satisfaction, there are two elements of the implementation to consider before proceeding. First, identify waypoints in the implementation at which you will be able to test previous code before proceeding. You would, for instance, probably want to verify that the HTML parser for a web browser were working before you attempted to debug the rest of the project since errors in the parser would likely crop up as random errors in rendering the web page. The worst strategy in CS161, which is often used by a startlingly large segment of the population, is to code the entire project and then attempt to debug it en masse. This more than anything else tends to cause 40-50 hour weeks that circulate in CS161 lore and give it its reputation as a devourer of souls. Debugging such a large project all at once is a monumental and overwhelming task that you should avoid at all costs. You will find debugging individual, smaller pieces infinitely easier.
Step Five: Implementation: Start early, start often.
Contrary to popular belief, it is indeed possible to eat three square meals a day and get a full night's sleep every night while taking CS161. The key is to start early on the assignments and work on them consistently throughout the period before the deadline. You will probably want to start coding at least a week (and ideally sooner than that) before the due date so that you will have several days to debug your code and complete some performance testing. While we do give you five late days to use at your discretion over the course of the semester, these should be reserved either for unanticipated conflicts with other classes, personal emergencies, or those occasionally unavoidable times when something goes horribly, horribly wrong with your design and you need an extra day to fix it. These days should generally NOT figure into your planning. Also, take your design documents seriously. A good and complete design can give you a monumental head start in completing these assignments as it will help you organize and focus your thinking.