CSE 332

This is my course review of CSE 332. I took the course in Winter 2016 with Adam Blank.

Notes

I took these notes during the course.

The course has been okay so far, i.e. not excessively annoying like CSE 351. It’s somewhat interesting how the course combines both proof-writing and programming projects (sort of reduces the monotony of most courses in doing problem set after problem set).

I continue to be surprised by the lack of preparation I observe in many CS students. They seem to display a near complete lack of understanding of proofs, for instance. But perhaps the most confused are the most vocal, and the silent majority are decent.

I’m however amazed that the instructor average response time on Piazza so far is 3 minutes.

Dealing with Java’s handling of generics is rather painful, and I am now fully convinced that the several hours I spent at the beginning of the quarter to set up Eclim (a completion engine that integrates with YouCompleteMe on Vim) has been worth it.¹

More observations from after the 7th week (rather chaotic thinking at the moment; I should come back and fix this later, but if not, don’t take what I say here too seriously…): I know at least one person who hated this course when they took it, and by the 7th week I too am rather tired from feeling overworked. However, I should also say that CSE 332 when taught by Adam Blank (the course web pages for past quarters not taught by him look significantly less interesting) could be one of the few courses I would consider worth the money (in terms of UW tuition). The combination of fast responses on Piazza, having many TAs, being able to use GitLab for projects, and the lectures slides (I don’t attend lecture) make for a significantly improved experience compared to simply self-studying the material out of CLRS. Indeed, it sort of amazes me how much work Blank seems to have put into the course (he even builds web apps to facilitate doing/grading homework, e.g. an interactive tree builder for a homework assignment about heaps). His lectures slides are all in LaTeX and often contain step-by-step thought processes for various algorithms (e.g. for deleting from a B-tree or when doing alpha-beta pruning).² One regrettable thing is that the Piazza board (which contains a lot of insight from the instructor and TAs) and programming projects (three in all) are not publicly accessible. The specifications (“specs”) for projects are posted as PDFs, but the projects aren’t as simple as the specs; indeed there is a lot of auxiliary pre-existing code that is important (it’s sort of a challenge to navigate the source/remember what each piece is even doing, but makes the course more realistic unlike the one or two file homework assignments in CSE 142 and 143; it also really shows you the power of modularization).

One thing I strongly dislike about the course is just the sheer amount of time I seem to be spending debugging just to locate very minor problems (I realize it makes me sound naive to say this). Yes, debugging is a fact of life for programming, and yes, practicing makes one quicker at debugging and gives one better intuition about where the problem is, etc., but it is also incredibly distracting from actually learning and understanding the data structures of the course (which is the main topic of interest).

I also don’t think the project writeups add a lot to the course. This is especially because the writeups ask for detailed experiments on the code we have written, and again, it seems like a lot of time spent on something that isn’t the main focus of the course. Yes, knowing how step-counting works and how to time programs is important, but it’s frustrating to have to spend so much time on it and to have so much of the grade depend on it (for project 2, approximately half of the grade is based on the writeup).

I suppose this is also just a general criticism of school (and work) in general, but it’s incredibly stressful to be graded on every minute detail and be subject to deadlines, etc. etc. (I would have preferred something like a point-accumulation-based grading system, where we have unlimited attempts and problems to choose from and solve.)

Also I feel embarrassed to admit it, but despite being a computer user for much of my life and playing around with it a lot (including a fair amount of programming), I had never systematically or comprehensively learned data structures and algorithms until this course. (I only had a partial and ad hoc understanding and intuition for various algorithms and their runtimes.) At times it seems like the other students in the course are better-prepared than I am, because they are also preparing for coding interviews (presumably) unlike me (for now—see e.g. my Wikipedia page). Therefore, this course has given me a kind of confidence that I didn’t have before, in terms of having a better intuition for runtimes of algorithms, and knowing whether the first solution that pops into my mind is good for its simplicity or bad for its horrific inefficiency.

The writeup in particular causes a sort of dissonance because on one hand we are taught to make code clean, robust, etc., and on the other hand there is a deadline to meet and we know we won’t ever look at the experiment code that we write for the writeup. In other words, the experiments encourage a sort of “hackish” mindset of ad hoc modifications, which might be necessary in the “real world”, but it’s still frustrating for the grade to be based so much on it.

Backlinks

• Winter 2016 at the University of Washington
• CSE 351
• University of Washington
• MATH 335
• computing