The Trouble with CodeSchool

&#62; To truly master the art of programming, we must learn the techniques available to us, not just the tools. Data structures, algorithms, design patterns, and computer science concepts are what I’m talking about here.<p>Exactly how are those <i>techniques</i> 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.<p>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.<p>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.<p>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.<p>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’ve spent the last 3 1/2 years working on a computer science degree from Stanford. In the past year, I cannot think of a time my understanding of the concepts mentioned in the article provided me a particular advantage in my programming work. That time includes a research position, an internship at VMware, an internship at Nicira (bought by VMWare), a self-initiated Unix course, a TAship in networking and a few quarters teaching introductory computer science in the CS 198 program.<p>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.<p>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.<p>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.)<p>For those of us in software, let us not challenge ourselves to achieve personal mastery and also to enable mastery and education for others.

Everyone who has shipped a production site knows that codeschool doesn't have a mission to teach you "programming", so much as a stripper does not want to have sex with you. They are both meant to tease and entice you.<p>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).<p>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.

The market for teaching Computer Science fundamentals is already rather crowded with thousands of Universities competing in that space. It's no surprise that Codeschool et al don't address that market. At their pricing level they are going for volume and volume is obviously at the lower end of the market.<p>Now there are to me two interesting points:<p>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.<p>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 (<a href="http://htdp.org/" rel="nofollow">http://htdp.org/</a>) approach, which I'm familiar with, is much better. I'm sure there are other initiatives.

&#62; Do you know what a binary tree is? The difference between a merge sort and a quick sort? What the singleton pattern is, and why and when you should use it? If you can’t answer one or all of those questions, then it’s time to start learning the techniques.<p>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.<p>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.

There's always 2 sides to this argument. CS grads will say codeschool grads don't know enough CS fundamentals. On the other hand non-CS grads will say CS grads only know CS theory and don't actually know how to build products.

I would just like to point out that I believe the CodeSchool methodology is brilliant. I have tried fizzbuzzing my way through Codecademy, reading books and all sorts. But that is not the way I learn: I am an adult. I need to know context. I need goal oriented learning. Furthermore, I am an audio learner more than a visual learner, and because my memory is not as good as it used to be, I need more of the Kinesthetic.<p>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.<p>@zachgallant I will try out <a href="http://codehs.com" rel="nofollow">http://codehs.com</a> next. Thanks for the rec!

<a href="http://tutsplus.com" rel="nofollow">http://tutsplus.com</a><p>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.<p>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".<p>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.<p>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.

This is dead on. Code School, Treehouse, etc. are all excellent learning resources. As are the in person bootcamps that teach you basic programming for roughly $10,000 and 3 months of your life.<p>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.<p>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.

You should really check out CodeHS -- <a href="http://codehs.com" rel="nofollow">http://codehs.com</a><p>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.<p>Part of the curriculum is reading other peoples' code and critiquing it. Students learn to think like a programmer, not just follow instructions.<p>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.<p>also, feel free to email me if you want to learn more. zach@codehs.com

This article completely misses the point of CodeSchool. CodeSchool's best selling point is exactly what the author is complaining about. I know how to program, I know how to design and analyse algorithms and I know my data structures inside out. I don't, however, know the best way to test Rails applications. CodeSchool provides a really accessible way for programmers to stay on top of the latest technologies, frameworks and idioms. It is not intended to replace a CS degree/education and I'm not entirely sure where the author even got that idea from.

I am a soon to graduate CS student, while I know a lot of theory about algorithms, data structures, parallel processing, numerical methods , architecture etc., sites like codecademy/treehouse/codeschool are great supplement. At university I learned basics of programming in java/C but only used them in some theoretical projects to learn about some algorithm/concept. Those sites are great to get into more practical aspect of computing and if you know basics of CS are a great way to pick up new language/framework/field.

The key is balance between theory and craft.

The article criticizes too soon. Here I explain this point, give some references where can get good explanations of the topics in the article, mention some more topics, and then explain what I believe is a more important guide to success in computing for the foreseeable future and, in particular, a low risk approach to very successful information technology startups. For this last, venture partners listen up.<p>Maybe the standard reference on design patterns is:<p><pre><code> 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. </code></pre> Most of the rest of what is mentioned in the article is in any of, say,<p><pre><code> 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. </code></pre> Two lectures of 90 minutes each are about enough to cover what the article has from the last three.<p>There's an ocean of more such stuff can stuff between ears.<p>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<p><pre><code> 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 </code></pre> or in<p><pre><code> Extendible hashing From Wikipedia, the free encyclopedia </code></pre> at<p><pre><code> http://en.wikipedia.org/wiki/Extendible_hashing </code></pre> In my current project, I needed to be able to read a list of, say, 10 million numbers and end up with the, say, 100 largest. To do that I borrowed the heap data structure from heap sort (in Knuth above).<p>Later I heard that a standard Google interview question asks much the same.<p>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.<p>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.<p>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.,<p><pre><code> Vasek Chvatal, 'Linear Programming', ISBN 0-7167-1587-2, W. H. Freeman, New York, 1983. </code></pre> But I believe that the article's author is missing a still bigger point: He is implicitly assuming that for writing a program, it is sufficient (1) to look at the real problem and (2) use knowledge of programming languages and algorithms to write the software. For problems we understand well enough how to do in principle essentially manually, sure. Otherwise, heavily not.<p>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.<p>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.<p>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.<p>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.<p>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.<p>For an application of this pattern to information technology startups:<p>(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'.<p>The example from biomedical technology would be a safe, effective, cheap, patentable one pill cure for any cancer.<p>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.<p>(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.<p>(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.<p>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.<p>(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.<p>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.<p>(5) Deployment. Deploy the software, go live (say, on the Internet), get publicity, users, maybe ads, and revenue.<p>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.<p>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.<p>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.<p>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.<p>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?<p>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.