Maybe my CS degree was unique (I don't think it was), but at the 400 level we had specialization choices including security, graphics, web development, databases, operating systems, embedded, software engineering, etc.

> A project that is done in the average CS class will be presented as a way to teach a design pattern rather than teaching how to solve a problem.

Design patterns != algorithms. My professors actually spent precious little time teaching me how to program, most of that was self-taught. What they taught me to do was how to solve problems, and that education has been very useful.

If your CS professors are spending most of their time teaching you design patterns, you should ask for a refund. The only CS class that taught me design patterns was my 400-level software engineering course.

The problem is more that in an undergrad degree you are unlikely to need to do any large scale (by industry standards) project. So the way that they teach you good design is largely forced and the most academic way to do that is through a "design patterns" type class where the project that you are building is small enough not to require design patterns in the first place.

This will then educate people that you should really always look for patterns to apply and ways to abstract things since you will be artificially marked up at college for building abstractions and will look for them in every problem you have.

On the other hand someone who is more taught by experience will start by writing awful code like putting their whole program into 1 or 2 functions , they will then experience pain points because of this and realise certain re-occuring problems and either come up with their own solutions to them or read "gang of 4" , this will teach them design patterns the natural way.

This is exactly how I taught myself. The transition from unorganized to organized (patterns) happened for me pretty naturally. For me, it was learn how to organize, or quit. Now-a-days, patterns are everywhere (and probably have been, but I didn't get it until I got it :)

The CS graduate will have covered big O classifications but if they immediately focus on this form of optimization it's probably because they have spent years reading blogs that tell them this is the nature of tests at places like Google.

If every CS grad automatically thought this way by virtue of their education there would be no reason to test for it in interviews simply because a CS degree is often a minimum requirement for the kind of job where you'll be asked these questions.

It's only a priority if you make it one and those self-taught guys can probably self-teach themselves big O.

My point was more that a formal CS education is likely to give you a different perspective on programming vs being self taught.

I would imagine most self taught programmers focus on results oriented learning, when I first learned to program before doing any formal CS my approach was "I want to do X , what is the minimum set of stuff I need to learn in order to do that good enough", after learning more formal CS and being forced to consider things like abstraction and efficiency for their own sake I would always focus more on them in every program I write.

Not suggesting that you can't be completely self taught and learn everything you could from an academic education (you can) but you are less likely to spend a month learning a bunch of design patterns and algorithms unless they directly apply to something you need to do right now.

You are more likely to just start hacking away at something then think "oh, this code is a mess how can I fix that?" rather than reading the entire gang of 4 book to start off with.

When I was around seven years old, we had a Tandy Color Computer 2. I wore out the book that came with that, playing with BASIC. We also had a Vic 20, a TI-99a and an Ohio Scientific, and eventually an IBM AT compatible. For years, I spent a lot of time playing with short BASIC programs.

Eventually, maybe around seventh grade, I got a book called Turbo Pascal Disk Tutor (or something like that). I loved that book and I spent many months studying the book and doing the exercises. I was very serious about learning object-oriented programming. Over the next couple of years I experimented with a simple wireframe 3D CAD-like program. I became very familiar with abstraction, polymorphism and other object-oriented concepts before I entered the 9th grade.

Anyway, I'm not going to list every single program I ever wrote or design pattern or programming language or concept I taught myself, but the point is, I did read books and learn a lot of things that are actually apparently missing from many undergrad and even graduate CS-like programs. A guy at Stanford just recently came out with a Rails course partly about software engineering, which apparently is practically revolutionary. There is more contemporary software engineering baked into Rails than what probably more than half of CS or even SE graduates in the last five or ten years ever saw in their courses.

And ever since I dropped out of college (only took like two CS-related courses while I was there), I have been extremely motivated to learn as much about CS and software engineering as I can, mainly because of attitudes like yours.