For as much time as is spent in school on theory, one still needs to spend (at least) an order of magnitude more time going deep in a theoretical domain to understand it well enough to apply it competently. The difference in the amount of self-study required to grok many classes of complex systems design between someone with a CS degree and someone without falls below the noise floor. No matter what, you will need to do inordinate amounts of self-study to acquire theoretical competency.
A CS degree is essentially a theoretical survey course. It tells you these domains exist and gives a little bit of high level context, but if you want to become an expert in those theory areas then you are still learning almost entirely on your own and/or from other experts on the job.
I am reminded of PGs famous example of the "Blub"[0] programming language .Here's the relevant quote:
> As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
In the above, the "Weird Language" can also be a formal modeling of the problem domain and solution.
(Note: He should not be presuming the developer is "he")
While a good manager should be slotting the right people into the right projects, an important meta-skill for all professionals of whatever background is self-awareness of your own skills and weaknesses and using that awareness to play an active role in determining where you work and what you work on.
In almost all these cases, developing a simple model grounded in some kind of common CS formalism, playing with the idea, and then explicitly constructing the system around that model would have made the application much more understandable, with a lot fewer mysteries, and reliably used by the customer in much less time. Even small systems containing simple logic, with a few input and outputs, can yield extremely complex emergent behavior (Game of Life being first obvious example).
I have met many computer science majors who are incapable of writing software to save their lives, let alone design complex systems.
I also think that if you get hands on experience first, you learn to appreciate the science later on and therefore learn it with more gusto.
“often”?
You are severely underestimating the number of corporate/enterprise/SAAS CRUD jobs out there that don’t have to do anything that complex.
In short: IN GENERAL - Those with SE degrees (or other non-CS degree, or no degree) can be excellent developers (good code style, good unit test coverage, aggressive PR reviewers, etc).
However, the art of computer programming - or computer system design -- is often in formally defining the problem at hand using computational structures (such as graphs), understanding the properties of that model, and creating a new algorithm over that model to solve it. Then developing a software system to mirror the properties of that formal system you designed.
Those people who did not spend dozens-to-hundreds of hours agonizing over their coursework in algorithms, abstract algebra, linear algebra, "foundations of computing" (i.e., computational complexity theory, computational theory, language hierarchies, etc) I found can lack this critical aspect of system design. Instead, they design systems that lack unity and are often simply a collection of routines to handle various inputs - rather than having the knowledge to think "Hm, maybe this whole thing I'm working on is a special case of a well-studied problem". What this means practically is that there is often a simpler, better-defined, and more testable solution lurking behind the veil of ignorance.
Sure, there are many many teams and projects for which the scale or complexity are not sufficient to warrant some kind of formal analysis and modeling -- but many do.