This is my fourth time taking this class. Yep, you read that correctly: 4 times. To be sure, however, I wouldn't exactly say I really took this class until this past quarter. That is because all previous times, I would get psyched out upon looking at the first assignment, procrastinate, think 'oh this prof has a nice late policy' (2^n points off for n days late), and then boom, the late policy would creep up on me, and I would never get the assignment done.

Which brings me to advice on how I got an A in this class, after 2 withdrawals and an F: Treat this class as your absolute number 1 priority.

This class is extremely tough. With the addition of the project (in which you design a web application), this class is essentially a 'lower-division capstone'. You should not expect Eggert to cover what is needed for each assignment and you especially should not expect him to really cover anything needed for your project. For example, we didn't even really cover Git (which is absolutely essential for the group project) until around week 7 I think. And if you waited until week 7 to start your project, well that just isn't a good idea.

You should start all of the assignments as soon as they're released. Do not wait for Eggert to go over everything needed for it, because he won't. The lectures serve as high-level explanations of software construction, and while he uses the assignment topics as kind of guidelines for him to go over various topics of software construction (i.e. Git for version control), he won't go into specifics. It is up to you (and hopefully the TAs' hints video if they keep doing them) to figure out what the hell to do, probably with a couple of visits to office hours. Eggert is very strong on learn-by-doing.

Another thing to be prepared for are Eggert's exams. They are absolutely terrifying. It is quite possible that you will not really know how to do any of it. That being said, you need to realize that everyone is probably on the same level as you, and so everyone will get around 50% most likely (as that is the score that Eggert aims for, because he 'likes a nice bell curve'). In other words, don't freak out too hard on the exam. Just get as much down as you possibly can.

And finally on the final project: Your group will pretty much be on your own. Finding a group that is around the same skill level as you is most definitely the way to go also, as going with the CS gods who have been coding since the womb will probably just give you some intense imposter syndrome, and you really won't learn anything. Nobody on my team had ever even used any of the languages/technologies we used on our project prior to this course, and we still got a 100 on it. Again, online resources/tutorials are godsend.

Anyways, hope this review helps you all not to make the same mistakes I did 3 times in a row.

(P.S. Emacs > vim)

35L was definitely one of the most unique classes I've taken. Since this class is taught by TAs, everyone's experience seems to be different. Having a good TA is critical to understanding everything in this class, however without any ratings on TAs, it is kind of a wildcard when signing up for the class. Thankfully my TA (Shivam Dalmia) was phenomenal and explained everything thoroughly while also being very helpful with projects. The projects in this class are all over the place with new topics coming up every week. Some projects were extremely tedious like learning Eggert's beloved Emacs in Project 1 and literally logging every single key you press in a text file. Projects varied in difficulty and usefulness overall with most projects just being Eggert flexing some patch he made to Coreutils or another GNU project. Project 9 was new this quarter and took a lot of people by surprise. Overall it wasn't too difficult if you gave it some time, but it seemed kind of pointless dedicating a whole project to digging around the git internals.

The final in this class was interesting to say the least. Eggert (who does not show up until the final) strolled in with a stack of exams that were ridiculously thick (at least twice as long as the practice final that was given out). He prefaced the final by saying that he didn't have time to edit the final which was why it was "a little bit longer than he wanted". This was an understatement. I don't think a single person finished the final and the point distributions of questions were completely off. For example, answering in a few words what a git branch is was equivalent in points to writing an entire Makefile for a C program that you also had to write by hand. If you take this class, be sure to do the easy questions first on the final to maximize your points.

Overall this class was a wild ride, but the material you learn is undoubtedly extremely useful. After 35L, it's amazing how much faster and competently I can work on linux servers and use all of the tools that are provided.

I placed an incomplete as my grade since it has not been officially recorded yet, but I'm probably headed towards an A.

First off there is no professor for the class, only TAs that can help you solve small problems with your code or clear up concepts. The entire class is broken into 10 assignments and a final exam.

Assignments:
For most of the assignments they are "assigned" Monday and due that Friday, giving you roughly one school week to finish them (some exceptions like the shell scripting program that takes 2 weeks). I quickly learned to start the assignments the weekend before so I could space my work out properly. I would say to prepare to dedicate on average 15 hours for each assignment. Most of them are not even long, you just need to do a lot of the research on your own. There were multiple times were I had to scrap everything on Wednesday and restart to finish that Friday. Many people think they get easier further down the class. I think there's definitely hard ones throughout the class(Assignment 8) but you get into a nice groove. Also project 10 is just a presentation and short report, and it's pretty easy.
My advice: Break assignments into small chunks and work a bit everyday, while testing all the time of course. Always play around with your code a little too, it'll help answer some of your own questions.

Final Exam:
Focus on the TA slides and overall concepts for the assignments. Just make sure you get what is important from the slides and study these concepts every so often and you'll do fine.

Overall, this class is like a marathon were you think you are always behind. Just put in your best effort for the assignments and study a bit for the final and you'll do fine :)

He clearly doesn't care about how COVID-19 will affect some of the students. All the family shit, inconvenience or fairness cannot be compared with the joy from torturing students. Dr. Eggert is an extremely caring professor and, I sincerely love this course. I love CS but this class is just disgusting.

Wow. This is the worst class I've taken so far. The skills are all valuable but you are given little to no guidance / explanation and the work load is absolutely ridiculous. I EASILY spend twice as much time on this class as CS 32--the weeder class. Not to mention this class is only worth 3 units. :(

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.

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.

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.