Another way of putting this: a primary function of a curriculum - university or otherwise - is to convert unknown unknowns (things you don't know exist) into known unknowns (things you are aware of but not fully versed in) and known knowns (things you fully grok). This is why we shouldn't replace college with nothing: this is an important function.

Self-study isn't exactly nothing. I do find that there are a lot of people, especially web developers, who don't understand a lot of the basics, or even the language they're using.

I got into development from doing design work, also self taught back in the 90's. I wanted to do something... spent a very rapid weekend learning JS from a very large book, then applied what I needed the next monday. Spent the next weekend finishing that book and the next month swallowing three other large books on the subject (two more on JS, one on HTML). From there was VB5 then Access & VBA... then I started working as a developer. From there I learned more about databases and data structures, dabbled in C/C++ then circled around to VB6 when it came out. From there around the end of 2001 (after 9/11) I was unemployed and no jobs to be found. While crashing at a friend's house I learned C# with the command line compiler and another large book (didn't have VS). Since then more databases and db types, more C# and when it came out Node.js (had done a lot of classic ASP in JS along the way too).

I spent about 5 years working in eLearning, writing simulations of systems for learning/training as well as courseware. Really enjoyed that time in my life as I was constantly taking in domain knowledge as well as a very varied environment. Unfortunately after a while all the context switching and constant intake took a toll and I took a few more boring jobs doing corporate/banking work.

In any case, you'd be surprised how much you can learn without a formal education, or anything really structured at all. To this day I tend to take in new stuff rapidly and get bored once I've figured out the hard parts. Currently working on learning Rust and Kubernetes, short break on rust as the async syntax gets implemented and settles in.

I think my statement was too strong; I definetely don't mean to suggest that nobody who has never followed a curriculum of any sort can ever be successful. What I mean is that in general, as a policy, it is useful to have some curriculum to shed light on the unknown unknowns.

But to respond to "self-study isn't nothing": that's true, but your self study didn't replace college, it replaced self study. What I mean is that everyone has to do that self study and job training targeted at the specific stuff they're doing. Self study is necessary to expand "known knowns" in targeted areas, which is really necessary. It's just not as good at illuminating "unknown unknowns" as a curriculum put together by a person or group of people who know the breadth and history of a field.

I think it depends on the person and the experience. It's easy to say that a particular course was helpful, because it often is. But what's the opportunity cost? What other things didn't you learn because of all that time learning about, say, OS schedulers?

Also, it assumes that you have access to a very high quality education. In lots of cases, the teaching might be mediocre (perhaps even at elite universities that care more about research grants than education).

There's a lot of value in having a standardized base of knowledge, where you learn all the things that a practicing engineer should know. But in reality, the sum of things you "should" do takes more than a lifetime. And you have to find some ways to differentiate your knowledge and expertise if you want to innovate.

Yes, nothing is perfect. But in general, it is hard to be a good guide to yourself in a new area. You can do it, but it is a skill that needs to be developed and most people don't have it (or rather, they typically have the depth-first part but not the breadth-first part, if that makes sense).

I wasn't even talking about the course quality (which as you note, is very variable) but about the curriculum.

One thing you can do as an individual teaching yourself CS, say, is to try and follow the curriculum of a known good CS program. There are issues with this, too, but at least you are getting some guidance.

The opportunity cost issue is a good point. One problem with following undergrad programs, say, is that only part of what they are doing is teaching you material, the other part is learning-how-to-learn stuff. If you are an independent learner of sufficient skill, some courses will be way too slow for you.

It would be optimal in some sense to have high level "key concept" material that you can survey efficiently and then decide when and where you need to dig deeper. It's a bit of a chicken and egg problem though, because if you are insufficiently skilled you will do poorly at the second part...

As mentioned in another comment for this post, Cracking the Code Interview is probably a good place to start in terms of reviewing some key concepts, assuming you don't have a CS degree and are largely self taught.

Of course given the libraries and systems already available, you don't practically need a lot of this knowledge, but it does help. When certain portions of an application just don't perform well, or when you hit really weird side effects of race conditions on static properties etc. I think it's also important to know the language and tools that you are working with as well as possible. It's not always possible to know everything, but you should probably read and complete at least one book on the language you are using. You can hack away in any given language for years. But until you've actually read cover to cover on a comprehensive book, you won't necessarily understand some concepts, or better still you will learn how the language does something for you, that you've been doing the hard way.

I disagree greatly, I find that the things you need to know you can often just learn on the job.

In this context we are talking precisely about the things that you cannot learn that way (at least, not efficiently).

It's obviously true that you don't need to know these things to perform your current job, but that's not what the OP was talking about.