What is lacking from modern computer science undergrad curriculum?

> Classes teach you all about advanced topics within CS, from operating systems to machine learning, but there’s one critical subject that’s rarely covered, and is instead left to students to figure out on their own: proficiency with their tools. We’ll teach you how to master the command-line, use a powerful text editor, use fancy features of version control systems, and much more!

https://missing.csail.mit.edu/

An overview of what a typical software team looks like, and some sort of role rotation so young people get a taste of all the jobs that come together to create software. Obviously CS students should remain focused on the "Dev" angle, but understanding how QA, Product, design, sales, marketing, and management all come together would be helpful for a lot of people. Not all teams have all these roles, but the majority of engineers who work in corporate America will end up working on pretty standardized cross-functional squads for decades to come. It would be nice to have recent grads respond to that environment with something other than a sneer towards the "non-technical" folks.

College isn't trade school and I'll die on that hill.

But that said kids are pretty bad at just using computers. Courses need to spend more time on getting them up to speed with using CLI tools and familiarity with file systems.

I feel like people need to graduate into using an IDE because teaching people about build tools and configurations or scripting can be a nightmare, no one seems to know how to do it coming out of school.

>Computer Science curriculums. Well rounded engineers

It depends how you define Engineers. Because you could be a Software engineer in the modern day with zero knowledge on anything but software.

It is also interesting you mention well rounded engineers. CS is not an engineer curriculums. That is CE. Computer Engineering. And I would argue you cant be a well rounded engineers when you have little to zero hardware knowledge. Go around on HN, Reddit and Twitter to see how many devs have really zero knowledge on Hardware. It is not about trends, or latest development, but the fundamental of computing. CPU, Cache, Memory, Network, IOPS. And how the OS hides some of these hardware issues.

I still remember I thought I picked the wrong course when I was doing CE. I often wish I had more software or programming materials. Compared to CS when they had more fun. But 20+ years later, I think CE provides much better foundation than CS. Especially when moore's law is dead. You cant ignore hardware any more.

And there is one more thing that CE taught which as far as I am aware of is completely lacking in CS. To this day I still dont understand how an engineer could have zero understanding in cost and business. It only takes a few lectures to provide enough ground work for student to think through this. And yet they are mostly missing in CS.

- Applied logic

  - How do you think through a problem and solve it. 

  - I think a good engineer is someone who is akin to a detective and enjoys that kind of work

- Ethics

  - Intro ethics isn't enough. Also intro philosophy isn't enough. We need actual applied ethics where they sit students down, explain how to say "no", and how to know when you should.

- High-income personal finance

  - Students go from living on $10k a year to $10k a month, basic personal finance is alright but someone really needs to explain how to go through this huge sudden boost in earning power, how to handle it, what to do with it, etc. 

  - Personal finance, in my estimation, is more about how to fit your expenses into your income. I think "high-income personal finance" would assume a basic understanding of how to budget (or even the assumption they won't necessarily need to), but more about setting yourself up long-term and not making financial mistakes

More traditionally, at least a couple of formal logic classes. Nothing drilled into me the fundamental that the logic gate system is IN AND OF ITSELF an abstraction quite like the class where we constructed a formal language. (Which did not evaluate to true and false - it evaluated to tasty or not tasty)

Less traditionally, at least some digital history, politics, and ethics. History of computing at minimum, but ideally also things like the dot-com bust, the rise of search engines pre-Google, a basic idea of when and how the internet + WWW started to grow, the intersection of tech companies and governments, political issues in digital spaces (decentralized versus centralized, "real names" versus pseudonyms, how property ideas translate (or don't) to the digital world etc.) and going over some of the ethical dilemmas and fuckups the profession has faced in the past.

To combine some ideas from the question and from a couple of comments:

They need to teach software engineering.

First, what's the difference? Software engineering is about building programs that are useful in the real world, which typically means it worries about the efficient construction of larger-scale programs, and whether those programs actually meet the need for them when they're done. And then it worries about maintaining them over generations of new developers as the old ones leave. ("Efficient" should be understood as "minimally inefficient", because you cannot make the process of building larger-scale programs efficient. All you can do is minimize the inefficiency as much as possible.)

Second, why should they teach this? Because 95% of their graduates are going to work in software engineering, not in computer science. (If they don't teach this, then they should create a separate software engineering department, as chemical engineering is a different department from chemistry. But if they do that, the computer science departments are going to be a lot smaller...)

EE/CE/CS should be all under one curriculum. Start people with basic transistor logic gates, take them all the way through basic chip design, then assembly, then compilers, then linkers with operating systems with things like networking/drivers/peripherals, then higher level languages, then more advanced things like ML and other algorithms.

Ill even go a step further and say that anyone doing any other engineering discipline should start with that, and then do additional classes to specialize. Mechanical or Aerospace or Bio engineering professions are essentially exercises in optimization, which a modern computer does 1000x better than any human.

The biggest challenge is writing readable code and this should be focused on a bit more on top of does the code work and pass the tests for the programming assignment.

Everyone has their own style of writing code but I find code in the vein of

    bool system_has_room_to_store_new_data = num_objects < db.limit;

    if (system_has_room_to_store_new_data) {
        // ... proceed
    }

is so much easier vs

    if (num_objects < db.limit) {
        // ... proceed
    }

There is a lot like this that would dramatically improve every engineer's ability to write readable code. The biggest difference between academic code and business code is the number of people contributing. Please let's focus more on writing human readable code and less on being as terse as possible.

In almost every language, the compiler can and will inline this for you avoiding the extra variable and memory usage and even if it won't in a GC language the memory will be freed nearly immediately.

This doesn't need to be a course, but it should be applied across existing courses, sample code shown in class etc.

Also, no more

    for (int i = 0; i < myArry.length; i++ {
        myArr[i] += 1
    }

I have almost never seen this in any codebase I have worked with. Teach .map, .filter, .forEach, etc. Every language has these methods.

Another one is early returns for validation checks:

    if (someConditionIsntMet) {
        return null;
    }

    if (someOtherConditionIsntMet) {
        return null;
    } 

    // Proceed with logic and function implementation

This avoids a lot of needless indenting. Putting the checks at the top is so easy. You can even throw all the predicates in an array, loop and return true if all are true or false if one or more is false.

FP has also become far more popular now - a brief overview of Option, Result/Either, and Future types would be nice. We don't have to get into the theory of functors or monoids or monads, but students should be aware there are better patterns of handling errors than try/catch and throw

Technical writing. It would probably be best when paired with an academic reading course where you learn to read the academic papers on computer science. "Foundations in Computing: Reading & Writing"

Each assignment could be a process of writing a summary and then breaking down a component of the paper into a diagram and walkthrough process. Writing in this case would have to involve more than just words too. You could do a section on diagraming and another on screen recorded walkthroughs or video-based show-and-tells.

A lot of CS departments only teach big computing systems, not tiny ones. No microcontrollers, embedded systems, internet of things end point devices, etc. You can often take an engineering course in those things, but it seems like few people are developing a science of tiny computation. Maybe that's part of why microcontrollers have been stagnant for so long.

There should be a class that traces the history of team based software development and criticism of it. Hopefully this class will provide impetus for something better than what we have today. The class should discuss things like:

> NASA and IBM's early software development efforts > Mythical man month. > Rise of the tech giants. IBM. Microsoft. Google. Amazon. Meta. How they approach team based development. > Team based tools. IDEs. Version Control. Now github rules them all? > Why data was neglected for so long. The "OO database impedance mismatch". Or why OO doesn't believe data should exist. > Prototype approach. Prototype and refine first. Then a mad scramble to complete. > Requirements approach. Detailed documentation. Then a mad scramble to complete. > Agile approach. . Then a mad scramble to complete.

Clarity. A clear idea of the meaning and objective of an undergrad CS degree that's shared by students, teachers, universities, and industry.

- What does it teach? - What does it not? - Why that, and for what purpose? - Who should take it? - What are similarly valuable alternatives, for people who want something else?

I had to take a class called Numerical Methods for my math minor. It was all about the various algorithms used in math like Bezier Curves and LaGrange polynomials. I asked for an exception from my computer science department to allow me to substitute this class for one of its other 400 level classes, hoping to use the class for requirements in computer science, too.

The department head refused, saying it's important to have a "well rounded" education, not one focused on math. Instead, I had to take bioinformatics to fulfill the requirement. Because that's, like, more related?

My point is, there was inflexibility in what the department was willing to accept, that seemed pretty arbitrary. Perhaps allowing a broader view of computer classes would lead to a better mix of student's learning.

Security

sales, marketing and negotiation

Caches. Branch predictors, prefetching, translation lookaside buffers and their shoot-downs. The Hot Path. Bitsets, popcount, FFS, a&~(a-1). Kernel bypass, ring buffers. Logging, write-ahead logs, undo/redo/autosave via logging. Computation in strong type systems. Latency vs throughout. Queuing.