Bar none, this is the right way to take CS 130. This class is taught by a rotating group of employees at Google who actually do this stuff for a living. In my mind, despite how much work this class is (not very much by Eggert's standards, but still sizeable), this made all the difference in the world. This quarter, it was taught by Michael Burns, Greg Billock, and Eric Hennigan. As with Eggert's version of this class, the group projects really do make or break your grade, so having a cooperative, helpful group to work with is essential. I took this course during the COVID-19 pandemic when everything was online, so good communication with teammates and the instructors was more difficult, but still doable.

Nothing about this course felt too overwhelming or frustrating. You worked on a team webserver project for most of the quarter (the project topic rotates from year to year I'm told) and you didn't have to deal with overwhelming and unnecessary problems on final exams and copious amounts of reading. Just practical things you would actually work on in industry. And that was a really nice break from what classes at UCLA usually are. The exams were very open-ended (and a small portion of the grade, 20%) but that was typical of exams this quarter because of online instruction, so I'm not sure how that will be different in the future.

I would say the biggest challenge of this class was interacting with other teams for part 7 of the project, because you have to work across teams to add design features to each other's project repos based on our APIs. The team we were adding features to was quite late sometimes in providing reviews, and the team working on our repo implemented their changes really late. So having to coordinate all that was challenging, but not impossible.

Tips: try to do extra unit tests whenever you can for the early projects. They are pretty generous with extra credit if you have much higher than 80% coverage. Set expectations with your team early on about when to make deadlines and how to handle situations when you can't get something done. Lack of communication results in unnecessary last-minute struggles, especially near the end of the quarter.

TL;DR Overall, it was a great quarter, all things considered, and this is by far the definitive way to take this class. Even if you hate group projects or otherwise don't like this class, you are infinitely better off taking this with Michael and the Google team than with Eggert. Also, shoutouts to Eric for having a unique and snazzy bowtie for every lecture session.

Burns is probably the best professor to take this class with but my god did it have me stressing. If there is one CS class I would say you cannot cram projects it's this one. My group would consistently start relatively early but would always be working down to the wire. The amount of hours I had to put into this class is actually insane. In most classes you can get away with taking a grade hit on a project or two but because this class' projects build on top of each other you have no choice but to finish them. When you meet with your group and split work it can be difficult to judge how much time a task will take, so you need to make sure to start working early in the week to figure out if you need to pass work to someone else. Lectures are long and boring but you really do just need to memorize all the slide content to do well on the exams.

Quarter-long project involves building a webserver from scratch. By the end of the quarter, build times for the project took anywhere from 6 to 10 minutes, which meant that every time you add a print statement to debug something, you had to wait that long to test your changes. I have a Windows computer, and the course offers little support for Windows users (by the end of the quarter, I had to resort to paying for AWS).

Very slow Piazza response times (many times no response at all). No professor office hours unless you schedule them. Vague project specs since professors want you to figure it out and come up with the best design choice. Sometimes, project specs and/or Piazza instructor responses would contradict with the test cases used for grading. We're given one assignment per week. Once, an assignment was posted an entire day and a half late, but the professors refused to give us an extension on the assignment even though we lost a significant amount of time to work on it. To make things worse, this assignment in particular was a very difficult/time-consuming one.

Overall, learned a lot, but could've learned the same thing in lesser time (with a less annoying project). At times, this class felt like a part-time job with weekly meetings with your team and frequent code reviews (sometimes totaling up to 20 hours a week). If you do take this class, make sure you have really great team members!

Listen to me when I say that if you want to get something useful out of your education as a CS major, you need to take CS130 with these professors.


Forget learning about silly graph representations of class architecture or Hoare logic or mobile apps; those topics hardly belong in this class.


Burns and co. (for me, it was Philo Juang (worked on early Youtube!) and Alex Monroe) taught everything that had to do with software engineering as a profession: testing, build systems/deployment, API design, refactoring, distributed systems, design patterns, documentation/writeups, engineering team structure. That's an overview of what they lecture (and test, with short one-hour exams) about. (I didn't attend a single lecture myself, so if you want to do that, you can - but the lectures are extremely insightful. Trust me.)

Now the project, the pearl of this class. You work in a team and stick it with it all year. You have to learn to get along with them and with others at some point. Unlike with the other classes, the professors don't just lazily tell you to come up with an idea and make it happen yourself; the syllabus takes an active role in steering your education. Everyone is making a web server - but when you see people present their approach to implementing the web server, you find an amazing variety of expressiveness in this plain topic, with some groups writing loftily, some writing humbly.


You all work in C++ learning how to write proper code - using RAII (smart pointers, scope-based locks/files), design patterns when appropriate, enforcing code style, etc. One person reviews the team's code for a week; you rotate weekly. You learn so much about writing C++ and writing OOP code. You learn about using libraries and threading and dependencies and CMake and docker and Bash scripts and checking on your server and messing up a build and *getting things done*, because at the end of the day -


- this class is about engineering, not about science. I can say with extreme confidence that I improved as an engineer tremendously and am now actually prepared for my job out of graduation. To use my personal story, I have no internship experience whatsoever and mostly wrote cute projects in various programming languages as I saw fit. From my cooperation with a team member who had experience, I became aware of my shortcomings and how I could improve. From working with a team member who was stressed keeping up to speed, I learned how to better handle my ego and be more sociable. I developed my own good habits and takeaways and now feel so much more confident in myself as an engineer, technically and socially.

Take this class! Don't settle for less.

Taught by three professors at Google which is cool in itself.

The course provides a lot of useful skills that students would learn from software engineering internships such as writing tests, code reviews, design patterns, ... etc. The content is useful, but since students already learned a lot of this from internships, some students find the content redundant. Overall, the projects were fun and not too difficult.

Would definitely recommend taking it with the Google profs in Spring!

Honestly this class is really painful for me but also super super useful. I'd say the experience totally depends on your teammates.. However, regardless of how nice the teammates are or how much they sucks, this is a super useful class. A lot of important software engineering principles are introduced and practiced in this class, like unit testing, dependency injection, code review, etc. Especially if you're not familiar with the industry this class is going to be the one to take (e.g., it's gonna prepare you really well for upcoming internships or stuff)!! But just to make the quarter less painful, make sure to pick the right teammates (at least make sure they know how to code in C++ or if they don't they know how to Google and they do not ghost you :) ).. or have the fingers crossed they matched you to some good smart people.