To be fair to academic code, it's typically used once to prove a point and then thrown away. It's a lot like an R&D project any of us might do that will either be rewritten later or just used to test a theory and then forgotten.

Academics are notorious for their code, but I suspect the parent was talking about people in industry with a CS background.

I think some more fairness is needed here - Academic code is often bad in absolute terms, but excellent if you understand the requirements and process that produces it.

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.

It would be like saying an Art History major could "easily" learn to paint. The skills just aren't transferable.

> The skills just aren't transferable.

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 ...

The skills of "programming in the large" are hard-won through experience. There is no good "theory" that will help you structure a large program (despite many languages from academia making the claim of good structure). That's just one example.

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.

I think you misunderstand what I mean by "theory" and "theoretical background." Knowing how a computer works from the silicon level up to the operating system helps you design systems, and starting with that foundation helps you build better systems. You can get the same experience after a theoretical education, but you can't fake a theoretical basis from simple experience. You're right that you can learn it, but in my opinion, having the theoretical foundation is key to getting the right type of experience, and also helps you immensely along the way.

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'm not sure I agree. For practical programming, design is one of the most important skills that you need. Code that is ugly is automatically unmaintainable, no matter how theoretically sound. The text editor is your canvas, it is your job to turn out a work of art.

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.

At least at my university, you can't get a CS degree without a significant amount of programming. Everybody--even the theory people--gets a thorough background going all the way from high-level programming through assembly and even a bunch of EE (it's technically an "EECS" program). Then everybody who isn't specializing in EE or very interested in CS theory does a lot of programming in more advanced courses. On top of this, most people work on some research which also tends to involve a significant amount of programming.

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.