My advice for getting a good grade in this class:

Tests: To make the tests Eggert will watch recordings of his lectures and randomly pull topics for his tests, on my midterm he put a question on how make files, a topic he had spent all of 5 seconds on in class. This is why this class is almost impossible to study for, the best you can do is look over high level concepts (he really likes to ask what if questions) and if you have the time, rewatch the lectures. While taking the test you might feel discouraged because you don't know the answers, this is because you aren't expected to get many right. Eggert shoots for a 50% average on his tests, which is why I recommend just word vomiting on anything you don't know to try to get partial credit.

Hw: the hws are worth 1-1.5% of your grade each and there are 6 of them, considering how little they're worth you'd think they'd be easy, but they can legit take over 10 hours each. The reason people do them is he likes to put questions from the hw on the test and if you have your hw solution with you its really easy to copy bits and pieces from it to the test and they also teach you the content. However if you something else more pressing, for example the project, its fine to turn them in really late or not at all (I personally didn't do assignment 6 for that reason) as the late policy is really generous and they aren't worth much.

Project: All I can say is try to take this class with people you know, if you get a bad group you're just screwed. Most people spend week 10 grinding nothing but this project, break the cycle, start early.

Final grades: Its a little odd that I have to say this but your raw score isn't very correlated with your final grade if that makes sense? He doesn't have a curve, or even a set amount of A's he wants to give out. To determine your final grade he goes over your work and determines what grade you deserve. Eggert is not afraid to fail an entire class if they don't live up to his expectations. But that won't happen to you ... hopefully.

This class absolutely sucks, but has some silver linings. Here's a review from someone who isn't insanely cracked at programming and doesn't converse in Mandarin:
First: assignments. There are 6 assignments, most of which do not pertain to anything said in lecture, each of which takes a stupid amount of time and is pretty pointless for your grade (worth 1.5% each). Use GitHub + GPT to save your own time and sanity.
Second: The TAs. The negative reviews of the TAs are completely accurate, most TAs for this class are insanely useless, not familiar with the content, or teach you the wrong information that screws you later on the test. I stopped going to discussions as the TA-lead section is almost completely useless and sometimes even negative for your own learning. Also, the TAs constantly screw up grading and misgraded 4 out of my 6 assignments, so be sure to regrade request any possible assignment + midterm. The midterm averages increased by 4% just because of regrades and how incompetent the 35L TAs are.
Third: The tests. I got about a std deviation below the mean of 48% on the midterm, but somehow crushed the final and got in the top 20%. Here is the strategy to do good on a Paul Eggert exam: take notes of everything he mentions in lecture/writes down. GPT/understand all the concepts you are unfamiliar with. The stuff he barely goes over or covers is always tested. Become really familiar with the workings of the assignments, especially shell commands, Linux, and Python. Print all lecture + searched up notes. The small things he mentions in lectures are very similar to test questions, Having all lecture notes printed saved me for the final.
Lastly, some tips. Participate a few times in Piazza for participation points. He covers things really fast during lecture, I preferred to watch the recordings to actually write down what he says. The final project was easily the best part, but be sure to get a good group and start early. The content after the first 4 weeks begins to get slightly more interesting and useful. This class is pretty useful as a whole (besides Emacs Lisp). It's also pretty generously curved: around average on the tests will get you a B, above and below average and between 1 Std dev will get a B-/B+, anything above/below std dev will get you an A/C.

Highly reccomend the class, but its really tough. Grading is also really weird. There are 4 labs that make up over %30 of our grade, but only lab 0 and lab 1 were graded in time to talk to TAs about grading. The rest were not graded until 2 hours before the grade deadline, and any 0s were left that way even if unfair. The only enjoyable part of this class was lecture, and maybe labs if the grading wasn't so bad. Eggert is a really ood lecturer, and can stay engaging for 2 hours, unless the material is really boring which does happen. The labs are actually pretty fun to do, but hard to test, so a working program might still get a 70-80 because of special case test cases. Exams were very hard, ~%50 averages on both. As a really bad test taker i still did around average on the midterm and below on the final and passed.

---Lecture: Eggert's lectures are overall good. He makes them engaging and easy to follow. He does a pretty good job at explaining difficult topics. One critique I have for them is that he goes into depth about topics that are not too relevant.

---Discussion: Discussion sections are vital for doing homework. Eggert barely covers the homework in class, and they are very difficult to do without any guidance. Other than homework help, I did not find the content of discussion to be too useful.

---Professor: Eggert is a genuinely nice person, contradictory to how difficult his course is. He is very easy to approach with questions and does a lot to help.

---Project: You can choose or be placed in a group of 3-5 people. This quarter we were tasked with building a client-server web application. Contrary to regular school projects I recommend you really try on this since it can look great on a resume. Eggert only covers React, so if you want to use any other technology it's up to your team to learn (basically a no-guidance project).

---Assignments: He gave 6 assignments and most of them were pretty hard. If you understand them well, you can do them in a day, but if you don't it can take forever. Most of them are pretty useless in terms of attaining skills or prepping for the exam. The grading on them were extremely lenient. He also has an insanely forgiving late policy where each day you're late is 2^(n-1) points off (1 day: 1 point, 2 days: 2 points, 3 days: 4 points...)

---Exams: Eggert's exams are by far the hardest I've ever taken. I can't stress enough that there's no amount of studying that will fully prepare you.

---Tips: Go to discussion section before starting each assignment. Go to office hours if you're ever stuck on a project; don't waste time struggling through it. Start your project early and make a weekly product road map to ensure you're not cramming it during finals week. I would say study every detail of lecture for exams, but no one has time for that. To maximize points make sure you understand every coding language thoroughly and try to BS you're way through open ended questions. In coding questions if you find yourself writing many many lines of code, you're doing something wrong.

It's hard. The midterm was already difficult, and then the final took it to another level. One of the questions could legitimately be a Scheme homework assignment. Generally speaking, there are three types of exam questions:

- Rote: Implementing a simple function, drawing syntax diagrams, etc. This is as close to free points as you're gonna get, so I try to do these first.
- Discussion: I save them for last since they're pretty easy to BS. On the flip side, the TA's will often have a random reason to dock points.
- Cool stuff: Occasionally there will be a question that is like a logic puzzle. The answer was not discussed in class exactly, but you can arrive at it with a solid understanding of the course material. Probably where people lose most points.

Overall, there is no difference between remote and non-remote Eggert exams; they're still timed and he still writes them the day before.

On the other hand, the homeworks are extremely fair. The spec contains a lot of test cases, and if you pass all of them you're almost certainly going to score perfectly. Not to mention the exponential decay penalty for late submission :chef_kiss:

With all due respect, the TAs carry this class. Everything from assignments to assignment hints to the project to exam grading to piazza posts are handled by the TAs. Daniel Meirovitch is the GOAT TA.

Professor only shows up in lectures and during his office hours. Even though he is very knowledgeable about most of the topics, his lectures are disorganized and there is no flow of topics. He jumps from Lisp to HTML to C/gdb abruptly. The lectures provide little to no preparation for the assignments and the project, all the help came from discussion and Daniel's tips videos. And not to mention the fact that all lectures are typed out on Emacs which gets super boring and unintuitive. He isn't on Piazza to answer any student doubts, which is highly irresponsible in my opinion, and takes days to reply to emails.

The midterm and final don't really test you on your understanding of the material but how many (sometimes vague) questions you can write an answer to in the allotted time. It's sad to see that a subject as important as software construction is neglected as badly as this by Eggert.

PROS:
- Project-based class, so you walk out of this class with a unique project that you can put on your resume. This is a group project though, so experiences will vary.
- The discussions are super helpful for assignments. We also use Piazza.

CONS:
- Too much content: This class has so many topics crammed into it, yet it constantly feels like we are behind in lectures. In terms of languages, you have to learn Emacs/LISP, Python, JS, and C for the assignments. Depending on your role in the group project, you'll have to learn other technologies as well.
- A lot of work. The first few weeks are pretty manageable, where you get roughly a week to do each assignment. Assignments 1 (Emacs), 2 (Scripting), and 4 (Intro to Git) were pretty manageable since most of the assignment consisted of lab components that the TAs go over in discussion. Assignment 3 (React) was also relatively easy as well. Assignments 5 (C programming) and 6 (Git internals) were super time consuming and required a lot of things to learn by yourself. You also have the project to work on during this time. At least Eggert has a pretty generous late policy.
- Self-learning: Eggert has a "learn by doing" philosophy, so he has no problems assigning homework and teach the concepts behind them after they are due. Thankfully the TAs are pretty helpful when it comes to this. For the project, you were supposed to build a web app using React and Node.js. They were barely taught in class (1 lecture) and you only had 1 assignment that needed to use React. For the project, you said to learn Node.js and database things like SQL by yourself.
- Exams: They are typical Eggert exams. No real way to prepare for them since the questions are always pretty specific. Taking the exams open-computer was super helpful, but I think the students taking it in-person would have a much worse experience.

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)

Unclarity. Unclear lectures explaining anything vaguely. Unclear assignment specs that makes you wanna smash the computer. Absolutely ridiculous project that the professor teaches you nothing about, and you have to learn every single bit from online resources.

Unpopular opinion: Eggert is one of the best professors at UCLA. His lectures are incredibly engaging and the subject material is interesting. You learn a lot about a bunch of things related to programming languages. This may have been the most interesting CS class I've taken here. There are also practical aspects through the projects. Maybe Prolog isn't that useful but you do a lot of functional programming and go over asynchronous programming and multi threading. These are all extremely useful. Projects range in difficulty. The OCaml project on parsing a grammer is impossible, I think I turned it in a week late. The Java project is okay but a little obnoxious. Every other project is straightforward and fun. I actually found the Lisp project the most fun (but I'm sure a lot of people won't). There's a paper due at the end of the class where you have to talk about a modern programming language. This paper is very easy and depending on how much effort you put into it you could maybe learn something that will help you. We had Kotlin as our language for our paper, which is nice because it can be used practically. The tests had a lot more coding than an average Eggert class. Our first midterm was 3/5s writing functional programs. These kind of tests are a lot more fair and the projects do help.

Don't get me wrong, this class is hard and you will have to put effort in it. But this is the best and fairest class I've taken from Eggert and one of the best Upper Divs at UCLA.