i could really write quite a bit about this. i'll try not to and instead attempt to be concise.<p>i wasn't a cs major before either. 2 years ago i set aside a quite successful consulting business i'd started to go back to school as a 30-something self-taught industry programmer and "fill in the gaps" so to speak.<p>let me say that a good cs education makes a night and day difference to being self taught. even if you're rather good. sure there are very good self taught programmers and while, of course, i'm self-deprecating and don't consider myself one, i've known quite a few. and sure there are also a lot of hacks in university CS programs, even the good ones though relatively fewer the better the program. i'm surrounded by lots of people who i stupidly judged as "beneath me" at first, because of all my so called industry experience, but 90% of them continually surprise me with their ability to solve very complex problems under very non-negotiable deadlines.<p>i thought i knew something when i went back to school. indeed, this actually caused me quite many problems at first because i tended to rely more on what i knew than what was being taught. but i reached a point rather quickly where my industry experience wasn't going to help me at all, and in fact actually hindered me because there was much i'd learned incorrectly.<p>but that's why i went back to school. so i threw much of what i'd accumulated over the years out the window.<p>i was previously a math major, but even doing the required CS discrete math, number theory, combinatorics, probability, set theory, formal logic, etc. introduced me to ways of thinking about math i had not previously seen. i think this is where a bit of rigor in the program one selects helps. some cs curricula will just gloss over these details, but at a huge disadvantage to the students because a really good understanding of a worthwhile algorithms book (cormen, leiserson, rivest, stein, for example) requires them. there's a big difference between doing something (i.e. writing code) and doing something well (writing purposeful code that is an elegant expression of some theoretical model).<p>a solid basis in algorithms is an immensely useful thing. even if it all just seems like "theory" at the time.<p>why? because i can understand most research papers or published documents i read now without having to look things up. or when i have to look something up because i don't know the answer, i generally know the right direction to look in. or i can look at someone else's code and see that they have actually chosen the wrong data structure for accomplishing a task, leading to a vastly inefficient algorithm. or, more importantly, framing the problem in the right graph-theoretical model and, as a result, exposing a richness in the data that i'd not known to exist previously. my first taste of this was the famous four-color theorem. from there i was hooked.<p>...and that was just the first year of being in school. it's also worth pointing out that year i really started to realize the importance of being able to rigorously prove the correctness of each step of an algorithm. though a lot of proofs are those by construction where one essentially describes building the model as the proof, some loop invariants or algorithms must be proven inductively for one to have any certainty about them. indeed, i now believe this was a critical skill to develop. proving the correctness of things improves one's ability to think clearly.<p>interestingly, in my free time i often consider how my education has affected my old development patterns. it might seem that with all this extra formalism that i now sit down and plan everything out before writing even one line of code, harkening back to the old rational-rose way of doing things. to put this to the test i've done a couple side projects in the last couple years and found that my development style was about the same as it was previously: start with an idea, address the nagging issues with implementing it, build a quick (but refactorable) prototype, test the hell out of it, and revise it until it all works. the thing is that in those interim steps i'm drastically more competent now than i was before. when i get stuck on something i can often get unstuck quickly by reasoning my way effectively out of being lost in the forest, and with the tools i have (and paradigms i have access to) if i absolutely must write my own solution from scratch, it's generally written well. and if it's not, it's usually because i didn't understand the problem i was trying to solve ... not the particular coding technique i was trying to solve it with.<p>so other activities (non-chronologically) were things like writing operating system components, replacing parts of the java collections framework with probabilistic data structures or building our own red/black trees, designing chips, writing an embedded system or microkernel, creating oCaml/scheme/haskell parsers and REPL's, building C++ as stroustrup first did (by doing lots of plumbing with void pointers in c), designing new DSL's, spending hours on theory of computation proofs and decidability, implementing the viterbi algorithm for a speech recognition system and other wondrous dynamic programming problems, binary and stereo vision, distributed/parallel computing, and the list goes on...<p>it has all built on the foundations we laid in the first few courses. had i skipped those parts, my solutions would have been less elegant and less correct, if i'd even been able to understand the problems well enough to solve them. and it also has the unanticipated side-effect of my having an intimate understanding of the beauty of the chain of ideas that has led us to this point in technology.<p>of course i'm hoping that all this work results in less loathsome cruft. i look at code i'd written from 5 years ago and shudder. some of it was quite clever but, on the whole, also quite naive.<p>ok, so i wasn't as brief as i'd intended to be. the main point is: you can have a great career as a self-taught programmer. i did previously. if you really love cs material, why not study it formally? if you have the opportunity to go back to school and do it, even if you're older or even if you have to do it part time, it will be extremely rewarding. and if it advances your personal "state of the art" and contributes to your passion, chances are it won't be a waste of time.<p>of course there is an opportunity cost...the money you won't be making when you're in school and the nagging thought that "what if you were on the path to building the next tech revolution and you veered far in another direction to go back to school". i'm afraid my opinion is totally useless here. for going back to school was life-changing to me in many ways beyond cs knowledge. there is much virtue in living a simple existence continually engaged in the pursuit of knowledge. maybe it's just my personality, but i'd say "veer away".<p>...<p>edit: i'd just like to add that i'm not trying to insult self-taught programmers here by any means. at the end of the day, i wholly believe that it all comes down to deliverables.<p>i mainly wrote this to communicate my own experiences when i asked myself a question similar to the original topic of the thread.