Exactly how are those techniques not tools of their own? A binary tree is a tool just like a language or a framework is. A quick sort or a merge sort is just another tool - hell, if I'm using a modern language, I can quite easily get any number of sorts in libraries. And what do I gain from learning the implementation details? Divide and conquer algorithms and recursion are wonderful, but simply saying "learn QuickSort" is emphasizing the wrong things.

I'm biased. I'm 19 and never took a formal CS course. I've self-taught myself some of these concepts - not all (bit twiddling is still a mystery to me). But the best programming learning happens organically. I learned how trees worked not out of a book, but because I needed to implement a parent-child relationship in a note-taking app I built. I learned recursion by learning how to do elegant functional programming in JavaScript to simplify my code.

This is how learning happens. You code. You realize your code sucks. You learn to code better. You realize you don't know how to implement something. You learn all you can about it, then you implement it.

Learn concepts because they're practical, not because they're on a list of Shit You Need to Know For Your Whiteboarding Interview. Every single one of the concepts on that list has practical applications, but there's no reason to memorize them and know them by heart unless you plan to use all of them tomorrow.

Otherwise, you're just falling into the same trap you do using a site like CodeSchool: missing the bigger picture of hacking. You're here to build. Learn what you need to do that.

I found this article intentionally contrarian for no useful purpose. Gayle, the founder of Career Cup cited at the end, runs a business grooming programmers to work at large companies (see her book 'The Google Resume'). Google and other large software companies are notorious for asking puzzle questions. Jeff Atwood, founder of Stack Overflow, has repeatedly expressed a hate for these questions. I've bought one of Gayle's books. It was well-written and helpful. However, I assume most programmers starting with Codeschool, Lynda and others are just dipping their feet into the world of software not shooting for working at Google tomorrow.

Mastery of computer science concepts is important in the long term. But as a 'long-term' programmer (~2 years of serious programming), I have yet to implement my own complex data structures in production use beyond simple JSON objects. Libraries simply abstract most of these problems efficiently enough for most work.

I read a comment recently stating 'the best programmers don't need frameworks'. Of course! The best produce frameworks themselves! And more importantly, the best produce frameworks, languages, and tools to educate the next generation of programmers in best practices. (See zachgalant's comment above.)

For those of us in software, let us not challenge ourselves to achieve personal mastery and also to enable mastery and education for others.

Given the author references a site like codeschool, I wish the author would have provided more direction/books/guides on how to become a programmer through knowing the conepts that he lists so that we could have a productive conversation over content rather than a service/business meant to address a giant market need (skilled workers in the CS field).

I can only speak to the merits of this article, it feels like it is just meant to get a rise out of the CS theory side and the non-CS theory side; which is sad.

Now there are to me two interesting points:

1. Is there a market for a more advanced CS education delivered outside the University system? Coursera/Udacity/EdX cover this to some extent, but even here their courses are simplified versions of the University offering.

2. Is there a way to do address the volume market in a significantly better way than Codeschool et all do? Their pedagogy is quite out-dated -- it's the old programming language as bag of syntax approach. The How to Design Programs (http://htdp.org/) approach, which I'm familiar with, is much better. I'm sure there are other initiatives.

A thousand times this, I'd respect a programmer who can do this and a lot more in a single language, rather than FizzBuzz on 10 different languages.

Even though being a polyglot helps (and provides different perspectives to solving problems - OO, functional, etc), a decent level of knowledge needs to be in place for that perspective to resort to anything of use.

CodeSchool isn't deep, but it gives me a solid overview of a topic and is good at what it does. I _wish_ there was a site out there that could teach me programming, not from fundamentals like a child, but from overarching context and concepts like an adult.

@zachgallant I will try out http://codehs.com next. Thanks for the rec!

I have tried several subscription sites, and I prefer this one by far. A few things make it stand out for me: Variety of content and content depth allows you to get a taste for different languages, tools, and syntaxes, while learning enough to kindle the fires of interest. Kindling and nourishing exciting concepts and ideas is what allows for real learning to occur.

Second, I much prefer the more bare bones approach to teaching than the highly polished, high production, hand-holding that defines Code School. Generally, less time is spent on useless background information which noobs will never appreciate anyways and professionals don't generally give a crap about until they decide to "buy in".

Additionally, they tend to purposely leave in (or even intentionally create) errors while presenting that give important context to the underlying logic. This is the sort of thing that always either get cleaned up in post, or is not embraced for the teaching tool it is.

The only drawback is that it operates as a sort of freelance hub, and not all of the commissioned teachers are equally eloquent OR qualified. However, my feeling is that once you get to the point where you're learning advanced patterns, you're already looking at source code and participating in a community.

But the one thing that traditional computer science education has over all of these sources is that they teach the really hard courses: algorithms, data structures, and discrete math.

The reason why Treehouse and the others don't teach this online is because it is incredibly difficult to teach these courses online. Udacity doesn't even do a great job (and they are the best in my opinion). What elevates the thinking of a programmer is a deep understanding of these topics. And, as far as I know and have experienced, the only way to gain this understanding is to struggle for months through problem sets, proofs, and dense textbooks. Gamified "programming for everyone" websites will give you tactics, but not strategy. This might be fine for your purposes, but please realize this: programming is not for everyone.

It's focused on providing a strong fundamental background to absolute beginners, so they learn not just how to write a program but how to write a good program. We teach good programming style, variable and function naming, commenting your code.

Part of the curriculum is reading other peoples' code and critiquing it. Students learn to think like a programmer, not just follow instructions.

Right now, most of our content is a bit more basic than your recommended path to mastery, but it's all the steps to get you there. You can't underestimate the difficulty of understanding the difference between if and while for a beginner. Or the idea of parameters and return values, things that people with experience often take for granted.

also, feel free to email me if you want to learn more. zach@codehs.com

Maybe the standard reference on design patterns is:

     o    Erich Gamma, Richard Helm, Ralph
          Johnson, John Vlissides, 'Design
          Patterns:  Elements of Reusable
          Object-Oriented Software', ISBN
          0-201-63361-2, Addison-Wesley,
          Reading, Massachusetts, 1995.

     o    Donald E. Knuth, 'The Art of Computer
          Programming, Volume 3, Sorting and
          Searching', ISBN 0-201-03803-X,
          Addison-Wesley, Reading,
          Massachusetts, 1969.

     o    Robert Sedgewick, Kevin Wayne,
          'Algorithms, 4th Edition', ISBN-10:
          032157351X, ISBN-13: 978-0321573513,
          Addison-Wesley, Reading,
          Massachusetts, 2011.

     o    Thomas H. Cormen, Charles E.
          Leiserson, Ronald L. Rivest, and
          Clifford Stein, 'Introduction to
          Algorithms, Second Edition', The MIT
          Press Cambridge.

          Also known as CLRS.

          Sometimes can find this on the
          Internet as a PDF. Amazon currently
          sells the third edition from 2009.

There's an ocean of more such stuff can stuff between ears.

E.g., once I needed something, worked it out, and later discovered I'd reinvented k-D trees. It's in Sedgewick. One project I was on made important use of extendible hashing as in

     Fagin, R.; Nievergelt, J.; Pippenger,
     N.; Strong, H. R. (September, 1979),
     "Extendible Hashing - A Fast Access
     Method for Dynamic Files", ACM
     Transactions on Database Systems 4
     (3):  315–344,
     doi:10.1145/320083.320092

     Extendible hashing
     From Wikipedia, the free encyclopedia

     http://en.wikipedia.org/wiki/Extendible_hashing

Later I heard that a standard Google interview question asks much the same.

So, since I got some extra mileage out of the heap data structure in heap sort, I would criticize the article for asking for quick sort but not also heap sort: For sorting n items, heap sort is guaranteed to run in time proportional to (n)ln(n), but the corresponding expression for quick sort is n^2 (the guarantee including worst case) -- a bummer. Yes, usually in practice quick sort is significantly faster than heap sort.

There's too much of such stuff to carry it all around between one pair of ears. So, get an overview and use books such as above as references. Each of those algorithms takes only about an hour to understand and an hour to program. So, just wait until need such an algorithm.

Alas, CLRS tries to cover the simplex algorithm of linear programming, and my view that they botch the effort. Good coverage of linear programming takes more than an hour, but there are several good texts, e.g.,

     Vasek Chvatal, 'Linear Programming', ISBN
     0-7167-1587-2, W. H. Freeman, New York,
     1983.

Here's an example (which we will generalize below): Write software to say how to feed update information to the control of the trajectory of a spacecraft touring the outer planets with, also, the ability to fly between Saturn and its inner most ring.

For this will also need to know (1) Newton's second law of motion, (2) Newton's law of gravity, and (3) how to setup and solve numerically with sufficient accuracy the resulting initial value problems for some nonlinear ordinary differential equations. So, need some physics, differential equations, and numerical analysis.

Note the 'pattern' that is going on here: (1) We start with the real problem, finding updates to the control of the trajectory of the spacecraft, (2) convert that real problem to a mathematical problem, (3) get a mathematical solution to the mathematical problem (e.g., with theorems and proofs from differential equations and numerical analysis), (4) program the mathematical solution.

So, we do not try to go directly from the real problem to a real solution and, instead, take a side detour from the real problem, into some mathematics, into some software, and then back to the real problem.

I claim that this 'pattern' will be of greatly increasing importance and value for computing starting now and for the foreseeable future. That is, we need ways to connect from the real problem to the real solution more powerful than just what we used to do manually or what we might do intuitively, with heuristics, genetic programming, 'machine learning', artificial intelligence, etc.

For an application of this pattern to information technology startups:

(1) Problem. Pick a "big ass" problem, one, say, 1+ Internet users in the US and around the world want solved. Pick a problem where for those users the first good or a much better solution will be a 'must have' instead of just a 'nice to have'.

The example from biomedical technology would be a safe, effective, cheap, patentable one pill cure for any cancer.

Note: Now with such a "big ass" problem we have a good shot at being able to f'get about subtle issues of UI/UX and 'product/market' fit. So, here we reduce 'market' risk.

(2) Do a faithful conversion of this problem into a precisely stated mathematical problem. The math involved might be original with advanced prerequisites. This conversion is usually from challenging to impossible. If cannot make this conversion, then return to (1) and pick another problem. Else continue.

(3) Solution. Find a mathematical solution to the mathematical problem. Want the solution to result, for the real problem, in the first good one or a much better one than anything else. The math involved might be original with advanced prerequisites. Finding this solution is usually from challenging to impossible. If cannot find such a solution, then return to (1) and pick another "big ass" problem. Else continue.

Note: A mathematical solution to a precisely stated mathematical problem is usually easy to check (follow theorems and proofs) with high reliability. So, if we have such a solution that checks, we have lowered project risk.

(4) Computing. Convert the mathematical solution to software to do the data manipulations. This work might be regarded as resulting in an 'algorithm' for the problem, but an 'algorithm' is just some code to do something, and without the mathematics such code has next to nothing to recommend it. So, we don't really want just an 'algorithm'; instead we want something logically solid from some mathematics.

The computing involved might be original with advanced prerequisites. This conversion is commonly from challenging to impossible. If cannot make this conversion, then return to (1) and pick another problem. Else continue.

(5) Deployment. Deploy the software, go live (say, on the Internet), get publicity, users, maybe ads, and revenue.

Note: Starting at step (1), this sequence has high risk. But given success through step (4), due to the big ass problem and the good or much better solution, step (5) has low risk.

So, if we can get through step (4), then we are GO for a valuable solution to a big ass problem, a solution 1+ billion people regard as a "must have" and not just a "nice to have", get to f'get about subtle issues of UI/UX and 'product/market fit' or a 'lean' development process with lots of feedback from the market and revisions of the work.

My view is that this sequence of (1)-(5) will grow rapidly in importance for computing and startups for the foreseeable future. In this case, the key is not some computing skills, classic algorithms, or computer science but some mathematics. possibly new with advanced prerequisites.

So, net my view is that for the future of computing the crucial academic material is from departments of mathematics instead of departments of computer science.

To be more clear, the advantage of the 'detour' into mathematics is get a solid, low risk 'logical chain' from the real problem to the computing and the real solution. That's part of what we want, right?

The only thing that surprises me about this sequence of (1)-(5) is that it has long been so standard in applications of applied mathematics, physical science, and engineering to the solution of important real problems but seems to be totally missing or nearly so from current venture funded information technology startups.