What? Almost the entire meat of my CS program was programming projects in a variety of foundational domains (operating systems, networking, concurrency, databases, graphics, compilers, cryptography, machine learning, visualization, etc).

Theory (discrete math, algorithms, formal languages) was 3 courses out of an 18-course program. HN keeps talking like it's the only thing you do in a CS major, which is bizarre.

I think you misunderstand. After an introductory course, it's expected that you don't need to be "taught to program" anymore. As part of your compiler class, you'll be taught about automata, regular expressions, grammars. For your projects, you might get some help with using a lexer and a grammar generator, but you should be able to figure out the "programming" parts yourself, and the teaching emphasis is on the theory.

Sure, but the vast majority of lecture time prepared you to do the programming projects, the vast majority of out-of-class time was spent on the projects, and the exams required minimal study besides having done the projects (one way of spotting cheaters was to look at the delta between understanding demonstrated out of class vs. in class).

See it this way: Each subject you finished at university, did you come at the end thinking "I learnt how to program", or did you come out thinking "I learnt how to structure a graphics pipeline"/"I learnt the tradeoffs involved in building distributed systems"/"I learnt how to structure data to make consistent updates and retrieval simple and highly performant"?

The most obvious way you apply what you learnt in those classes is by writing programs that implement those ideas (And it's also the easiest way to evaluate whether you actually learnt the concepts). But you can just as easily apply that knowledge by designing systems for somebody else to implement — somebody who presumably lacks the knowledge required to architect the system. Hammering out code is easy, and you don't need a university degree to do it. It's the rest of it that takes some study.

Where I studied, our lecturers expected us to learn the fundamentals of whichever programming language on our own time. The vast majority of our courses were focused on theory of CS/physics/maths/engineering/etc. That might explain why our class size dropped from around 100 in first year to around 15 by 4th year.

We had 5 kinds of maths; algorithms and data structures, databases, computer architecture (with assembly), English lessons, history of mathematics, operating systems, networking, and 2 programming courses: C and Java. There was very little learning by doing.

I suspect there's a fair bit of variance between CS courses, and even how we remember it.

In my case, the topics were similar to the list you give (although there were a significant number of optional classes which I filled with math, skewing it a lot), but the subjects were definitely more theory-focused than practical. Sure, there were practical classes for each subject, weekly projects, semester projects and so on, but they were secondary to the theory in both quantity and difficulty. As an example, you might deep dive into a number of networking protocols, but in the same period only implement a toy TCP/IP during a prac.

Interesting, I guess mine skewed the opposite way: the theory served the projects, and the vast majority of what you needed to know for theory-based exams, you'd pick up by doing the projects. Some lecture slide and textbook review necessary, but not a lot.

Always surprised to hear about this variance, given the general consensus that there aren't differences in quality between schools.

I'm curious, where did you attend? I started a CS degree (at UC Irvine), then stopped because I felt it was too abstract. Maybe I bailed too early.

Let's keep it real, the cheaters aren't opting out of learning to code because they want to dedicate all that extra time to mastering the theory instead.

The real problem is, the idealised goal of a university should be "learn something", but it's actually "get a degree".

Another case of "Once you turn a metric into a goal, it ceases being a good metric".

Goodhart's Law

https://en.wikipedia.org/wiki/Goodhart%27s_law

It depends on the class, but often times it is the university's job to teach people how to code. For example, if you make it through an algorithms class without knowing how to actually implement the algorithms, that is probably ok, as long as you have a strong enough theoretical understanding of them. If you make it through a systems programming class without learning how to do any systems programming, then that is a problem.

I'd disagree on this. Is it important for the university to cover the theory (algorithms, compiler design/automata/languages/parsing, logic, discrete mathematics etc)? Absolutely.

Does that mean there isn't space for a module on software engineering theory (design patterns, development methodologies, OOP principles, testing, version control...)? I really don't see why that has to be the case. Some of the worst code I've seen has been written by academics - undocumented, undescriptive nonstandard single letter variable names everywhere, huge monolithic functions named "compute" that span hundreds of lines and several levels of indentation.

"It is not the medical university's job to teach people to practice medicine. It's not a vocational school. The school is usually trying to teach the theory, not the practice"

See how it doesn't make sense?

No, because a medical school is literally called a professional school.

I don't know why you are marked down for this