I've long been critical of the way programming is taught in most computer science programs, at least in the US. I've had the opportunity to partake of two: UNC Greensboro, where I was enrolled for two semesters; and Stony Brook University, where I am taking my second CS course (for upper-division credits, so I can graduate this May). Both are excellent schools and excellent programs, with excellent professors and excellent facilities, so the problem clearly is not with the infrastructure. It is with the content.
Content has always been a problem in college or university courses. To much emphasis is placed on learning the language and it's facilaties and less on proper usage of the paradigms that the language exposes. This has always been the case. It is one of the things that I argue with professors about all the time. They teach bad practices because it's to "get the student off the ground." I'm sorry, but a bad practice doesn't get them off the ground, it gets them fired. Best to learn it right the first time than to have to burn out bad habbits that have formed over months or years of being taught wrong.
The problem? An overemphasis on "subsystem reimplementation." In today's software development environment, integrating subsystems and architecting elegant larger systems are by far more important than writing yet another memory manager or windowing system or renderer or linked list or sparse matrix. Teach these kids to think about how to solve problems, show them common data structures (allow them to implement a few, ask them to reason through the rest without implementing), then set them to work building systems from standard implementations.
Implementing subsystems is one of those things that should be kept in your datastructures course, and that's about it. You should never be required to implement your own set, map, array, or other container after you've taken DS. Even before taking data structures, you should have been introduced to your languages standard library and taught how to use it. You don't need to know how it works, just when to use it. The datastructures course will tell you how it works, and hopefully information on when and where to use it.
On the topic of proglem solving: That's what we are. Anyone who enters this field thinking that we program for any other reason than just to solve a problem needs to be taught otherwise. But problem solving should involve more than just building systems from standard implementations of data structures. 90% of the problems you will encounter have a text book solution, it's the 10% we should train them for. Because that 10% is what ends up pushing deadlines. It's also the part that ends up being the buggiest.
The most frequent and most pitiful question asked in the beginner forum, beside "Where do I start?" is "How do I put it all together?" And the truth is, we don't have enough resources on putting it all together.
I think you forgot the "I've got a great idea for an MMORPG..."
I remember the first time I picked up 3D Game Engine Design. I was thinking, "Yes, finally! A book that talks about how to put it all together!" Boy, was I wrong! And I wasn't the only one, so much so that Eberly wrote 3D Game Engine Architecture, which I haven't yet read, when he realized that lots of us had different expectations of the title. (See our video interview with Dave Eberly and Tim Cox of Morgan Kaufmann at the GDC for more.)
Never read it. I'm a traditionalist for programming books, I got to the publishers that have never let me down, like Addison Wesley. However, I do have the first two gems books. I wasn't overly impressed with them, as I found most of the knowledge they contained to be common sense, or something that had been better covered in other books. It's a nice collection of googling material though.
Software design remains an understated area. We vaguely say things like "be sure to design your system before you start implementing it," but we don't teach the necessary design skills or tools with anywhere near the fervor that we teach the math and coding skills. Most college CS graduates have taken precisely two courses that touch on design techniques like Software Development Cycles and tools like UML. Witness the relative unpopularity of our own Software Engineering forum.
Well...ok, now this is a subject close to my heart. Design is one of those things that takes experience to get used to. But at the same time, introducing design concepts at a beginners level is a perfect oportunity to ingrain into the fledgling programmer that little seed that will bloom into an all out design freak. Of course, you do have those people who see design as just a full set of UML diagrams, and forget that a design will evolve and grow as the system is built. You will never be able to document your entire system in UML from the start. Best to leave that to a program that can synchronize your class diagrams with your code. On the other hand, I've found that a lot of professors don't really know what design means. They see it as just "thinking about how you should solve the problem." Which isn't really correct. It involves a lot more than just the "problem" but also how this "problem" will integrate with all of the other problems that you don't have control over.
Lets face reality though, most of the young programmers that come here won't be in a team for months, if not years. They will be soloists. This does not work well in building up team based skills, of which design is one of them. It's a touchy subject really. But it's one that we, as a site should be covering. Heck, we could have a whole series on team building, team communications, and coordinating efforts over a wide area. If you think it can't be done, look at Unreal. They were spread out all over the world for most of the development time. It wasn't until the near the end that they all had to get together to coordinate their efforts and finish the engine/game.
Of course, there are the language wars that you have to deal with as well. I mean, I learned basic...god only knows how many years ago, and have been doing C++ for about 15 years now. It's been standardized for half of that. So what's my point? Simple: Look at the number of C# vs C++, or Java vs C#, or Java vs C++ threads on our boards currently, I can think of 3 off the top of my head that I have seen within one week of today.
Young programmers have been told that they should learn "a language." This inheritly limits their ability to understand or comprehend new design concepts, as they are stuck with the limitations of the language they have chosen. Not only that, but most will not learn another language. We shouldn't be discouraging them from learning other languages, but all to often you see someone post: "No, use language XYZ, as language ZWQ is [false information here, or atleast mostly incorrect]." Now, there isn't much one can do to stop such things, atleast not without being accused of being a nazi mod [grin], but it still bugs me.
We need a greater emphasis on architecture and engineering, here on GameDev.net, in the game industry (all aspects, including indie development), and in computer science in general.
We need more than a greater emphasis, we need the materials to back it up. We need the articles on XP, on Unit Testing, on Source Control, and team building and coordination, on content management. We need the software, to allow gamedevers to form teams around our site, manage their content from our site and distribute that content from our site. Heck, even open forum style lessons would be of use.