My attention is thusly turned towards the next three months. I don't currently have a job sorted; the folks I was talking to have apparently become unable to hire me (though they assure me they would very much like to), and the place I worked at last year haven't yet gotten back to me. (Hopefully I just need to drop them another mail to remind them).
There are other avenues, of course; I don't have to work in the games industry this summer. I could do freelance contract coding online, but it's hard to find contracts that pay decently. I could just spend the entire summer working on pitches for Xbox Live Arcade games and try and persuade Microsoft to take me up on one of them - would be nice, and would probably pay the best paying overall, but is also high-risk because Microsoft get hundreds of pitches for XBLA so the chances of me ending the holiday with nothing to show for it is quite high. I could just work on a PC game and try selling it on the web, but similarly, there's a high chance I'll end the summer with a half-finished game and no money. I could also work on my demos for my portfolio; that'd probably be the most fun, and would be useful down the line, but wouldn't get me any money at all.
One thing I've been considering is writing a book, an introdution to programming type text. I'm not at all content with the current state of introductory texts. There is too much focus on making things happen on the computer ASAP; and because even a simple program like a C++ "Hello, World!" can't be written without touching a multitude of concepts from include files to namespaces to functions, the programs are just given and comments are added saying "Don't worry about what all of this is doing, we'll explain it later, just copy it out and it'll work." Newbie programmers should not be starting with copy-paste coding.
Also, the problem with teaching programming via the teaching of a particular language is that the programming becomes 'tainted' by the specific idioms and details of that language. It becomes difficult to separate the general programming concepts from concepts specific to languages. A concept like pointers gets in the way of the more important concept of named storage. Things like garbage collection obscure what's actually going on with memory. It works out OK if you know about these things beforehand, but if you're covering things as you go along, it can get very messy.
So, if I were to write a book, it would focus on key concepts first - basic problem solving ideas (e.g. my previous assertion that any solvable problem has an infinite number of distinct solutions), data, dataflows, types, etc - before any actual code gets written. Code fragments would not be restricted to any one single language; they'd be written in whatever was most appropriate for the concept being illustrated (so there'd probably be some Haskell and C in the type chapter, while the basic control flow stuff would likely be easier in Python).
So yeah. That's an option.
Oh, and my debugging article is up. Hooray!