Learning by hacking
I do hacks. Tiny prototypes for digital things that I show to people quickly. And for five years I’ve been doing, on average, one a month. I call it sketching with code. Here are some of the things I’ve learnt.
My general principle for how I spend my time is Create Something Every Day. The “something” could be anything — sometimes a photograph, maybe a drawing of a monster on a birthday card, but more often than not it’s something interesting in code.
I’m always sketching with code, and sometimes, what starts as a little experiment can turn into a mini project that takes a few days to build, resulting in something I can show to other people. I call each one of these things, for want of a better word, a hack.
Hack, play, learn
A hack is a tiny, often throwaway, rapid prototype. It’s a way of demonstrating the very first part of an idea in a short space of time. I build each one to test how I think something could or should work. Others who work this way often talk about hacks as taking something apart and putting it back together in a new way. Others might say they are a way of mashing two things together to do something interesting. Always done at speed, always done with passion, always to scratch an itch and always best if there’s some humour or novelty involved.
Many of my hacks are based on not having much knowledge about something and wanting to learn how it works. Perhaps it’s Dropbox, for instance. If all my files are in Dropbox, what can I make using their API that lets me do things in new ways with them?
I’ve realised that hacking – the process of doing hacks – is how I learn. Over these last few years I’ve learnt much more than at any other time in my life, or at least that’s how it feels. I’d like to share a few of the things that I’ve realised. In general, I think of it as “hack, play, learn” – the bit that comes before the “build, measure, learn”.
Note – I’m not talking about that other, scary use of the word “hack”. You won’t see that ridiculous prefix “cyber-” here.
Do the idea right away, when you’re passionate
I love the really early stage where you’ve just had an idea, you’ve got an inkling about how to do something, and instead of just having the idea you build that first little demonstration of what it is supposed to be.
The best time to do that is when you look at the world, realise that there’s something missing and notice that you’re having excited conversations with people you know. If you’re in that mode, do something about it. For me, I open my laptop in the evening and see if I can sketch out the tiniest, simplest, bare-bones version of it so that I can show other people.
Working when I’m passionate and fired up is the best way for me to get a hack out into the world. If I wait until later, and I’ve worked it all out, it always seems to take much longer, if I get round to doing it at all.
Build to think
My friend NTLK has a saying about this, and it’s worth noting here:
“If I’m not making, I’m not thinking”
The process of making things can actually be the process of exploring the problem. So you’re thinking by making. You’re solving the problems at the point where the problems appear, rather than trying to second-guess everything up front. Get going, solve things along the way, learn about the thing by doing the thing. IDEO, the design agency have a similar motto – “We think to build, and build to think.”
Go to a hackday
I love the excitement of a hackday (or hackathon, although I’m not so hot on that word). If you’re not familiar, it’s a type of event where people get together to make hacks and demonstrate what they’ve done at the end. Sometimes there’s a winner, usually there’s a theme to bring people together – education, culture, the environment, charities, and so on.
I learnt a lot doing these tiny, two-day hacks at events like National Hack The Government Day – amazingly held at a Government office;or Culture Hack – an event all about combining technology people with cultural organisations with pretty explosive effect.
The process of just coming up with things and getting them out into the world within a few hours or days is fun and addictive. YeBay (Shakespearean eBay?) for instance took 30 minutes from “oh that’s funny” to “oh that’s on the internet”.
Surround yourself with hackday people who work this way and you’re bound to pick up some very interesting things.
Nobody is going to steal your idea
The spirit of the hackday is that people are usually fully open about what they’ve done. It’s understandable that if you’re unfamiliar with that way of working that you might be quite reserved about potentially having your idea “stolen”.
I’m from the opposite side of the camp. For instance, don’t make people sign non-disclosure agreements unless there’s a very good reason. The mental overhead on trying to remember who or what you’ve got an NDA about is not fun. Personally I don’t sign NDAs after spending well over a year under one for my main day-to-day activities. It was like being a rubbish spy.
If someone really values a conversation with you, they’ll value your network as well as your intellect. And they’ll also value your integrity.
Plus, nobody looking at your idea is going to think “oh that’s a great idea, I’m going to stop what I’m doing, completely rip this person off and invest my own time, money and energy in it to get it off the ground”. Startups are hard. Ideas are ten-a-penny.
Show people before you think you’re ready
There’s no use doing a hack in two days if you don’t show it to anyone quickly. My usual process is to send a tweet asking for people to try something out. I then send the link to the people who’ve responded and ask for a little feedback. It’s really helpful to get input from people early so you don’t go off down the wrong route.
Attending is a hack that I built and released in a day a couple of weeks ago. Because it got good feedback we added some finesse and design over five further days.
Give away the ideas you’re not going to do.
There’s nothing new under the sun. Yes, I know, you too saw that someone had their startup profiled on TechCrunch and you had that idea ages ago. You weren’t going to do that idea because you were doing something else, so be congratulatory and move on. Idea-having isn’t a limited resource. If you think you’re not going to do an idea, give it away or have a conversation with someone else about it. Sometimes, they surprise you and actually do it, and the fact that an idea you had actually came to something despite you not being involved is a good feeling.
Limit yourself
Some of the best music is made on instruments that limit the musician to just a few sounds. The 808 drum machine is the classic example. I think the same can apply to hacking. Give yourself two days. Keep it minimal. Or make sure you have a deadline where you’re going to talk to some people about your idea. The hackday format is great for this. You have to get something demonstrable by 5pm on Sunday.
Get good at getting fast
Once you’ve made one hack, there are probably elements of the process or the thing that you’ve made that you can use in subsequent hacks. You can copy and paste some of that, but maybe you can go further and make your own boilerplate “starting point”. I’ve got two now that I use as a starting point for things – Bootbuckle and Nub. Do a few hacks, and then make a starting point for other hacks. Optimise for doing the real work on the idea, not building another log-in system. As you use them, pull the code back from each of the new hacks into your “starting point” app so that next time you have an idea it takes you less time to get going.
Go wide
I try out lots of different things, and there are periods in your life where that’s a very good way of deciding what you want to do next. Try a variety of small experiments in your spare time with interesting people. Scratch little itches that you have. Intentionally “go wide” by looking at a variety of opportunities.
Go narrow
But the time comes when having a laser focus is the right way to go. And so it’s time to kill your darlings. Let’s say one of your hacks looks like it has legs, you’ve got some investment and you’re about to start a company around it. It would be foolish to be distracted by lots of tiny hack projects, so kill everything and focus on making that thing a success.
And then go wide again?
And once you’ve got that thing going, open up again and try a few things out. That’s where I am at the moment at Makeshift, and I’m right back in the “wide” stage, investigating several things in parallel.
Strike up a conversation
In the end, the best thing about a hack is that you’re publishing something that is a usable, demonstrable reference point about your idea. You can point to it, people can play with it, you can learn from playing with it too, and you can filter the things that you learn back into the next phase of hacking. It’s not “agile development”, because it’s a hack. It’s the bit before you get into the agile “iterate, iterate, iterate”, so it’s important that you have your ears open and have conversations with the right people around your hack.
Hacks can be tiny, and you don’t necessarily need to know how to code to do one. It’s probably more about an attitude that you can gain through doing this – that things that look difficult can start to look more achievable, that not everything you do has to be perfect, and that sketchiness, impermanence and bugginess are possibly things to embrace rather than shy away from.
The best way to have a good idea
is to have lots of ideas
In the end I am a firm believer that anyone can have a good idea. The trouble is that lots of us get fixated on a bad, or even worse, a mediocre idea and can’t get past that point. Some people feel like there are a fixed number of ideas that they’re going to have in their life, and they don’t want to give them up for anything. But I think that by being free and easy with your ideas you improve your ability to test whether an idea is any good before you commit to it. And hacking is a good way of rapidly filtering the good from the bad, and learning along the way.
I’m @stef on Twitter. Thanks to the #sundaypost people, and those who supported this on HelpMeWrite. If you liked this please hit the “recommend” button.
