The Myth of the solo game developer

Many Game Engineering programs get their students working on complete games, taking entire semesters or even a year to develop a fully functional title.   The rationale is that they need to learn all the aspects of game development from graphics pipelines to AI, game logic and Sound in order to be good developers.

No they don't.

Unless they are completely going indie with Mom & Dad's savings the day after they graduate there is no way we are going to let a graduate new-hire take an entire game project start to finish with.  That isn't where you start and nobody in the industry has the expectation that you will.

Our assets - intellectual property, development cash, and audience are precious.  We don't just drop them at the feet of someone new and say "go get 'em kid".   Actually, I don't know of many seasoned developers that have or expect that kind of latitude.

No, what a new engineering candidate gets to work on is maintenance code.
It isn't dirty laundry, it isn't scut work, it isn't menial.  It is important work that needs to be done.  They'll be working with existing audiences, products that still deserve support, or maybe helping port a title to a new platform.

 Working with someone else's code is probably the majority of work that is done in the industry.  Refining, debugging, and maintaining someone else's code is just something we all do.  It is a great way to learn shop coding standards, best practices, and different ways of thinking about problems.  There is also the potential for creativity if you have a better solution and a little management buy-off.

So why is there so much emphasis on original code creation?  Is this a Myth that has been around since the Doom days and lives on only in game schools?

In my ideal curriculum you would start by modifying, refining, and improving existing code that was built with (known) flaws in it.  Later, removing modules and replacing them with your own improved versions.  You'll get experience with debugging tools, analysis, and reading lots and lots of other people's code.  (This a solid work practice in our industry, so applying it to engineering coursework should be low-risk and straightforward implementation).

My (Untested) radical approach would be to take small existing games with built-in flaws and known performance characteristics and give you a grade  based on the performance of your improved product.   My rail shooter chugs along at 50msec per frame.  If you get it to 20msec you get a B, 16msec you get the A.   You turn in the running application and a diff of the code to show your work.   Have students break the games in new and subtle ways as an exercise for next year's class.