- Home
- Search
- Paul R Eggert
- COM SCI 35L
AD
Based on 146 Users
TOP TAGS
- Tough Tests
- Has Group Projects
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Grade distributions are collected using data from the UCLA Registrar’s Office.
Sorry, no enrollment data is available.
AD
Exams are more of creative writing questions rather than coding questions. One example question would be like "If you were to redesign system A on top of framework B, what's the pros and cons", at which point you can only freestyle write if you don't have the pros and cons of each system in your notes. Midterm had a mean and median around 63/100, final had a mean and median around 70/100, and yet still no curves on the final grades. I got 1 point above the average for midterm and about 82/100 for the final and got a B+. The whole class is appalled that no curves were given to such a low grade distribution. One TA said that past GPA distribution is around 2.7 for this class. It's pretty accurate. Don't be misled by the beautiful grade distribution of 2020 spring on Bruinwalk
Overall this class was definitely very useful towards learning about various aspects of computer science in terms of software development. Eggert was very engaging and the class wasn't as bad as I had initially thought (though the class was probably revamped and being a Sophomore helped as I had previous knowledge before coming in). Eggert is an amazing lecturer and the TAs were nice as well. The assignments were a bit difficult so they definitely took a lot of time to complete. For tests there is a wide variety of subjects tested on so it benefits to really understand how higher level concepts work as well as how to program in the ways taught during lecture.
Screw this dude. Screws us over with ridiculous projects and insane exams that are so hard to answer because he gets philosophical in his questions. He delves into a lot of redundant history and just generally goes on long tangents for extended periods of time, makes him seem like a good professor who wants to make students learn in depth but also makes me question what the point of some of his lectures is when they never make the exam. And after all this shithousery, he doesn't even curve our final grades. I ended up with a C despite being a consistently A/A- student because I did dogshit on his exams. He may have helped amplify my passion for CS, but I'm never taking another class with him again. My GPA and mental wellbeing took a strong hit with this dude.
TLDR - If you care a lot about cs at the risk of your own sanity/free time/grades, by all means ignore this review. If you just want to learn stuff and do exams and do a project, be very careful about this man and this class. It will screw you over if you're not at the very top of your game.
Dr. Eggert is a godly lecturer. You will never fall asleep in his lectures (despite the fact that they're two hours long) because each second of his speech is like honey for your ears, oozing with essential knowledge and a little bit of his eccentric humor. Even when we were just going over basic git commands, his clear and confident explanations just showed how much expertise he has in software construction. And of course he would be an expert—he literally helped write the very tools that he teaches us about. I can't think of any other professor at UCLA who has a bigger impact on free and open source software than Dr. Eggert, and I am truly grateful for his both as an awesome professor and as a pillar of the FOSS community.
Ok, I may be a bit biased, but no matter how passionate you are about FOSS, you will learn a TON from this class. It's not about memorizing Elisp functions or every generation of the HTTP protocol (you can leave those details in your notes since the exams are open-note), but more about understanding the significance, pros, and cons of different components of software construction and how they work together.
One of my favorite lectures was about building software. We started with compiling individual C files. Then, he introduced layers of automation on top of gcc, such as make and autoconf, until we concluded with system packages. It was just so satisfying to learn about how every stage combines to form a more complex system.
A lot of people really dislike CS 35L, since there's so much content and too little time to absorb it. Personally, CS 35L is my most favorite class at UCLA so far, since it taught topics like git/ssh/python/bash/make, which I LOVED learning about. HOWEVER, the class itself is still a pain in the ass. Assignments are often vague and time-consuming. As others have mentioned, this is TA-led, so your experience may vary. I was lucky to have an awesome TA that taught well.
GNU Emacs was the only thing of value that I learned in this class.
Whoa. So, before I 'defend' Emacs, I have to be very careful you know that this is not just a knee-jerk reaction and 'HeY yU iNsUlTeD mAh EmAcS', and that it is not unreasonable to think emacs is outdated. Emacs being outdated is most likely a myth, and that impression will most likely be spread by the fact that many don't use emacs, and never actually get to learn about what it is. It is often compared to text editors, namely Vim, and that is all the more reason it will just look like some old text editor, but it is not that at all. Emacs is not a text editor, emacs contains a text editor. Emacs is more like an example of ancient magic that people once had a hold on and was lost in modern times to some extent. The reason is its a full programming language interpreter with a text editor, at the bare minimum, built on top of it (and to the person who asked why 'nobody builds these things for IDE's', I don't know if that's true, but if there's any truth to it this may be partially why; not every IDE is a programming language, nor does every IDE allow full turing complete modding. Emacs is exceedingly suited for change, even ridiculous change). Better yet, the language it uses is possibly the most dynamic language in the world (lisp), one that allows you to touch and play with the code of the device while its live, and add on to it effortlessly. Hell, a language that allows you to modify the language itself. That is the pinnacle of modding and customization.
Anyways, because of this, its true power is not in its text editor -- many of us forgo the emacs text editing and just integrate vim's text editing into it. It does have a powerful text editor though, I still end up text editing Emacs style more often than Vim style, but anyways -- it is its power as a sort of operating system. You can always build new emacs tools, full programs if you will, and similarly we have continued to build emacs tools over time. You are not using 1970s emacs in 2019, it is still alive and well and extended. Emacs, as it looked when it first came out, was just a starting point, since its not like a normal program which is just a snapshot in time, but a fully organic starting point to grow anything.
It has some graphical limitations, not in functionality but in pure appearance, which can further give the appearance of being outdated, but none of the practical limitations.
Because of emacs' dynamic language nature, there is another secret gem that might be the true source of its power -- integration. Every tool you add to emacs can often be used in conjunction with every other tool in a very polymorphic way, which means adding features is less like "emacs + n + m" and more like "emacs * n * m"; every feature boosts every other feature. This has resulted in some tools that are true outliers, with true power that may not be emulated elsewhere, like org mode and magit (please look into magit if you haven't). Emacs can accommodate many workflows, and teach you some newer ones.
Anyways, as for actual emacs users, the number is not insignificant either. It doesn't have a majority usage, but I will usually see it with at least a 5% or 15% in different community interviews (example: https://insights.stackoverflow.com/survey/2016 ~5.2%). Looking at this survey, that puts it on the same usage (about) as PyCharm , VsCode, and PhpStorm, differing by about 2%, and about half the users of Atom, and it has several more users (in this survey sample) than a common editor like TextMate. It is still a common editor, just with an image of being old or unused or uncommon at time, if anything because its old.
Just as a reminder for the 400th time, one of the strangest things about emacs is its called a text editor, and maybe because in the beginning, that's all there were, and that's what its image became cemented as. Emacs is an IDE, a mini operating system, and much more, and never have I gotten as much features elsewhere as I have in emacs (although I do not claim they are not there), and never have I had the combined features you get from the unique combination and integration of all these features within it. From what I've seen, some emacs features are less refined than some other IDE counterparts, others are more refined. Emacs often (not always) requires more tinkering, an IDE less so. I have had times where I was able to use a huge mod pack for emacs 'out the box' like I would an IDE, and other times where it needed some adjusting. I will say its a bit like android vs ios; android if you want to tinker and freedom, ios if you want something that just works and don't want the freedom to break something. I will not be so bold as to say emacs is going to be the universal best for everything, just that its not outdated, and that it is going to have a very long shelf life. I do possible hope to one day, however, work on a new emacs with a makeover and an overhauled branding, as the latter I think is more what emacs is outdated on; its brand. I luv emacs. T-thanks for reading
Imagine showing up to the final having memorized all 1 billion emacs commands and still getting fisted harder than any other test. People literally showed up with 500 pages of printed notes for this final. All I could do was copy directly from my notes onto the final. I literally have no idea how I got an A in this class.
NEVER with Eggert anymore! Never!
Before I took this class, I assumed that the reviews on Bruinwalk is a bit too exaggerated. I changed my mind right after the midterm.
Exams are very hard and almost impossible to prepare. Homeworks takes a lot of time but how to do the homework is not taught in class. The Project is just enforcing your group to self-study a lot untaught stuff.
The worst point of this class is that you grade depends more on your classmate. If they work very hard, there will be almost no curve, and your effort is nothing in this case.
I did learn a lot through this class, but that kind of suffer make it not worth. I cannot imagine how happy my spring would be without CS 35L.
Some Bruinwalk reviews were helpful for me while taking this course, so I felt that I should provide another data point for this class. I also think that people typically read Bruinwalk reviews for strategies on how to do well in a course, so that’s what my review will mostly cater to. I hope this is useful if Prof. Eggert teaches more iterations of this class which is uncertain at this point in time.
TLDR:
To give yourself a good chance of doing well in this class, you need to have really good/organized (not necessarily concise) lecture notes and play around with concepts Eggert discusses to develop intuition. Make sure you really understand the lecture content (supplement your notes with Google searches, man pages, documentation, etc. to add details to your notes). Eggert exam questions typically test students’ intuition about concepts from lectures. His questions are akin to niche Stack Overflow questions. Developing an intuition for concepts will allow you to fish for more partial credit, which is the way that you do well on these exams. The graders are usually generous with partial credit. Pretty much everyone struggles through this course, so don’t feel bad if you feel lost. To be honest, this is one of those classes where you should stop worrying about how things will affect your GPA/grades, or else you will be super stressed.
Relevant prior knowledge I had:
Some simple UNIX commands (ls, cd). Knew some basic Git commands (add, commit, push). Played around with gdb once or twice. Same with Python. Took CS 31 and CS 32.
Homework:
Reviews from prior quarters give some tips on how to do well on these so I don’t have much to add. New to this quarter (Spring ‘24), there were LA assignment guides that helped students get through the assignments. This was super nice for assignment 6 (random byte stream generator). One of the LAs who contributed to these guides, Benson Liu, was pretty active on piazza to answer questions. Shout out to him. New to this quarter were autograder scripts that the TAs wrote. These were helpful despite some hiccups in the grading of the first assignment. You’d pretty much know your homework grade by the time you submitted it, so that was a nice benefit of having the autograders. You also had unlimited submissions so you could incrementally check that you are on the right path.
Project:
Not much to add here. It was graded leniently. Find a good group and start somewhat early. I feel like everyone spends a lot of time on it until the deadline, even groups who start early. That’s just from what I’ve observed.
Midterm:
I got around the median on this exam. During Spring 2024, the midterm was moved online because of the Palestine/Israel protest events that happened on campus. This probably led to quite a bit of cheating on the exam and I think that this may have been compensated for in the final grades.
Final:
I was able to score in the top 10% on this exam so that’s probably why I got an A. I think I did better on this exam because my answers were much more specific and detailed than those on my midterm. Prof. Eggert typically references an example or piece of code for many concepts in this class. Since my notes were organized (albeit 200+ pages long), I was able to reference relevant examples from lectures to strengthen my exam answers. Having tables of contents and a binder helped me do this. The grading rubrics for these exams tend to award answers that provide some specifics, so I think that worked in my favor. I’d aim for 5-9 sentences for the longer free-response questions. My wrist felt super sore doing this but I think it was necessary.
This is already a pretty long review, so I’ll just add some more comments that you may find insightful:
The class is graded on a curve which is why I talked about my exam grades relative to the class. Prof. Eggert doesn’t provide a methodology for his curve, but I think I got an especially helpful boost from the curve due to my performance on the final being significantly better than my performance on the midterm. Perhaps he was compensating for the online midterm. I know other people in this class felt that they didn’t receive much of a curve (the raw exam scores were relatively high). Nobody will really know though.
There were 2 Bruinwalk reviews for this quarter (Spring ‘24) posted before mine -- I wouldn’t take them super seriously though since they posted a review prior to the final. The final exam is 33% of the grade, so I’m not sure how you can give a reasonable review of a class without taking the final (especially one from Eggert!). To provide context, the first review for this quarter was posted right after the first assignment which is when those auto-grader hiccups happened. As I said before, these issues were resolved for the rest of the assignments.
Would I say that Eggert’s exams are mostly fair? Probably, with some exceptions. Namely, I’m thinking of a problem from our final exam that was not really related to anything covered in class. I’m not going to get into specifics, but I luckily had some knowledge of graph theory prior to the final. For my peers who had no experience with those concepts, I feel for them and can see how that question was unfair. Eggert may introduce new concepts on the exams -- he feels that these are moments where he has the class’ undivided attention to teach. I don’t agree with his philosophy here, but I think you can still do well on the exams by getting questions correct that were mostly related to lecture material.
I felt anxious at times while taking this class, especially after my midterm performance. I think the ideal way to deal with this is to stop worrying about your grade. Just focus on trying to maximize the content you learn from this class because it is useful material. As a bonus, you’ll likely end up with a better grade with that mindset.
Prof. Eggert was always kind and approachable when I asked him questions. His lectures are memorable. I’d suggest trying to attend every lecture in person.
This may be an unpopular opinion, but you may want to take CS 35L and CS 32 in the winter if you have some prior knowledge (more relevant prior knowledge than what I had when entering this class). I say this because the medians for the exams have been much higher in the spring than in winter/fall (70s vs. 50s). CS 35L + CS 32 quarter would be a ton of work, but the spring averages are just so unbelievably high. For reference, 400 people took CS 33 in the spring (the large majority of which were freshmen). Around 170 people took CS 35L in the spring (with a large number being freshmen). The freshmen who take this class in the spring tend to be some of the top in their class, so you might have a better chance to outperform your classmates in the fall/winter.
Paul Eggert is the greatest lecturer I have ever witnessed. He is so passionate about teaching, and it's remarkable how he is so knowledgable while also so good at understanding what it's like to not know things. It is truly an honor to attend CS 35L lectures. Assignments and exams are also very well made. I thought that grading was error-prone, and TAs were not very responsive, but I still enjoyed homework assignments and exams regardless. The LAs, on the other hand, were fantastic. I don't think software construction is a topic I enjoy much, but this class put forth an incredible effort to change that.
AVOID THIS FUCKED UP CLASS AT ALL COST!!! The syllabus and Eggert's teaching is horrible because he's trying to squeeze AT LEAST 2 quarters worth of contents into 10 weeks. The autograder policy he implemented makes this class a fucking nightmare. Yes. one typo will make you get a zero on ALL subsequent keystrokes even if you got them right. I spent like 10 hours for each assignment trying to redo my dribble files again and again just to make the autograder accept my attempt even though I understood how does emacs really work. This class needs a reform ASAP and I don't think Eggert is a great lecturer.
Exams are more of creative writing questions rather than coding questions. One example question would be like "If you were to redesign system A on top of framework B, what's the pros and cons", at which point you can only freestyle write if you don't have the pros and cons of each system in your notes. Midterm had a mean and median around 63/100, final had a mean and median around 70/100, and yet still no curves on the final grades. I got 1 point above the average for midterm and about 82/100 for the final and got a B+. The whole class is appalled that no curves were given to such a low grade distribution. One TA said that past GPA distribution is around 2.7 for this class. It's pretty accurate. Don't be misled by the beautiful grade distribution of 2020 spring on Bruinwalk
Overall this class was definitely very useful towards learning about various aspects of computer science in terms of software development. Eggert was very engaging and the class wasn't as bad as I had initially thought (though the class was probably revamped and being a Sophomore helped as I had previous knowledge before coming in). Eggert is an amazing lecturer and the TAs were nice as well. The assignments were a bit difficult so they definitely took a lot of time to complete. For tests there is a wide variety of subjects tested on so it benefits to really understand how higher level concepts work as well as how to program in the ways taught during lecture.
Screw this dude. Screws us over with ridiculous projects and insane exams that are so hard to answer because he gets philosophical in his questions. He delves into a lot of redundant history and just generally goes on long tangents for extended periods of time, makes him seem like a good professor who wants to make students learn in depth but also makes me question what the point of some of his lectures is when they never make the exam. And after all this shithousery, he doesn't even curve our final grades. I ended up with a C despite being a consistently A/A- student because I did dogshit on his exams. He may have helped amplify my passion for CS, but I'm never taking another class with him again. My GPA and mental wellbeing took a strong hit with this dude.
TLDR - If you care a lot about cs at the risk of your own sanity/free time/grades, by all means ignore this review. If you just want to learn stuff and do exams and do a project, be very careful about this man and this class. It will screw you over if you're not at the very top of your game.
Dr. Eggert is a godly lecturer. You will never fall asleep in his lectures (despite the fact that they're two hours long) because each second of his speech is like honey for your ears, oozing with essential knowledge and a little bit of his eccentric humor. Even when we were just going over basic git commands, his clear and confident explanations just showed how much expertise he has in software construction. And of course he would be an expert—he literally helped write the very tools that he teaches us about. I can't think of any other professor at UCLA who has a bigger impact on free and open source software than Dr. Eggert, and I am truly grateful for his both as an awesome professor and as a pillar of the FOSS community.
Ok, I may be a bit biased, but no matter how passionate you are about FOSS, you will learn a TON from this class. It's not about memorizing Elisp functions or every generation of the HTTP protocol (you can leave those details in your notes since the exams are open-note), but more about understanding the significance, pros, and cons of different components of software construction and how they work together.
One of my favorite lectures was about building software. We started with compiling individual C files. Then, he introduced layers of automation on top of gcc, such as make and autoconf, until we concluded with system packages. It was just so satisfying to learn about how every stage combines to form a more complex system.
A lot of people really dislike CS 35L, since there's so much content and too little time to absorb it. Personally, CS 35L is my most favorite class at UCLA so far, since it taught topics like git/ssh/python/bash/make, which I LOVED learning about. HOWEVER, the class itself is still a pain in the ass. Assignments are often vague and time-consuming. As others have mentioned, this is TA-led, so your experience may vary. I was lucky to have an awesome TA that taught well.
GNU Emacs was the only thing of value that I learned in this class.
Whoa. So, before I 'defend' Emacs, I have to be very careful you know that this is not just a knee-jerk reaction and 'HeY yU iNsUlTeD mAh EmAcS', and that it is not unreasonable to think emacs is outdated. Emacs being outdated is most likely a myth, and that impression will most likely be spread by the fact that many don't use emacs, and never actually get to learn about what it is. It is often compared to text editors, namely Vim, and that is all the more reason it will just look like some old text editor, but it is not that at all. Emacs is not a text editor, emacs contains a text editor. Emacs is more like an example of ancient magic that people once had a hold on and was lost in modern times to some extent. The reason is its a full programming language interpreter with a text editor, at the bare minimum, built on top of it (and to the person who asked why 'nobody builds these things for IDE's', I don't know if that's true, but if there's any truth to it this may be partially why; not every IDE is a programming language, nor does every IDE allow full turing complete modding. Emacs is exceedingly suited for change, even ridiculous change). Better yet, the language it uses is possibly the most dynamic language in the world (lisp), one that allows you to touch and play with the code of the device while its live, and add on to it effortlessly. Hell, a language that allows you to modify the language itself. That is the pinnacle of modding and customization.
Anyways, because of this, its true power is not in its text editor -- many of us forgo the emacs text editing and just integrate vim's text editing into it. It does have a powerful text editor though, I still end up text editing Emacs style more often than Vim style, but anyways -- it is its power as a sort of operating system. You can always build new emacs tools, full programs if you will, and similarly we have continued to build emacs tools over time. You are not using 1970s emacs in 2019, it is still alive and well and extended. Emacs, as it looked when it first came out, was just a starting point, since its not like a normal program which is just a snapshot in time, but a fully organic starting point to grow anything.
It has some graphical limitations, not in functionality but in pure appearance, which can further give the appearance of being outdated, but none of the practical limitations.
Because of emacs' dynamic language nature, there is another secret gem that might be the true source of its power -- integration. Every tool you add to emacs can often be used in conjunction with every other tool in a very polymorphic way, which means adding features is less like "emacs + n + m" and more like "emacs * n * m"; every feature boosts every other feature. This has resulted in some tools that are true outliers, with true power that may not be emulated elsewhere, like org mode and magit (please look into magit if you haven't). Emacs can accommodate many workflows, and teach you some newer ones.
Anyways, as for actual emacs users, the number is not insignificant either. It doesn't have a majority usage, but I will usually see it with at least a 5% or 15% in different community interviews (example: https://insights.stackoverflow.com/survey/2016 ~5.2%). Looking at this survey, that puts it on the same usage (about) as PyCharm , VsCode, and PhpStorm, differing by about 2%, and about half the users of Atom, and it has several more users (in this survey sample) than a common editor like TextMate. It is still a common editor, just with an image of being old or unused or uncommon at time, if anything because its old.
Just as a reminder for the 400th time, one of the strangest things about emacs is its called a text editor, and maybe because in the beginning, that's all there were, and that's what its image became cemented as. Emacs is an IDE, a mini operating system, and much more, and never have I gotten as much features elsewhere as I have in emacs (although I do not claim they are not there), and never have I had the combined features you get from the unique combination and integration of all these features within it. From what I've seen, some emacs features are less refined than some other IDE counterparts, others are more refined. Emacs often (not always) requires more tinkering, an IDE less so. I have had times where I was able to use a huge mod pack for emacs 'out the box' like I would an IDE, and other times where it needed some adjusting. I will say its a bit like android vs ios; android if you want to tinker and freedom, ios if you want something that just works and don't want the freedom to break something. I will not be so bold as to say emacs is going to be the universal best for everything, just that its not outdated, and that it is going to have a very long shelf life. I do possible hope to one day, however, work on a new emacs with a makeover and an overhauled branding, as the latter I think is more what emacs is outdated on; its brand. I luv emacs. T-thanks for reading
Imagine showing up to the final having memorized all 1 billion emacs commands and still getting fisted harder than any other test. People literally showed up with 500 pages of printed notes for this final. All I could do was copy directly from my notes onto the final. I literally have no idea how I got an A in this class.
NEVER with Eggert anymore! Never!
Before I took this class, I assumed that the reviews on Bruinwalk is a bit too exaggerated. I changed my mind right after the midterm.
Exams are very hard and almost impossible to prepare. Homeworks takes a lot of time but how to do the homework is not taught in class. The Project is just enforcing your group to self-study a lot untaught stuff.
The worst point of this class is that you grade depends more on your classmate. If they work very hard, there will be almost no curve, and your effort is nothing in this case.
I did learn a lot through this class, but that kind of suffer make it not worth. I cannot imagine how happy my spring would be without CS 35L.
Some Bruinwalk reviews were helpful for me while taking this course, so I felt that I should provide another data point for this class. I also think that people typically read Bruinwalk reviews for strategies on how to do well in a course, so that’s what my review will mostly cater to. I hope this is useful if Prof. Eggert teaches more iterations of this class which is uncertain at this point in time.
TLDR:
To give yourself a good chance of doing well in this class, you need to have really good/organized (not necessarily concise) lecture notes and play around with concepts Eggert discusses to develop intuition. Make sure you really understand the lecture content (supplement your notes with Google searches, man pages, documentation, etc. to add details to your notes). Eggert exam questions typically test students’ intuition about concepts from lectures. His questions are akin to niche Stack Overflow questions. Developing an intuition for concepts will allow you to fish for more partial credit, which is the way that you do well on these exams. The graders are usually generous with partial credit. Pretty much everyone struggles through this course, so don’t feel bad if you feel lost. To be honest, this is one of those classes where you should stop worrying about how things will affect your GPA/grades, or else you will be super stressed.
Relevant prior knowledge I had:
Some simple UNIX commands (ls, cd). Knew some basic Git commands (add, commit, push). Played around with gdb once or twice. Same with Python. Took CS 31 and CS 32.
Homework:
Reviews from prior quarters give some tips on how to do well on these so I don’t have much to add. New to this quarter (Spring ‘24), there were LA assignment guides that helped students get through the assignments. This was super nice for assignment 6 (random byte stream generator). One of the LAs who contributed to these guides, Benson Liu, was pretty active on piazza to answer questions. Shout out to him. New to this quarter were autograder scripts that the TAs wrote. These were helpful despite some hiccups in the grading of the first assignment. You’d pretty much know your homework grade by the time you submitted it, so that was a nice benefit of having the autograders. You also had unlimited submissions so you could incrementally check that you are on the right path.
Project:
Not much to add here. It was graded leniently. Find a good group and start somewhat early. I feel like everyone spends a lot of time on it until the deadline, even groups who start early. That’s just from what I’ve observed.
Midterm:
I got around the median on this exam. During Spring 2024, the midterm was moved online because of the Palestine/Israel protest events that happened on campus. This probably led to quite a bit of cheating on the exam and I think that this may have been compensated for in the final grades.
Final:
I was able to score in the top 10% on this exam so that’s probably why I got an A. I think I did better on this exam because my answers were much more specific and detailed than those on my midterm. Prof. Eggert typically references an example or piece of code for many concepts in this class. Since my notes were organized (albeit 200+ pages long), I was able to reference relevant examples from lectures to strengthen my exam answers. Having tables of contents and a binder helped me do this. The grading rubrics for these exams tend to award answers that provide some specifics, so I think that worked in my favor. I’d aim for 5-9 sentences for the longer free-response questions. My wrist felt super sore doing this but I think it was necessary.
This is already a pretty long review, so I’ll just add some more comments that you may find insightful:
The class is graded on a curve which is why I talked about my exam grades relative to the class. Prof. Eggert doesn’t provide a methodology for his curve, but I think I got an especially helpful boost from the curve due to my performance on the final being significantly better than my performance on the midterm. Perhaps he was compensating for the online midterm. I know other people in this class felt that they didn’t receive much of a curve (the raw exam scores were relatively high). Nobody will really know though.
There were 2 Bruinwalk reviews for this quarter (Spring ‘24) posted before mine -- I wouldn’t take them super seriously though since they posted a review prior to the final. The final exam is 33% of the grade, so I’m not sure how you can give a reasonable review of a class without taking the final (especially one from Eggert!). To provide context, the first review for this quarter was posted right after the first assignment which is when those auto-grader hiccups happened. As I said before, these issues were resolved for the rest of the assignments.
Would I say that Eggert’s exams are mostly fair? Probably, with some exceptions. Namely, I’m thinking of a problem from our final exam that was not really related to anything covered in class. I’m not going to get into specifics, but I luckily had some knowledge of graph theory prior to the final. For my peers who had no experience with those concepts, I feel for them and can see how that question was unfair. Eggert may introduce new concepts on the exams -- he feels that these are moments where he has the class’ undivided attention to teach. I don’t agree with his philosophy here, but I think you can still do well on the exams by getting questions correct that were mostly related to lecture material.
I felt anxious at times while taking this class, especially after my midterm performance. I think the ideal way to deal with this is to stop worrying about your grade. Just focus on trying to maximize the content you learn from this class because it is useful material. As a bonus, you’ll likely end up with a better grade with that mindset.
Prof. Eggert was always kind and approachable when I asked him questions. His lectures are memorable. I’d suggest trying to attend every lecture in person.
This may be an unpopular opinion, but you may want to take CS 35L and CS 32 in the winter if you have some prior knowledge (more relevant prior knowledge than what I had when entering this class). I say this because the medians for the exams have been much higher in the spring than in winter/fall (70s vs. 50s). CS 35L + CS 32 quarter would be a ton of work, but the spring averages are just so unbelievably high. For reference, 400 people took CS 33 in the spring (the large majority of which were freshmen). Around 170 people took CS 35L in the spring (with a large number being freshmen). The freshmen who take this class in the spring tend to be some of the top in their class, so you might have a better chance to outperform your classmates in the fall/winter.
Paul Eggert is the greatest lecturer I have ever witnessed. He is so passionate about teaching, and it's remarkable how he is so knowledgable while also so good at understanding what it's like to not know things. It is truly an honor to attend CS 35L lectures. Assignments and exams are also very well made. I thought that grading was error-prone, and TAs were not very responsive, but I still enjoyed homework assignments and exams regardless. The LAs, on the other hand, were fantastic. I don't think software construction is a topic I enjoy much, but this class put forth an incredible effort to change that.
AVOID THIS FUCKED UP CLASS AT ALL COST!!! The syllabus and Eggert's teaching is horrible because he's trying to squeeze AT LEAST 2 quarters worth of contents into 10 weeks. The autograder policy he implemented makes this class a fucking nightmare. Yes. one typo will make you get a zero on ALL subsequent keystrokes even if you got them right. I spent like 10 hours for each assignment trying to redo my dribble files again and again just to make the autograder accept my attempt even though I understood how does emacs really work. This class needs a reform ASAP and I don't think Eggert is a great lecturer.
Based on 146 Users
TOP TAGS
- Tough Tests (67)
- Has Group Projects (58)