SE is often relegated to a "fluff" subject in schools simply because it's, well, not very challenging. Classes based around the topic of SE are often topics like "Formal Software Development Methods" where you learn about verification of concurrent programs, formal symbolic testing, contracts, explicit model checking, etc. These are all "soft skills" and hard to directly generalize into a programming assignment, so students often times write essays formalizing their logic.

Frankly, I'm surprised that your SE class did compilers at all, many schools in CS have their own "operating systems programming"/"low level programming"/"compiler design" sort of class, where the topic is fully fleshed out, rather than just a tiny project.

I think this must vary a lot between schools.

In my school, SE ended up weeding out quite a few people who couldn't actually program. They were fine at math and "theory," but when it came down to actually programming, they produced garbage which only eventually worked through trial and error.

For most other classes, grading was based entirely on test cases so they could still pass with their frankenstein programs. SE was the only course which required the development of a large application and where grading was substantially based on actually looking at the code.

For the record, there were 0 essays in my SE class and lots of large, in-depth projects.

Wow, things have changed since I took my SE electives (17-18 years ago). We had to write code and there were final projects that required the development of a non-trivial application. One that compiled and at least nominally worked. Granted I only took a course of about three electives at the sophomore and junior level, so maybe I missed the "fluff" in other levels.

Yeah the first "formal" sophomore SE elective I took was literally "hey isn't OO the best? Don't you love drawing UML diagrams? What word is P-O-L-Y-M-O-R-P-H-I-S-M, and can you write a 1 page essay on it?"

Once you get up to the actual SE electives, they're all about the formalization of software and how it can be represented. These classes are usually avoided by students as well, since students opt for fun (from the student's pov) classes like robotics programming, compiler design, web development, crypto, etc, which only makes the SE classes seem like more "fluff".

At my school we wrote a part of a model checker (in C, with pthreads) for concurrency, the rest of the assignments were (as I recall) a mix of questions and math proofs, so you either got it, or got to redo the questions.

In general I only recall writing one simple essay and it was, indeed, for our completely fluff project planning class, which was almost entirely about the instructors homegrown, mostly bullshit agile-like system.

I think it depends where you study. In my university, SE was basically "Write essays about why OO is great and draw lots of UML".

Perhaps things have changed since I was in school about 15 years ago but I always called it "academics teaching you their warped view of what life as an industry programmer is like". I quickly learned that nothing which was covered in those classes were things I did in my jobs once I graduated.

Be fair. Some of it is just learning what code is, and how to think about it. They provide some practice with various dogmas. The idea is, once you are working you'll learn more/different ones and have some facility doing so.

"Nothing I learned as a toddler is anything I do now that I'm an adult"