Ask HN: Why don't most self taught developers start with Computer Science?
9 comments
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.
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.
There are two sides to this topic.
Without strong theoretical roots and familiarity with sorting/pathfinding algorithms, you are unlikely to spot the situation where off the shelf solutions are not sufficient.
You yourself and your employer might not feel like you are the right person to implement or adapt these low level algorithms. (Chicken and egg problem)
Rest assured that there are projects and occasions where doing this type of work is necessary
Rest assured that there are projects and occasions where doing this type of work is necessary
I'll chime in because you describe me to a tee.
I'm a "maker", and a tinkerer. The science doesn't really interest me near as much as the tools available to make things.
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.
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).
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.
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.
What I do is akin to making cars out of parts engineers have designed.
I'm a "maker", and a tinkerer. The science doesn't really interest me near as much as the tools available to make things.
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.
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).
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.
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.
What I do is akin to making cars out of parts engineers have designed.
In a paradise world, every woodworker could have a deep knowledge of forestry, plant biology, the chemistry of dyes and glues, structural and mechanical engineering, metallurgy and tool repair, and so on ad infinitum. But actually we learn the tried and true ways of doing things, acquire skills and workshop knowhow from mentors, maybe occasionally pick up some scientific knowledge from a magazine. In this way I don't think knowledge of computer science is a necessary basis for practical software work.
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.
Most self taught developers really love programming, not as a career to make a living.
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.
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).
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.
https://github.com/linpengcheng/PurefunctionPipelineDataflow
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.
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).
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.
https://github.com/linpengcheng/PurefunctionPipelineDataflow
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:
- "Hmm I like this game, oh let me try add this cool feature"
- "My mum seems to be having problem with expenses management, I hear from Fred that Python can help"
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.
Finally, David Perkins' baseball analogy applies a lot to practical SW development, quoting from [0]:
``` 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. ```
[0]: https://www.fast.ai/2017/07/17/num-lin-alg/
- "Hmm I like this game, oh let me try add this cool feature"
- "My mum seems to be having problem with expenses management, I hear from Fred that Python can help"
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.
Finally, David Perkins' baseball analogy applies a lot to practical SW development, quoting from [0]:
``` 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. ```
[0]: https://www.fast.ai/2017/07/17/num-lin-alg/
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.
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.
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.
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.
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.
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 about programming languages.
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?