I - disagree here. My CompSci background gets me called in to deal with the hard stuff that others skip bc the theoretical parts of CS are not present.
As mentioned in a further comment below - I can understand why code is slow (eg: BigO for cpu or memory), what structures and algorithms to use in different scenarios (Data Structures & algos), how things are working (Computer Architecture, Programming Languages [theoretical construction of languages], Compiler design), and Automata. Absolutely, these can be learned by oneself - but I find they rarely are. I know what is happening at a network layer, OS layer, memory layer, application layer, and system layer, and code layer.
I can grok a new language quickly, by learning some very key aspects of its language design from my Programming Langs class (the "meta" of ProgLang design), etc.
I’ll agree with your disagree. Other than APCS in high school, and some discrete math and number theory in college, I learned to program myself. By reading a lot I picked up most of the things on your list above.
But where I really perceive my limitations from lack of formal education is where math comes into play. I get the gist of how cryptography or machine learning works, but I don’t think I’d be able to work in those areas for a living even if I spent some time brushing up on my skills and doing self-study. I never developed the intuition for the relevant math, and that makes it extremely difficult to pick up the material just by reading. And doing an entire self study course sequence of the missing material seems like too much of a hill to climb.
>> I never developed the intuition for the relevant math
in my opinion, the best way to develop an intuition for the math is through manual calculation (by hand) and by implementing the algorithms/math in code, wax on wax off.
Since everyone making a living in those areas is reusing libraries now many people's knowledge is limited to things they have heard repeated, they don't necessarily have an underlying intuition about the math.
Rayiner, that is really impressive. I personally know I loved programming - but would not have had the fortitude to make it through the theoretical comp sci classes had I been self directed. But oddly enough for me, I favored the theoretical more than the practical classes.
Exposure to the CS curriculum at least gives you a leg up in asking questions and working out the shape of your lack-of-knowledge.
Like, knowing that automata and complexity theory exists and remembering roughly how it works means that if something that needs that comes up, at least you have a sense of what you forgot about it.
For instance, having taken a database class where we worked in the relational algebra has helped me fluently write okay SQL even if I couldn't write out a sentence in the relational algebra to save my life.
That's of course a perfectly good way to learn SQL and probably much cheaper. I'm not saying that you need relational algebra to write a query, that would be silly. I just mean that learning that stuff does stick with you.
> I know what is happening at a network layer, OS layer, memory layer, application layer, and system layer, and code layer.
Yep. For me, the biggest reason I think a degree is necessary is because it is comprehensive. Self taught people are going to inevitably have multiple holes in their understanding. And worst of all, they will be ignorant of where those holes lie and how large they are.
> > I know what is happening at a network layer, OS layer, memory layer, application layer, and system layer, and code layer.
> Yep. For me, the biggest reason I think a degree is necessary is because it is comprehensive. Self taught people are going to inevitably have multiple holes in their understanding. And worst of all, they will be ignorant of where those holes lie and how large they are.
This is not my experience. Self-taught people are often much more aware of the potential for knowledge gaps, because they've had to learn what to learn. Part of self learning effectively is appreciating the complexity of a topic and choosing what to focus on, rather than just be lead through it by a teacher.
Their default position is one of humility, rather than the often common attitude of "I have a CS degree so I know what is happening at a network layer, OS layer, memory layer, application layer, and system layer, and code layer". (Hint, you don't).
In my experience, self-taught engineers are self-taught because engineering is a passion and they spend their lives doing it.
I can see the "I want to earn more money" boot-camp types having holes in their knowledge, but those who read engineering books and stay up all night coding always seem to have the deepest understanding of all because they live for it.
It'll get complicated talking about age too, because we don't want to pretend older people are "better", or risk turning into an agism-in-technology rant, but it has to be said that the older self-taught people probably started with 8-bit home-computers back in the early 80s.
At that time there was no formal courses, and their knowledge probably covers everything from assembly language all the way up - because most people who weren't just playing games started tinkering with BASIC then moved to assembly.
That low-level understanding of the whole system is invaluable, and really hard to self-teach yourself these days when computers are so complex and mysterious.
In 1984, when the Mac came out, I was a starving artist in Denver. I had a lot of college at that point, but no degree. I had foolishly wanted to learn everything interesting, so I had a year of art school and three years of coursework in biology, physics, and mathematics, but I was working in labs and retail by day, and by night as part of a songwriting partnership that ultimately went nowhere.
I was fascinated by MacPaint and wanted to learn how to do that. I had some FORTRAN and some BASIC from coursework, and a little FORTH from a friend, but they hadn't captured my imagination. MacPaint did.
I couldn't afford a Mac. They were 2500 dollars. In 1984 that was half of my annual income. (Yes, I realize that's unbelievably low. Starving artist.)
With help from the woman who became my first wife, I got hold of a Commodore 128. I started by typing in BASIC programs from Compute magazine. One of them was an assembler, and that's where things got really interesting.
I did end up writing an absolutely terrible paint program, but what really obsessed me for months was writing variations of Conway's life. The one I spent a lot of time on was a version that ran multiple sets of rules on the same field at the same time.
The color of a live cell was determined by the set of rules that governed it. Live cells of different colors could see each other for the purposes of liveness analysis, which is how the rulesets interacted. They were otherwise independent of each other. I spent countless hours poring over whatever references I could find about how to make things faster and more comprehensible, and tweaking the rulesets to see what happened. I would leave a program running overnight to see what it looked like in the morning. Often it was a boring disappointment. Sometimes it was spectacular. The rush of the spectacular ones kept me going.
I wrote other programs, too, trying to understand how window and graphics systems and compilers and interpreters worked. I worked in bookstores and read everything I could get my hands on about programming. In those days, retail bookstores paid crap wages, but allowed the staff to borrow all the books they wanted. It was a good deal, from my point of view.
In the fall of 1987, my mother sent me an ad that Apple Computer ran in the Mensa Bulletin, looking for hires. I applied and, to my utter astonishment, Apple hired me, and that started my profession as a programmer and a technical writer.
The way I got the job prepared me well to take advantage of Apple for learning more. I came into the company ravenous to learn all I could about programming. The company had three institutions perfectly designed for an autodidact like me.
First was the corporate technical library, a huge collection of technical books available for employees to borrow. Their policy was that if you wanted to borrow a technical book and they didn't have it, they would order two copies: one to lend, and one for you to keep. I got a lot of expensive technical books for free.
Second was the software library. They wouldn't give you a copy to keep, but they would order software that you wanted to check out, and they would let you renew the checkout for as long as you needed. They also maintained copies of basically every piece of software Apple had ever developed, released or not. My first hands-on exposure to Smalltalk was a check-out copy of Apple's implementation of Smalltalk-80.
The final pillar of my self-education was Apple's competitive intelligence lab. It was essentially a hardware library with instances of more or less every interesting hardware architecture you could imagine. They had a Cray Y-MP. I learned Lisp and emacs on Unicos running on the Cray. I used to sign up for time on the Xerox machines to play with Smalltalk and Interlisp and the Star Office system.
I agree with those who say that teaching yourself leaves holes. I've been identifying and filling in those holes ever since 1987. On the other hand, I can't say I regret how my natural curiosity ended up leading me into what became my profession. Undoubtedly, I would have been better prepared if I had taken a disciplined approach to learning programming from the beginning.
On the other hand, if I'd had that kind of discipline in the 1980s, then I probably never would have discovered that I liked programming in the first place.
Seeing that I graduated in 1996 from a no name college, do you really think that my degree helped me? By the time I went to school, I had already been writing assembly.
As mentioned in a further comment below - I can understand why code is slow (eg: BigO for cpu or memory), what structures and algorithms to use in different scenarios (Data Structures & algos), how things are working (Computer Architecture, Programming Languages [theoretical construction of languages], Compiler design), and Automata. Absolutely, these can be learned by oneself - but I find they rarely are. I know what is happening at a network layer, OS layer, memory layer, application layer, and system layer, and code layer.
I can grok a new language quickly, by learning some very key aspects of its language design from my Programming Langs class (the "meta" of ProgLang design), etc.