From what I have seen, the ratio of non-clever to clever code in a typical software is 80:20(I am being conservative. It's more like 95:5). The 80% doesn't need cleverness - it needs a lot of discipline and proper abstractions. CS doesn't teach you discipline or proper abstractions. Most of the projects in a CS curriculum are small, done in small teams or solo and are thrown away as soon as the course requirements are met. The higher level CS projects exist just to prove a point(research), or doesn't exist at all except in theory.

I never took the full CS program, but I hit most of the core classes while studying Cognitive Science. By far the most valuable class sequence I took was compiler design; learning HOW a compiler takes code and turns it into assembly language was a revelation to me, and I was able to "see" the relative optimization of algorithms much better after taking that course.

Will I ever need to write a compiler? Probably not, though I have written several small interpreted scripting languages/DSLs. But taking the class expanded my mind in a way that grants me insights a LOT of self-taught programmers I've worked with never seem to have.

Does everyone who takes a compiler design class gain those insights? No, certainly not. It's possible to muddle through just about any class without REALLY understanding it and pass -- some more easily than others.

The weeder classes in CS at my college were tougher than many, though, including one that actually required each student to write non-trivial programs in assembly language.

But back to your comment: It's not that all code needs to be "clever." A friend of mine once CRITICIZED a piece of code for being "too clever," and he was right. "Clever" isn't a goal. But sometimes the straightforward approach made by someone who is good, but self-taught, isn't as good as the equally straightforward approach by the self-taught AND CS-educated programmer.

>The higher level CS projects exist just to prove a point(research), or doesn't exist at all except in theory.

Real higher-level CS projects frequently involve interesting graphics research, which (also frequently) ends up working its way into commercial game development.

I don't have any clue what you mean by "doesn't exist at all except in theory," since even if you're building advanced data structures that you could otherwise pull from a library, you're building something "real" that could actually be used.

> But back to your comment: It's not that all code needs to be "clever."

By clever, I meant code that isn't routine. My definition of clever will include dynamic programming, reducing NP complete problems to known algorithms, writing a parser which takes xml as input and produces python dicts("writing a parser is simple" you say. But compared to the rest of the code in a typical project, it does count as clever)

> But sometimes the straightforward approach made by someone who is good, but self-taught, isn't as good as the equally straightforward approach by the self-taught AND CS-educated programmer.

It's not me who was making general claims. In my post, I did point out that about 20% of the time, CS background is very useful. The OP made the claim that CS and non-CS approach differs in general, which I don't think holds true.

> Real higher-level CS projects frequently involve interesting graphics research, which (also frequently) ends up working its way into commercial game development.

"Real higher level CS" -> http://en.wikipedia.org/wiki/No_true_Scotsman

You don't get to choose what real CS research is.

CS researchers have a lot of commendable qualities, but that requires a different set of qualities than a regular software development project, and CS research doesn't hone their skills as far as regular software dev is concerned.

Look at the code from the academia. More often than not, either there is no code(hence the comment "doesn't exist") or it's spaghetti. I don't see how that helps you write code for the regular projects where you work with teams, code isn't thrown away and you are expected to maintain it. Now, I am not saying CS researchers can't work that way - I am saying what they do for research doesn't help.

The biggest difference is that rigorous CS program will drill this proof-first, implement-later habit in you through repeated exercise. This is very valuable when solving something difficult because you will end up with many trial/errors, and it's much faster to iterate in your head than in an IDE. This habit is also difficult to acquire without deliberate and repeated exercise.

Most other differences are just difference in experience. It'll take a smart programmer+ no time to learn enough about CS theories to adequately solve that 5% of the most difficult part of the job.

+ By smart programmer, I mean someone who have enough intelligence/discipline to graduate from rigorous CS course, but did not.

A formal CS background gives people a very valuable toolset with which to program. It's something you can't fake, and if you know what to look for, it's instantly recognizable.

But if you don't have a CS background, yeah, I could see why it would all look the same to you.

A CS person can easily learn programming; it's second nature to them. But a programmer does not learn deeper theory as easily. Of course it can be learned, but that's why they teach CS at universities and not just programming—it's a much more difficult and more fulfilling subject, in my humble opinion.

This is not true, if you've ever seen academic code...

Code developed by actual academics is often terse, elegant and small; produced either due to a sudden flash of enthusiasm or because of a deeply held and significant urge to demonstrate a point. This kind of code is often at the core of what is known as "academic code".

The bulk of "academic code" is developed by a sequence of postgrads, pursuing individual goals and code is handed round with a mix of suspicion and over enthusiasm, and dropped and adopted according to the whims and short term needs of semi engaged investigators who are make do and mending with budgets and partners. So, by any sane standard it's bad.

On the other hand, it isn't meant to be adopted and used in the long term, and if you are looking at it at all it's because it does things that will be very expensive to replicate, and no one can afford to do a clean rebuild on. So - don't dismiss it if you can't afford to bin it.

Not all comparison are good. I agree that playing music requires skills that you probably don't have if you only studied art history, but this is absolutely not true when it comes to CS and SE. CS and SE both have to do with abstraction, languages, logic, models ...

In my experience, it's easier to teach a programmer CS theory than the other way round. At least the programmer knows what he doesn't know.

All I know is that I look for it when hiring. A Berkeley, Stanford or MIT CS student has a very high weight. They still have to prove themselves, but they definitely have a head start in my book.

I believe this is why so many without strong CS backgrounds are successful as programmers: They bring the design skills often lacking in CS graduates.

Really, it's not like saying an Art History major could easily learn to paint as much as saying an "Art Practice" major could.

Also, I've found that more CS-oriented people often have a good grasp of software engineering--designing programs, keeping them maintainable, ensuring correctness and so on. On the other hand, non-CS people tend to lack knowledge of theory unless they go out of their way to learn it (and most, unfortunately, don't seem to). It's much easier to get by programming at some company without knowing any theory than it is to learn CS without knowing how to program.

Now, there are obviously CS people who spend very little time programming. But, in my experience, they're relatively rare and tend to stick to academia. Really, they're more like math major who happen to like CS than anything else. The ones like that I've met here also happen to be some of the smartest people I've ever talked to, but that could just be a coincidence.

But there is a style of thinking that can come out of a study of computer science that can be very difficult to obtain on your own, and enable you to build larger and better systems than all but the very, very, very best of self-taught programmers, and while it's hard to put that difference into words, it's mostly the study of maintaining invariants in the code from both a theoretical and a practical standpoint. Or, if you prefer, a way of thinking that helps create and enforce a mathematically-strong form of conceptual purity in your code.

Those who don't have this background, and I very much include people who took the courses but just sort of skated through without absorbing anything, will often have problems with any API I create that requires certain constraints, such as being careful at what point they access local information vs. remote information. Their use of the APIs will be sloppy and hacky, because they don't really understand how they work or what they are for. The constraints I am thinking of are purely technical, a particular server/client split, so when I say you can not do X it is not merely me being an academic prick, it is because it is actually impossible to do X because at the time your code runs you are literally in the wrong place. Explaining this fact is easy, but explaining how the system conceptually wraps around this constraint and works the way it does is a challenge.

And APIs designed by such people, while they may get the job done, tend to be very brute force (for lack of a better term) and to lack any sort of firm foundation, such that the moment a requirement even slightly changes we have to make massive (and often hacky) changes to them.

Unfortunately, it is impossible to provide examples in the scope of a single post, because all small examples will not show the issue. It's a larger pattern of issues that tend to start interacting with each other, which is where the real problems emerge.

It is also the case that a proper path chosen through a computer science program will take you through some eminently practical theory that will make you a vastly more powerful programmer, and is very hard to pick up on your own. By far the biggest example of this is compiler theory. If you are currently in college and still have the opportunity to take your local compiler course, take it. I don't write very many "compilers", but I have now written quite a few "interpreters" and it has enabled me to complete projects that could not have been completed any other way. Getting a formal grounding in signal processing is also a good idea, that one can be hard to pick up later and has surprisingly useful intuitions for a lot of high-speed networking tasks. A formal grounding in networking can be good, though a lot of courses unfortunately seem to just march through TCP and the OSI model, which you could relatively easily just read about.

The fastest way to obtain this basic understanding if you are a good programmer but lack the formal education is one of really, honestly working through SICP (and not just reading it), or becoming fluent in idiomatic Haskell, with special concentration any time someone talks about "enforcing invariants via types". (Personally, I believe Haskell has completely supplanted Lisp as "the language to learn to expand your mind even if you have no intention of using it", but be sure you stick with it for a bit. Learning how to string together a couple maps and a fold is not where the interesting stuff is, it's what the interesting stuff is made out of.) Also, break yourself of the subconscious idea that academic === useless. As someone who tends to straddle the border I will completely agree it isn't all useful, but it isn't by any means all useless either.

And just let me reiterate as my closing point that it is absolutely possible to go through even a very good Computer Science program and fail to absorb the useful lessons it has. Presumably these are the people claiming it's "useless". I have to admit I tend to not have a high opinion of people who managed to go through a solid program and come out with nothing. (There are also some complete wastes of programs, so YMMV.)

This isn't to say that Haskell is the only mind-expanding language out there, but it sure is good and it worked for me. I think it makes it especially easy in this regard over ML or Lisp in the "mind-expanding" game because it has so many formalized computational concepts that are first-class and upfront. That's not to say that you can't expand your mind in other languages, but Haskell can really help you out if you're willing to roll with the learning curve.

I disagree with this statement. Python's introspection, first-class functions, magic methods, and duck-typing add a lot of the dynamism of Lisp, but every time you run up against something that needs to be a macro, it's a dead end. C has a rudimentary macro system that can get you a little past that point; for example, it's not too difficult to add a foreach construct to C that looks like this:

    queue *q = queue_new();
    queue_add(q, 1);
    /* ... */
    foreach (int i, q) {
        printf("%z\n", i);
    }

I disagree. In Python, you have much more advanced metaprogramming facilities, depending on what kind of effort you wish to go to. You have the normal introspection, magic methods and metaclasses as you mentioned (which, IMHO, are in themselves already much more powerful than what you can do with the C preprocessor). But you also have access to exec and eval which lets you do all kinds of crazy stuff that isn't possible with C macros. Using operator overloading and classes, you can even create a lot of new syntax which isn't possible in C[1].

Finally, if you are really determined, you can even hack semantics of existing Python constructs by instrumenting the bytecode. For example, I saw a hack which adds tail-call optimization to Python functions this way (iirc as a decorator).

[1] One example is python-pipeline: http://code.google.com/p/python-pipeline/

I have worked with extremely intelligent CS graduates. When it comes to the really involved algorithmic work they leave me in the dust. However every programming job I've ever had has been focused on the other stuff like writing tests and building clean abstractions and maintainable code 99% of the time.

When it comes to this stuff CS grads are no better than any other programmer. In fact, new graduates are often worse because they've never had to build and maintain massive systems over any significant period of time.

Person A spends four years getting a BS in CS at a top-tier school, learning about programming at least for a few hours a day on average, with the benefit of a well-considered curriculum and instruction by wizards.

Person B spends four years working full-time on something interesting at Google, which probably gives her more total hands-on-keyboard time, and also access to some minor wizards, although they may not care so much about teaching her.

Let's say that both of them also spend a bit of time on the side learning programming things not school- or work-related.

If both of them have an equal thirst for knowledge, I just don't see why person A is likely to become a better programmer, or why B would fail to pick up the style of thinking you described (which is common, in my experience, among good programmers.) I honestly think that you're mixing up the consequences of {smart, curious, motivated, spends a lot of time programming} and {took a CS degree}.

Real world might be different, but I don't think a CS degree should be teaching programming at least for a few hours a day. IMO that would be a total waste. There are bazillion of things to learn - database concepts, discrete maths, networks, ai&ml, digital electronics, some basic circuit theory, operating systems...There is programming involved in almost all of the courses, but the purpose isn't to learn about programming. When I am learning about MVCC, I am least concerned about learning programming, but the MVCC concept itself.

Oh, and this expands my Haskell point: http://www.jerf.org/iri/post/2908

However. There is definitely something to be said for SOME kind of structured education for developers. The author's anecdotal evidence notwithstanding, I have met many aspiring self-taught programmers who just don't have it. There seems to me to be a strong correlation between a person's drive to learn something and their willingness to pursue a formal education... not surprising if you think about it.

I also know an absolute genius programmer who is 99% self-taught. But just because people like Wozniak exist doesn't mean they're the norm.

In regards to the SaaS class: I know a bunch of people who took it before it was offered online. Perhaps surprisingly, most of them did not find it useful. The issue is that they picked up everything taught there either on their own or in internships; they really didn't need to waste a whole course on it. That said, the particular people I talked to are some of the better EECS majors who tend to have significant projects of their own and good internships, so there is certainly some bias.

I once worked with a brilliant programmer who was studying Classics and English Literature and he had an entirely novel approach too, and brought real value to the team.

That's the cool thing about programming -- it's an abstract thinking skill, so anybody with any sort of formal training will bring their specific ways of working and thinking into the game.

If you stumble upon a problem that cries for a trie or a splay tree and you don't know they exist, you'll have a very difficult time solving the problem with adequate performance.

If you are lucky and dedicated and talented you might end up with something similar, but it'll take you a lot longer than one who already knew they were there and how and why to use them. Likewise, if you have been trained in developing algorithms, you know what are the important things and which aren't, and have a toolkit to select ideas from.

Of course, outliers do not invalidate the thesis.

Caveat: These problems might not happen often in less data intensive domains but, when they do happen, they are certainly very important in my experience.

And the question arose from the claim that the formally taught and self-taught programmers take different approaches in general. It goes without saying that a problem that can be solved effectively using a trie will be approached in 2 different ways by someone who knows tries and someone who does not. The claim made in the OP was broad, and I am saying about 80% of the time, an auto-didact and a CS person will solve it the same way. Claiming that because sometimes a CS person can use insights which the non-cs guy doesn't have doesn't equate to different approaches.

It's possible to get the same end result most of the time (especially if the end result doesn't require the "clever" solution), but I would also agree that there definitely is a difference in approach that is discernable by watching someone work.

Starter finisher bug fixer architect

In many ways I think these are the sorts of things that are influenced by your background. People with a CS background tend to be better at the architecting side of things in my experience. The self taught are better starters because they are super comfortable learning new languages and enjoy the thrill of the new stuff. Some of the best finishers I've ever met tend to be EE folks.

I think this is possibly as much about their background as it is about the personality types that choose these different paths. That said, lets look at the coding style. The EEs I've worked with have all written extremely "simple" (This is not derogatory) code that was easy to verify and tended to not use as many "high level" features. The self taught programmers I've worked with write amazing code using some cutting edge shit that looks great and usually works great... but often don't think about optimization until the very end.. some times to the detriment of architecture and design. The CS folks will tend towards over optimizing up front and getting caught in the pre-optimization trap. They may over design it up front and tend towards some middle ground between "simple" and "cutting edge" that half the time ends up being worse than either of the other methods.

This is of course an over simplification and doesn't fully capture all of the differences I might've noticed.. it's simply an example and obviously I understand these are generalizations that won't always be true, but it's clear there are differences.

Additional example, if you want to know what a bunch of different grad students specialize in stick them together on a moderately complex project and just watch which items each person obsesses about. Some will obsess about network latency, some may obsess about the cache performance, others about security. We need all of these people... but it's clear they will hone in on different items.

That's been my experience as well, but I think it's mostly because of the three types, EE's are the only ones used to making schedules and sticking to them.