A chapter in Virginia Postrel’s book Dynamism asks the question: What classifies something as “work”, and other things as “play”? This is one of those trick questions which seems like it has an easy answer. The first thing that pops to mind - “You get paid to do work” - fails right away. I don’t get paid to do my dishes at home, but that’s definitely work. I do get paid to build software, but quite often a lot of that feels like play.
The book is excellent, so you should read it; but I’ll spoil the answer for the chapter in question: work has specific goals to be achieved, while play is freeform. If someone hires me to build the a web application, it’s work because there are requirements and deadlines to be met. Perhaps I’m given a fair amount of creative autonomy, but when we get near the end, some sort of basic goals (defined by the person forking over the cash for the project) must be met.
I might, however, build a very similar app as a personal project; and this would qualify as play because I’m responsible for nothing but pleasing my own curiosity. I can take a six month detour learning a new language or screwing around with a different visual style. I can decide halfway through that I don’t want a web app after all, but instead a web service, or maybe I really just wanted to paint a painting.
Why is this important? We know that most people are happiest when they have the right balance of work and play in their lives. But play serves an important purpose: it’s a chance to experiment, to learn new skills and techniques, to develop new patterns and approaches. This then feeds back into our work, because we can take the most effective techniques discovered during play and put them to work achieving the more concrete goals of work.
As developers, this is pretty obvious. If we focus all our energy on work projects, that means we don’t have time to try new technologies or new techniques. When you’re focused on a goal, you don’t have time to tinker. But tinkering is how we learn. New technologies are rarely a swap-in replacement. If you tried to use a non-relational database in your next web app, that means you have to rethink the role of schema, migrations, queries, and validation. Sometimes there are direct equivalencies for commands, and this is how people new to the technology tend to use it. That’s why Ruby written by someone who just came from PHP tends to read like PHP, and why someone using decentralized revision control for the first time will tend to stick to the commands and techniques which closely match how things worked in a centralized model.
At my last company I did a lot of hiring, and one of the most important questions I asked people was: do you have a personal project? If the answer was yes, I wanted to see it. The candidate was usually reluctant, because they thought of any such project as being something silly or unimportant. After all, it was just for play. One person I hired was a fanatical watcher of the show Smallville, and had built an imdb-like cast and episode tracker. She was reluctant to show it, but it impressed the hell out of my and we hired her. Another candidate showed us a site he had built that cataloged downloadable PC game demos. The site was very amateur in its visual style, but he had built his own in-place editor framework that was quite impressive, considering that this was pre-Rails and pre-ajax. We hired him too.
At the time I thought that I was so interested in personal projects because they showed personal motivation, the ability to self-manage, and a love for software development that extended beyond just the potential paychecks. Those things are true. But thinking about Postrel’s definition of work and play, and the importance of play in learning and personal growth, I now see what is possibly an even more important reason to ask to see a candidate’s personal project. Someone who pursues personal projects is going to keep learning, trying out the up-and-coming technologies and figuring out how to integrate them into their work process. Someone who is 100% focused on work work* all the time is fated to have their skills slowly fall out of date.
* That's not a typo: saying words twice in a row changes their meaning. I believe this was pioneered by teenage girls, as in, "Do you like him, or do you like like him?"