|
|
Should I Take 169?This is a question we as tas get asked frequently. While we can never provide you with a straight yes or no answer, we can help you make an informed decision. To that end, we've linked you to some thoughts and opinions of former students about their experience with 169. Hopefully this will give you a better insight into what 169 is all about.
If you're still torn on the issue, please talk to myself or Eric. We'd be happy to answer any questions you have. While it is tempting to put off the decision to take 169 until it actually starts, doing so can leave you worse off. Because 169 is such a large time commitment, most students take only two other classes besides 167/9. Thus if you begin the semester taking three classes and 167 and intend to add on 169, you might find yourself seriously overworked by the end of the year. Moreover, you might be faced with the difficult decision between finishing all of your original classes and finishing 169.
Now I don't want to make it sound all that dire; I firmly believe that any student who mentally prepares and makes the necessary sacrifies for 169 can and will finish it. The rewards from taking 169 greatly justify the time and effort spent on it. I can't even begin to articulate how much my mental model of the computer has changed from taking 169. So many processes and issues that I never thought about or didn't understand were made absolutely clear.
As many people have noted, 169 makes you a better programmer. It forces you to interact with and understand a large codebase. It forces you to write code that is clean, concise and amiable to change. Most importantly, it forces you to understand exactly what's going on. The nature of operating systems code means that many high-level programming language abstractions, such as the stack or registers having certain state, may be broken. By being exposed to these broken abstractions, you have a greater appreciation for when they work. Furthermore, you completely understand the mechanisms underlying the abstraction.
While I love 169, I realize it's not for everyone. And while I do recommend that you take 169 if you take 167, I would still much rather have you take only 167 than no operating systems course at all. 167 will definitely make you a better programmer and will still expose you to the underlying mechanisms of the abstractions described above. What 167 lacks are the small details that concretely glue together the larger pieces. This is what 169 provides. This is why I took it.
So, to sum up, if you're still unsure whether you want to take 169 or not, talk to me, ask questions -- figure it out now. I'm availabile before and after class as well as on my hours.
Yotam Gingold's thoughts:
If you're looking for a deep understanding of operating systems, take CS 167. If you're the compleist type who doesn't leave a room in Zelda until you've sword-tapped AND bombed every wall, take CS 169. CS 169 will give you a few more worry wrinkles, though you'll have virtual memory to show for it, which *sounds* like it could be useful all over the place. 169 doesn't diverge from 167 until after the second assignment, so you get some time to see how you like writing systems code in a stunted subset of C++. 169 works like 123, where your code keeps building on itself (like a snowball, which when unsupervised likes to turn into an avalanche).
In CS 169, all the data structures and function declarations you'll need are given to you; you "just" have to fill them in. Systems code is all about thinking logically and dealing with corner cases, which makes filling in the functions a straightforward process once you understanding the design. The straightforward code also means your bugs tend to be small and simple. This doesn't mean debugging is easy, it means the bugs are more poisonous and hide better (tropical bugs). This all adds up to a somewhat unpredictable time demand. If you work diligently, you will finish every assignments with time to spare --- but you need to plan for the one or two bad lines of code that can hold you up for days.
Yotam |
|||||||