If there is one major difference I can point out between software developers that went to school on CS education and those that didn't, it's that the ones that did not go to college for CS did not necessarily seek alternative sources for CS. They go head-first into programming concepts.<p>What we get from that is a more varied mixture on how much CS fundamentals these self-taught programmers know. And many of them tend to stay on the surface of programming topics, using higher level tools but more concerned with learning programming languages than learning <i>about</i> programming languages.<p>So I think maybe this is just part of a more generalized concept that self-taught endeavors are less interested in concepts and theory and more interested in "just doing"? Or do they not encourage the discipline to start on theoretical subjects first, and then build up from there?
Because starting with CS does not help them ship anything quickly, starting with CS is a long winded arduous route and most self taught developers start with the intent of shipping:<p>- "Hmm I like this game, oh let me try add this cool feature"<p>- "My mum seems to be having problem with expenses management, I hear from Fred that Python can help"<p>Now, I am not saying that those with CS route don't intend or don't ship; but the motivations at the beginning of the route are different.<p>Finally, David Perkins' baseball analogy applies a lot to practical SW development, quoting from [0]:<p>```
We have been inspired by Harvard professor David Perkin’s baseball analogy. We don’t require kids to memorize all the rules of baseball and understand all the technical details before we let them have fun and play the game. Rather, they start playing with a just general sense of it, and then gradually learn more rules/details as time goes on. All that to say, don’t worry if you don’t understand everything at first! You’re not supposed to. We will start using some “black boxes” or matrix decompositions that haven’t yet been explained, and then we’ll dig into the lower level details later.
```<p>[0]: <a href="https://www.fast.ai/2017/07/17/num-lin-alg/" rel="nofollow">https://www.fast.ai/2017/07/17/num-lin-alg/</a>
Back in my university years I was stunned when we moved from mechanical engineering theory to practice and it became clear that you need little to none theoretical knowledge to design machinery. There were step-by-step guides on every topic, there were machine parts for literally everything and they all were standardized and heavily documented, so putting up an automatic production line was practically a no-brainer. This is what goes on with programming as well - there are frameworks and libraries for everything, all you have to do is to compose a solution to the problem, in most cases it does not require any science.
I'll chime in because you describe me to a tee.<p>I'm a "maker", and a tinkerer. The science doesn't really interest me near as much as the tools available to make things.<p>And, when I try to dive into the science I get overwhelmed and feel like I cannot keep up. The overviews are often interesting, but deeper dives are very difficult to make because they're hard to keep up with and what I really want to do is make something.<p>I've been pondering this very issue myself, and I'm leaning towards thinking there should be a clearer line between the too (CS & developers).<p>I work with open source APIs and languages. I don't need to know about the guts of Javascript or processors to make apps. I need to know how to use the language and the APIs that make that easy for me. And that, just in and of itself, is a career choice that's quite different than CS.<p>I'm using the tools the CS folks make easy for me to use to build apps and people like me can get very good at that, but it's an entirely different kind of person that's good at CS. Those folks are at a different, higher level of understanding how things work than people like me.<p>What I do is akin to making cars out of parts engineers have designed.
Because many CS fundamentals like sorting algorithms or tree traversal have almost zero real world applicability. (When have you ever had to implement a sorting algorithm?) People who are not already committed to learning these concepts through a class have no reason to learn many of them. They’re more likely to spend time on useful things.
Most self taught developers really love programming, not as a career to make a living.<p>My earliest major is accounting and statistics, bachelor of management. I use management ideas and large industrial production lines as algorithms and programming ideas. It is simpler, more mature, more reliable, and more vivid than CS.<p>The history of CS is too short to explore the correct programming ideas. I had tried to learn OO and FP and found that they are Various Pattern To Die (No Do No Die).<p>I suggest that they take a major in industrial production management or finance. Rust learned a little from the financial industry. Unfortunately, the Rust financial model is wrong, causing the language to be too complicated and immature.<p><a href="https://github.com/linpengcheng/PurefunctionPipelineDataflow" rel="nofollow">https://github.com/linpengcheng/PurefunctionPipelineDataflow</a>
Your stereotype may or may not be true. I'm self-taught, my degree is in Aerospace Engineering. But I was curious about how the author(s) of a BASIC interpreter knew what to put in the language so that I could write a little program to determine bending moments in Harpoon anti-ship missiles. I started with the CS part, and ended up having to learn programming concepts along the way.
When considering what people take from a CS education (and I come from one), I don't think it's the fundamentals, concepts or theory that's important if you are interested in building software. I think it's the skills you gain from being in that environment for 3 or 4 years: being able to think abstractly and decompose problems, being able to design systems etc.<p>I can't necessarily name X, Y or Z algorithms or data structures off the top of my head, but I do know how to take a problem, think about it and solve it.<p>If you can get these skills elsewhere then great. I've mentored people doing web development bootcamps and this is always the advice I give them.