The popular opinion for this course is that the projects are way too hard and take way too long. For most people, that does carry quite a bit of truth. However, just saying that would make this review sound exactly like the ten preceding this one, so I'll try to do better.

I would qualify the difficulty in the projects, as not that they themselves are difficult, but rather they require quite a lot of knowledge and maturity in programming in C – something that the previous Computer Science classes do not prepare the students well for. Having done the projects myself and helped numerous others, I'd say the two major pillars that people were not as prepared for were:

- reading documentation (“man pages”): ability to skip the boilerplate and get to what you are actually looking for; finding and adapting example code

- understanding and applying memory allocation: fixed-size arrays vs. malloc(); pointers, lifetime, and ownership. Most people understand what they are and how they are different, but applying that knowledge correctly could be a different challenge.

If you are or become comfortable with these things, the projects will be quite doable.

On the other hand, the exams had a different focus. I hate to use the overused word, but they force you to think critically and provide a reasoned answer backed up with facts and experience. For dreamers and debaters, it was heaven. For the rest of us, it was a first taste at what software engineering is all about: a whole lotta dreaming and debating. (Oh, feel free to replace “dream” with “BS.”)

But where do you get the facts and the experience? The former you get by following textbook readings, which are unfortunately very heavy, as well as by listening and processing Professor Eggert's excellent lectures. The latter you get by stumbling and reflecting while doing the projects.

Of course, many online resources exist for help in the projects. However, a word of caution if you do decide to go down that route: most folks on GitHub who post their solutions were just as clueless as you are when they did it. Thus there is great variance in the the quality of said resources.

But if you do end up finding resources of high quality, make sure to maximize your learning by carefully reading and understanding why they did something but not something else: because there’s an actual reason, or because they just felt like it? How did they think of something that you didn't? Reflect, and you’d become a much better Computer Scientist or Software Engineer for it.

Probably said too much already, so I'll stop. In any case, good luck, and hope you enjoy the class!

Paul Eggert is an absolute legend. A veteran of the software development industry, he shines in his lectures while he doles out wisdom from his years of experience. He is irreplaceable.

In terms of exams, yes, they are hard, but one can easily get away with 1-2 standard deviations above the mean by writing down what seems reasonable. Much easier than other exams where you absolutely must know the answer.

Readings were a little bit harsh. Too many readings, not much useful content on them in the exams. One of the books, Principles of Computer System Design: An Introduction by Jerome H. Saltzer and M. Frans Kaashoek (SK), was way too stuffy.

Projects were an absolute disaster this quarter. Way too easy, the skeleton gives everything away. Takes me only like 2 hours to complete. Absolute disgrace, learning nothing from them. Please note that I talked to the professor about this—this isn't his fault, he says he has to keep the labs because the TAs are only trained on them.

I didn't really attend discussion, but the first one was pretty good. Solid TA. Just by design of the course, this discussion wasn't very useful. Reading over the PDF worked just as well for me.

Lectures are pretty good but haven't been changed much in 10 years. Tests are open-notes and hard

Eggert was much more fun for this class than he was for CS35L. He seemed to engage with the material more and offered more examples. I liked his lecture style. I def recommend reading OSTEP throughout the class because his lectures are pretty much exactly the textbook. Make sure to take detailed notes because this will be most of the midterms. Midterms are very hard, but the curve is generous. The assignments weren't too bad but were not always very related to the lectures.

Eggert speaks at the perfect speed to watch bruincasted lectures at 2x speed. Exams are overhated imo; sure they're difficult, but they're difficult for everyone so the curve helps everyone. Labs/hw were fine for the most part, but the guidelines for the round robin lab were god awful, I don't even think the TAs knew the answers to some of our clarification questions.

I got away with watching lectures and not taking my own notes, just using someone's off github. I just wrote down things from lectures that I couldn't find in the past years' notes (like when he mentions a research paper from within the last 4 years or so). I did most of the readings the first half of the quarter but gave up second half and the lectures were good enough to get me through the exams.

Great class. Eggert really cares about teaching

I really advise keeping up with the OSTEP (AD) textbook readings. I understood the lectures much better when I read the assigned reading beforehand. The SK readings assigned are very dense and difficult to read, so I didn't do them. The lectures are more structured than 35L which made it easier to follow along.
The exams are Eggert exams. The averages for the exams were pretty low (around the 60% mark) but my grade definitely got curved in the end.
The labs were badly managed, but going to discussion helped out in starting and completing them. There were last minute changes to the labs and a lot of confusions. The TAs did not have test cases available because of the change in instructions because they could not produce them in time of the deadline and were quote "Too lazy to make them."
Other than the poorly managed labs and the exams, I would say this class is pretty good and more enjoyable than 35L.