Most academic departments don't dedicate classes to practical skills, but they do acknowledge them in curriculum planning. A history major won't see "How to structure a research paper" on the syllabus of any class they take, but that doesn't mean the professors don't intend to teach them. How to organize research notes, how to read a book, how to structure a paper or a program, and so on are supposed to be learned alongside the academic subjects that are listed on course syllabuses.

There's a limit to what can be learned in college, though. You can't teach CS undergrads patterns of enterprise architecture in a meaningful way any more than you can teach history undergrads the craft of writing a book when they're still only writing papers. Teaching them to absorb rules of craftsmanship without any personal experience to judge them by will only encourage them to become astronauts and "best practices" prigs. (Not to mention that the professors themselves might be relatively inexperienced and mediocre at those things.)

Unfortunately though, the desire to make curricula that are practical is increasingly infiltrating CS departments, only the academics have no idea what is practical, and end up teaching the language du jour that recruiters happened to be looking for 5 years ago which is out of date by the time students graduate.

The best thing that can be taught to undergraduates is the first principles of the field so that they at least have a solid foundation to build on.

I lament the loss of courses built on Structure and Interpretation of Computer Programs - one need only read this post by Joel Spolsky to see similar sentiments expressed:

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...

I think exposing students to architectures and patterns can't be bad. As a student myself, I'm glad to have this exposure as I can now look at frameworks I couldn't really understand before, and at least make some (more) sense out of it. I can recognize the way things are named and organized.

Also, when facing a particular problem in a project or homework, instead of unconsciously reinventing the wheel, I can refer by name to a solution that is already implemented, or at least be aware that I'm reinventing a wheel.

While I'm not about to design an Enterprise Application by myself, I think I can at least work in such a context and understand better where's my part in the whole.

*

In my previous life as a platoon commander in the army, I was specifically trained to command a platoon. I was however given exposure as to what higher levels were doing, so that I could work with the whole formation.

Thanks for that bit of perspective. If every thread like this had a comment like that at the top we could all get where we are going a lot faster.

Same goes for the article. The author clearly thinks that these books have helped him succeed but unlike some essays there is no sense of him dissing other approaches. "that meant the most to me" He succeeded. But he didn't lose his perspective.

I'd say software is becoming more 'specialized'.

My alma-mater (UBC.ca), the CS Dept touches a few subjects:

- Design Patterns (still using GoF, which is probably not the right fit for 3rd year students)

- Refactoring (we do refer to Martin Fowler's book albeit we don't dig that deep)

- Barbara Liskov book (touches a few thing regarding type-systems and its relation with OOP, IN-OUT contract/verification, a bit more academic/formal but most of us saw her work in C# contracts, the L in SOLID principles, some of the OOP best practices probably).