in reply to Learning by Doing

There are two things I always do after "Hello World" in a language I care about.

a) implement Conway's Game of Life. Optimize as best as possible. Make it look shiny. For some reason, I like to try graphics development rather than SysAdmin type scripts first...gives you a sense of gratification. In Perl, play some with Perl/Tk or maybe explore some other GUI things.

b) implement some random game. Games have tons of seemingly impossibly hard problems to solve, and they'll end up creating problems you don't know how to solve initially (that you'll have to think about for a good while). Plus, games are fun, better than itch scratching. I typically try for hard things, like a clone of "RC Pro AM" in 3D, an AI for a board game like "Abalone", or a game like "Civilization" or "FreeCiv". In each of these areas, there are challenges that cannot be immediately grok'd and you have to bend your ways around the language to find good clean solutions. Plus, you'll never finish. Games can be expanded and improved forever.

You might never finish B, but every time I start a program that I don't finish, I learn a lot along the way about how I should have started instead. That is, learning by making mistakes, redesigning, finding new tools, new optimizations, etc.

Anyhow, someday, I'll make a nice game that everyone will want to play again. I haven't had that success since I wrote an excellent version of MineSweeper for my TI-85 calculator in 1996. But hey, that's how I learned to write for the '85, and that helped out a lot for Calculus and Physics (which needed real world programming on that calc), paving the way for me to pick Computer Science as a field. I may write boring apps at work, but occasionally I'll start a nice game project, and I'll feel that love for the art again...and I'll learn new things.

Just doing it for a job doesn't mean you'll learn it, you often get caught in the same old ruts. Rinse, lather, repeat, you know? Push the envelope.