I've sat next to the engineer who had to write various sort algorithms for the embedded runtime I helped design.
I've witnessed a file system get implemented from scratch.
I have walked through the Windows' kernel source code and knowing my fundamentals sure as heck helped to keep me grounded.
> (and if there aren't, that's often a big red flag that you're doing something wrong).
Or that you've chosen a career building the layers that underpin everything else.
I've found that life is more enjoyable when I understand how things work at a base level, and remembering my fundamentals opened up doors to work on cool projects.
As a fellow 1980s CS person, I too got a lot of DSA coverage, but I ended up using a respectable amount of it when I was working at low-level systems programming jobs. I have never used what I learned in my computer graphics class. But I had classmates who went into animation and used that stuff every day.
Agreed about the lack of any education about the "engineering" side of the work, though. One challenge is that engineering is mostly a group activity but education is focused on individual learning. With some exceptions, you don't get a group grades in classes, and usually, collaborating with other students on your homework or your tests is considered "cheating" rather than "teamwork." Professors aren't in the habit of repeatedly changing the assignment out from under you while you're halfway finished, but dealing well with unpredictably shifting requirements is a huge part of the job.
That would be quite interesting in terms of "real world" education. The unfortunate thing is that most terms/semesters are only a few months long and so work has to be very explicitly defined and scoped to be achievable in that time with the expectation of the student spending maybe 10 hours a week on any one class, tops.
I think it would be too real for the kids.
Coming up to speed on a large existing code base of inconsistent quality and style is another enormously important job skill, as is writing code that can be maintained by the person who has to come up to speed on your code a year later, but you'll never get those skills from writing small precisely-specified programs from scratch.
I think bootcamps try to fill that field but most of the ones I've seen are quite trivial, getting you through the basics. If you're asked to implement 10 greenfield CRUD APIs and then go to a job and have to maintain some huge monolithic repo it's going to be hard.
I think an educational approach where the curriculum involves some sort of "For this task, you have to change this thing in this codebase and deploy it without crashing the thing", "refactor this code base", giving people some sort of project and then switching it up in the middle would be valuable because it's mostly what software engineers do day to day: write tests, fix bugs, implement features in existing projects.
I learned almost nothing about engineering. It took me quite a while on the job to learn and appreciate the practices that result in long-lived, maintainable systems. Overly complex, fragile systems with inscrutable interdependencies using esoteric frameworks are often the product of smart people who don't understand engineering principles (yet we often call them "engineers").