I’m a big proponent of play as a means to grow and succeed. In my career I’ve spent endless hours building things that interested me with no thought of recompense or acknowledgement, simply to broaden my knowledge on a particular subject, or chase a particularly intriguing idea. Play provides you with a fun method for exploring your medium without risk or judgement. It also allows you to build the things you wish people would pay you to build, and market the results to help steer your career.

In my conference talks, I frequently encourage others to experiment with interactive media. At first, I would often be asked “where do you find the time?” In answer to this, I started talking about an approach I call “Passionate Procrastination”, which simply involves using time you might otherwise spend procrastinating to build interesting experiments. We all have those moments in our day when we need to step back from the task at hand and let our brains mull things over. I proposed that rather than read Digg, watch videos, or surf Facebook, that time could be used to work on something else that you are passionate about.

When pressed further, I started talking about how little time was actually required. Twenty minutes every day gives you three full work weeks per year to apply to experimental projects. Considering the average American watches more than twenty minutes per day of advertising, this time shouldn’t be that difficult to find.

This seemed to convince most people (or they simply stopped asking) until today when I was yanked unceremoniously into a dotBrighton meeting via Skype and posed a question from an attendee regarding my recent talk at FOTB (I think his name was Paul, but I was a bit distracted, my apologies if I got it wrong). He cited my twenty minute figure, and asked how I was able to accomplish anything in that little time, given that it typically takes a good five or ten minutes to really ramp up on a new task.

I thought it was a great question, and that it warranted a more coherent answer than whatever I mumbled over Skype at the time. For me, there’s three parts to how I use this time effectively:

Firstly, that twenty minutes is an average that I only use as a demonstration of how little daily commitment it requires to accumulate a fair amount of play time. I would guess that most of my experimentation sessions last between 30 and 90 minutes, but I definitely don’t do it every day.

Secondly, it’s important to have a goal ready for when you decide to take a play break. I maintain a list of ideas in a text file on my computer, and glance over it regularly to keep the concepts fresh. I try to think through the implementation of these ideas during AFK (away from keyboard) times, like when I’m showering, or lying in bed trying to sleep (these are my two most productive idea times). This way, when I have some time to play, I’m ready to jump right into writing code and testing if my ideas work.

I also try to disassemble my implementations into small, easily-achievable sprints and accomplish one or two of them during a single break. This helps define and limit your time, as well as giving you a sense of accomplishment which can help propel you when you return to your usual work.

Thirdly, most of my play time is while procrastinating on other work. This means I already have my tools open and ready to go. In fact, I’ll often have a real project and an experimental project open at the same time, and swap over to play when I get momentarily stumped on real work (or just need a quick break). You mileage on this may vary depending on your work circumstances and your boss.

Play offers so many benefits, and it really helps keep working with technology from becoming mundane. Finding time to do it is likely easier than you think, even if it means missing the next Old Spice ad. I’m on a horse!

It’s worth reading through the first four parts of this series if you haven’t already: “Introduction“, “Hiring“, “Orientation“, and “Training“.

Once we’ve finished subjecting our new hires to a week (maybe two in future) of classroom training, we turn them loose on an internal project. The core goals of this exercise are:

• Familiarize new hires with our process and all the steps that go into a project.

• Apply concepts learned during formal training, and continue their technical growth.

• Begin developing their competency in critical secondary skills including estimation, time & project management, project planning, user experience (UX), leveraging existing resources, effective communication, QA and issue resolution.

• Develop skills with tools including development tools, SVN, and Basecamp.

• Start them thinking about value and business considerations for projects.

• Force them to respond to feedback and changes in an agile, responsible manner.

The trainees are informed about this project on their first day at work, and reminded of it throughout their first week so that they can brainstorm ideas in advance. They are also encouraged to run their ideas past people to get feedback. Over the course of the second week they then develop a full project plan, which is maintained and organized in Basecamp.

At the start of this phase (usually the first day of their second week) the trainees are asked to solidify their concept(s) for their internal project, and prepare whatever materials they deem necessary to present it.

The only requirements for the project is that it fit in a 2-4 week timeline, and that it provide value to the company. This value can come in a number of forms; it could be useful, have market potential, have promotional value, contribute to the knowledge of the company, or it could just advance their training in a significant way.

At the end of the first day of this phase, they present their concept(s) to the senior staff, and are presented with feedback as to its viability, value, and implementation. They then revise their concept based on that feedback.

Next, the trainee develops wireframes, defines user flows, and identifies any data requirements for the project. Again, this is presented to available senior staff and revised based on feedback. In particular, we focus on the appropriateness of the user experience, and the completeness of the wireframes, flows, and data requirements to ensure the trainee has a good understanding of the full scope of their project.

The trainee then moves into doing some high-level architecture. They prepare a CRC outline (classes, responsibilities and collaborators), and an I/O spec (input / output for a web or local service). Once again, this is presented and revised.

With the architecture approved, they write up a project plan that includes a timeline, with milestones and micro-deadlines (ie. goals for each day or two).

Once all of this is complete (generally on the Friday of that week), they present their complete project plan (wireframes, architecture, I/O, timelines, etc) to the entire team for feedback and criticism. This lets them receive and filter a range of input, as well as letting them see the more experienced members of the team disagree and debate different ideas.

With their plan complete, they are ready to move on to production, which is the focus of the next article.

If you haven’t read the first two parts of this series, “Introduction” and “Hiring“, I’d suggest starting there.

The first day for a new hire is a busy day of orientation. The goal is to get them set up and comfortable with all of our systems, policies, and processes.

First, they get reintroduced to the whole team and educated on everyone’s roles. They learn who to talk to for specific issues, and who will be guiding them through their training.

They start with the administrative side of things. They sit down with our office manager to sign their employment contract (which they receive in advance so we can answer any questions), fill out forms, talk about payroll, benefits, employment policies (lateness, time off, overtime, external work), and general office polices. We put a lot of emphasis on the core clauses of their employment contract surrounding NDA and IP considerations.

Next, they get set up on all of our systems, and receive training on each. This includes:

• Our network, dev PCs, and connected devices.

• Software, what’s available, how to request serial numbers, etc.

• Our email system, webmail, and signatures.

• Instant messaging.

• Basecamp, project tracking, and writeboards.

• Subversion, checking out / in, branching, creating projects, etc.

• Tracking time, and why it’s so important.

Next we walk them through all of our processes. We outline the full training program they will be going through, including informing them of the internal project they will be building (part 5 of this series). We give them a high-level introduction to our process for delivering projects and doing quality assurance. QA receives a lot of emphasis – what are the processes for testing, identifying bugs, resolving issues, and communicating status back to the project manager. We also talk a bit about our policies for using open source libraries in client projects (ie. usually only MIT licensed or equivalent and only with prior client permission).

Finally we remind them of their NDA, and introduce them to all of the current projects we’re working on. This can be a quick overview, or a more in-depth dive into each project depending on the time available.

Before the end of the day, they are asked to enter all of their time into our time tracking system, and are expected to keep this up to date going forward.

The next article in this series, “Training“, is up.

If you haven’t read the introduction to this article, I would suggest starting there.

The first challenge in creating a great developer is finding someone who has the right raw attributes to start with. There are two parts to this: finding candidates and screening them to choose hires.

To facilitate the former, I work to establish connections within the local community. I sit on advisory boards for a number of local interactive programs, I get to know the instructors, I give occasional guest lectures to classes, and I try to contribute to (and in some cases, establish) local user groups. This lets me help steer what (and how) students are being taught. More importantly, it helps me identify the rising stars in each class and in the community.

I look for people who are smart, creative, communicative, and demonstrate a genuine passion for the field. I want someone who can solve problems, and is going to be very self-motivated about learning new things and building cool projects.

Once I’ve identified candidates, I invite them in for an interview. Two days before the interview, I send them code from a small internal project, and ask them to familiarize themselves with it. I also ask them to bring in samples of work that they are especially passionate about, or think best demonstrates their abilities.

Our interviews tend to be very casual. They start by meeting the full team, to introduce them to the people they’d be working with. We sit down, and I ask them a few general-purpose interview questions about their interests, goals, strengths and weaknesses.

I have the candidate show me their previous work, and ask them a lot of leading, high-level questions. “Why did you want to build this?” “How did you plan the project?” “Why did you build it this way?” “Why did you approach this problem in this specific way?” “Why not this way instead?” This lets me judge a bit about what motivates them, their technical expertise, and their ability to communicate.

Next, I open up the code I sent them earlier, and start asking questions about it. I try to ask questions that involve both technical understanding and problem solving, such as why they think a certain block of code was written in a particular way. I also ask questions about UX design, because this is such a critical part of interactive development. I start simple and ramp up quickly, hitting them with questions that are both a little beyond their technical comfort zone and far beyond it.

Throughout this process, I encourage them to talk me through how they are solving the problem. I also teach them about more advanced concepts, then I ask them related questions. This is important, because I’m more interested in how they learn than what they know.

I spend a lot of time just listening. I let them decide when they are done answering a question. It’s pretty amazing how much you learn about a potential hire by just letting them talk until they are done, while fixing them with an inscrutable look. Some people babble themselves into an ever-deepening hole of incorrectness (bad). Some stop, and admit ignorance (good). Some talk their way towards a solution (better). A rare few ask appropriate questions to guide their response (best).

This approach lets me gauge their technical & UX knowledge. More importantly, it reveals their intelligence, creativity, and problem solving process. It also lets me see how they perform under pressure, and how effectively they communicate technical concepts. I also try to judge how well they will fit into our corporate culture.

If things go well, we’ll talk a bit about what it’s like working at gskinner.com, both the benefits (cool projects, bonuses, benefits, etc), and the potential drawbacks (a lot of learning, taking a beating from the team early on, and the odd high stress moment). We’ll also start a dialog on compensation. Sometimes we’ll finish up with a game of ping pong or foosball with a few members of our team to get a better sense for their personality in a more casual setting.

If things didn’t go well, I’ll give them some honest feedback on why, and try to give some suggestions for how they might be able to improve. If I think it’s likely that they’ll be able to rectify the issues, I might invite them to come back in the future when they feel they are ready for it.

Finally, I generally try to hire in pairs, with the same start date. This allows us to train them together, which reduces the time spent and helps with retention (because they can help each other). It also gives them a “buddy” at a similar level that they can identify, work, and learn with.

The next part of this article, “Orientation”, can be found here.

I’m often asked the question, “Where do you find great developers?”. The truth is: I don’t find them — I create them. At gskinner.com we rarely hire experienced developers; most of our new hires are fresh out of school.

We select smart, creative, and responsible new developers who exhibit a real passion for interactive technology and mesh well with our corporate culture. While we do require a minimum level of coding ability, technical expertise is one of the least important criteria. Teaching someone to become a great coder takes time, but it’s relatively trivial compared to trying to instill a love for the work or teaching someone to be a great problem solver, reliable worker, or cohesive member of the team.

This approach allows us to train our new hires exactly the way we want to, without having to convince them to unlearn incompatible practices. It also means they learn our process and integrate well with the rest of the team.

Over the past six years of running gskinner.com, I’ve developed a system for training and evaluating new hires, and recently formalized it into a documented process. We just successfully finished taking our first two devs through the full three month process, and while it’s still not perfect, I’m quite happy with the results.

I thought it might be worthwhile to share an overview of our approach with the community, and will do so in a series of blog posts (eight total, I think) over the next few weeks.

It’s worth noting in advance that this process is only valuable to companies that hire for the long-term. We invest a lot of resources into developing every new hire, so they can become valuable, permanent (as much as possible) members of our team. We treat everyone with respect, maintain a very reasonable work week (never exceeding 40 hrs), provide benefits & performance bonuses, and have very low turnover. If you hire & fire on a project basis, or have high turnover, this process will not help you at all.

Continue to Creating Great Developers part 2: Hiring.