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.

I HATE THIS CLASS

I mean there's no real point in saying whether you should take this class since if you're reading this you probably have no choice.

Project: Grading for this is pretty generous, just be very explicit about all the requirements for the report in it and you should be okay there. Even if you start early like we did you're still going to be in a time crunch at the end.

HW: They're all tedious, they vary in difficulty, they're not really relevant for the exam (or the effort you put in is very low yield), so just do them in whatever way you can and get the points...

Exams:

Eggert used an unusually large amount of conceptual essay style questions for our quarter. Having extensive notes will really serve you well here. I printed out man pages (these were very low yield), rules on globbing/regex, tutorials on shell scripting and emacs lisp, and my lecture notes along with vinlin's that you can find on github (very useful). I also made chatgpt explain some particularly hard concepts and printed out that as well. Unless you're really cash-constrained, print out as much as you can. In addition, write tons of information for every essay question on the test, I suspect I lost quite a bit of points on the final from not doing this. You never know what will show up on a final..

One more thing, though it didn't show up that often for us, ACTUALLY PRACTICE the coding techniques (barely taught) from class. Most students will not know how to write code in Lisp or Bash and knowing how to do this stuff can give you a decent advantage on tests.

Lectures are interesting but all over the place. I would recommend watching the recording to make sure you don't miss ANYTHING. If Eggert spends more than two sentences talking about a topic, it is fair game to assume it's on the exam.

Assignments are a pain, so start them early. And take notes on them. I think Eggert aims for about 40% average on his exams, so expect to do bad. Bare minimum you need to understand every thing he said in class, and that should get you a median grade. If you want to do better, try printing out hundreds of pages of command manuals, guides, and tutorials to make sure you are proficient in JS, Python, shell scripting, and C. Aim for partial credit.

Class participation is 10x endorsed answers on Piazza for 0.1% each. I'm not sure why this is a thing because that means TAs have to endorse 2400 answers for everyone to get full credit.

Make sure you have at least one or two people you know will pull their weight in your project group. It's 35% of your grade, and I had a groupmate that authored one commit. I don't think the TAs give af.

TLDR: Pretend this class is 15 units.

This is a review for people who feel as if they are a "below average UCLA student."

Now I can confidently say this, because I am a transfer from CC as a Ling & CS major (35% acceptance rate). So yes, I was not a top 5-10% handpicked CS student like the majority of the students in this class. In fact, I recently switched to Ling & CS, making me still pretty extremely new to coding and all CS-related topics. CS 35L was my first CS class at UCLA.

As a result, I struggled heavily. I don't think I have ever struggled this much in a class EVER. If you are not familiar with the topics and are not considered a superstar student, this class will be extremely difficult; there's no way around it. I even got 2 std below the mean on the midterm (raw score of 16/100).

The odds say that you are definitely a better student/coder than me for being at UCLA, but for those of you who are or believe that you are around me level, I hope that some insights from my experience can make it easier for you.

The first thing I would say is to GPT everything you don't understand. I can confidently say that I would easily have failed/dropped this class if it wasn't for the help of AI cutting the learning curve significantly when it comes to the pace of this class. Eggert goes through several topics pretty quickly, such as Shell Scripting, Emacs, Regex/Globbing, Python, C, git, debugging, security, etc.

The lectures don't go over the content needed to complete the assignments (each takes 5+ hours), so you need to get help from the TAs as much as possible, or use GPT to help break down the assignments or guide you.

Also, you need SOME web dev experience to be of use to your teammates for the group project. I had little to no web experience, so it made my time more stressful/difficult. Try to get a decent/good group, and try to start as early as possible. Make frequent meetings and set goals for each week. Leaving this last minute IS NOT A GOOD IDEA.

For Eggert's tests, you need to pretty much take impeccable notes to at least get the mean. My notes for the midterm were subpar at best, and ability to shell script / apply REGEX were extremely weak, which led to a horrible score.

HOWEVER, for the final, I completely changed my strategy, and even though my grade for it is not out, I believe I did extremely better on it compared to the midterm. Here was my strategy:

- Sign up to StudyFetch with your UCLA email (gives you the full benefits).

- Go to "Media Gallery" on Canvas/CS 35L class and go to each lecture and download the transcript.

- In class, Eggert gives around a 5-10 min break for each lecture. Take the 1st half of the lecture, plug it into StudyFetch for AI Notes, and let it generate "In Depth Notes". Do the same for the 2nd half. This strategy ensures that StudyFetch makes the notes as detailed as possible. If you want, you could split the lectures into 3 or even 4 parts.

This strategy gave me way better notes, and for the conceptual questions, I believe it will give me good enough partial credit for questions that I got completely wrong (I haven't gotten back the final yet).

Eggert still included Node/Python/JS coding/syntax questions that heavily favored those who have experience in coding in those languages. So for the questions that need you to apply the information, I would highly suggest practicing shell scripting, regex, python, C, and JS.

Overall, this class is unlike any other class I have ever taken, and even though it will completely tank my GPA, I still did learn a lot, and I will be trying to improve my CS knowledge over the summer to try to at least be somewhat on par with the average UCLA CS student.

I wish you the best of luck and try not to get egged on the exams! ;)