Sketching with Code

Getting good at getting fast

I’m about to write up my research for NESTA/Clore’s paper that set me off on the task of researching culture and hacking. Time to have a look back.

Attending the Culture Hack series of events has had quite a big impact on my life. I now hack for a living!

Obviously that’s not directly attributable to Culture Hack specifically, but looking back it’s clear that “getting good at getting fast” has been something I’ve been focussing on, and I’ve not really talked about that enough.

“Getting good at getting fast”, not “Getting good” or “Getting fast”, or even “Getting good at being fast” - it’s a focus on self-improvement, working out ways to reduce the time it takes to evaluate an idea, improve productivity in the tiny amount of time available for a hack, but mainly about improving the way that you think about how you get fast.

I’ve got a little “stack” of software and approaches that I have developed or found that help me make a web app very quickly. I steer clear of things that require some kind of “native” application to run directly on a phone - that kind of thing can come later. Working in a browser makes whatever I do much more malleable. I use Javascript and Ruby, and I’ve spent a lot of spare time playing around with frameworks, gems, libraries and other free things I find on Github (which in my opinion is going to only grow in what it contributes to the World, which is already pretty amazing - watch them).

I’ve watched myself as I hack. I get fired up on an idea. I try to get something on a screen as quickly as possible to get a “oh wow! That was quick!” reaction. I’ve also extended that to “get it online as quickly as possible”. Even if it’s just a word on a page, getting something onto the internet quickly means you’ve got past those irritating deployment issues that slow you down at the end and get demoralising. So I use Heroku, I use MongoLab, I use Typekit. Basically grabbing as much for free as possible…

Then there’s deciding on the idea - focussing really quickly on the tiniest little thing that you’re going to build to test an idea, leaving everything else on post-it notes under a sign that says “Featureland”. Using humour gets everyone fired up about an idea and often means you get much better resultant hacks. If the people you’re working with are laughing then others will find the idea at least a little bit interesting.

I guess that’s why at a hackday I now try to do about three hacks. One to flex muscles and build a team of people and show quick results, then give up when it’s done it’s job and is demonstrable, move onto something more ambitious, and then at the last minute see if you can knock out something in a couple of hours that helps make sure that all of the sponsors/data providers leave the event with at least one hack each - basically filling in the gaps.

Rohan from Sync has a good write-up from Culture Hack Scotland that triggered me to write this. After doing that hack I applied for the Eigg residency, and there’s been obvious similarities to the way I worked on that hack day to how I approached the residency - tiny, quick projects that demonstrate an idea, that could turn into much bigger things potentially.

Since then I’ve been at Comic Relief, in the Exploralaboratorium and it’s a similar approach - Monday starts with an idea and a day of playing, two days of hacking follow, a day of user feedback and iteration on Thursday, and a demo presentation to the staff of a finished, deployed hack at lunchtime on a Friday. A product in a week, each a hack - a demonstrator of what’s possible, and each with a set of questions that will be tested by putting the thing in front of users.

And that’s the main thing - doing things quickly means you’re only going to get the tiniest beginning part of an idea out into the world. It won’t be all-singing all-dancing, nor will it work on all devices, and fulfil all the various criteria that a full product might need to fulfil. But it’s a quick start, a quick way to test whether you should bother doing any more work on something. If it works, like the Data Necklace, which got lots of attention, then you follow through. If, like Yebay, you get a bit of a giggle and then nothing, then you shouldn’t do anything further with it and move on.

That “do it or drop it” decision is crucial to the “get good at getting fast” approach. Most of my hacks I drop after a little while, having learnt something, but occasionally they’ll turn into something big, and that’s the point where you need to think about what you want to happen after the hack. But that’s the subject of another post.