One of the tasks as organiser of Titanium App Camp is to write a collaborative Hackathon survivor’s guide, so here are my tips, according to my possibly limited experience. I have attended 5 hackathons in the past 3 years and all of them have been quite challenging. I’ve won none and I hated not winning so next time I think I will follow my checklist more than my heart 🙂
0. Don’t be scared/shy
I don’t want to hear any excuses “but I’m only a designer, I can’t code”. Nobody will witch hunt you for that. There are coders like me who are a rubbish architect, or/and a useless project ĂĄmanager or/and a hopeless designer. I need all those skills in order to produce something solid and pretty so please come to hack days and form a team where your skills will be definitely in need. I know there will be downtime, but it’s part of the challenge. “I don’t know anyone” – I’ve gone to hackdays literally on my own. No team, no friends and yet I’ve met the most interesting and kind people. It’s a social event (even if at the eyes of most non tech people it’s not social at all) so people tend to speak to you a lot easier than possibly in a bar or cafe (ok, I might have exaggerated a bit on the bar comparison). Plus you’re bound to bump into a Twitter acquaintance to which you will be able to finally put a face against 🙂 “I only code when I get paid”. Although this one could be a respectable reason, I truly believe that there is so much value you can take from a hackathon. If you want to learn something new it’s a unique opportunity to do so. I remember the lovely and most patient Daniel Knell and Chris Lockteaching me how to use Zend; the Facebook engineers being on site (lots of them) to explain in details how to use the Graph API. the ever so patient Twilio devs helping me setting up a call and text messaging through their API. I learned skills I can now use in my day job and get paid more because I know this new stuff! And if your idea is really good you might land some funding! VCs and press often attend hackathons!
1. Pitch your idea
Do you have an idea already? pitch it to a few friends, techy and non. Do they honestly think it’s a good idea, or just useless? At hackathons I’ve seen spectacular ideas win, as well as quirkiest ones, so it’s not as if only the most useful ideas win…
2. Don’t start before the hacking time begins.
It’s rude and unfair. Although I think some people must come in with some sort of “basic codebase” they can then adapt. In a way, I recommend this and I will definitely try to do this next time. Not to bring something specific to the hack, but a working base. For example this could be the previous hack you have built, maybe stripped out of specific modules, but you know you will need (I’m making an example using Zend Framework) a user model and a database model, so you might as well keep those. Whatever you do think very carefully, I’ve spent hack days where I got nowhere because I wanted to build my hack in Zend (just to learn more about it) and got really anal about setting up models and controllers the right (hopefully, all part of the learning curve) way. Whatever you bring don’t cheat, start when you officially can start, it’s more fun and deep down you know you will have won (hopefully) in good faith.
3. Form a team
Idea or no idea, try and find some friends/colleague to team up with. I usually go to hackathons on my own because at times I just go to play around with a new technology and learn something new and therefore get lost in the learning process and don’t really finish what I build. But to make the most of it, form a team with skills that complement each other. If you can’t find any friends of colleagues then post a message on Twitter with the event’s hashtag and ask to be retweeted, or post a message on the event’s meetup page/facebook page/comment area, etc. You can also form a team on the day. There is usually a shout-out for “people with skills but no ideas”, or “people with ideas but missing skills”.
4. Don’t choose your hack just yet
I might be explaining something you already know, but at hackdays there might be rules on what to build (or not). There mostly will be categories i.e. “the mobile app that uses both Spotify and Last.fm’s APIs” or “best for children” etc. Each category winner will get a prize (could even be a tablet or a phone!), so there is not only an ultimate winner, but you could aim to win one of the categories. So before you set on an idea, wait until all the sponsors/categories owners have pitched their request. Some of them will want a problem solved i.e. “build a Spotify app that works with food” or “build an archive of music videos pre 1990s”. Then make your decision.
5. Look at the available APIs and datasets
This should give you an idea of what you can actually build. On the day be really careful about the dataset you choose. When deciding which of your ideas to build, the API/dataset you chose could have a big impact on your work. APIs are usually safer, but still check that the API has an endpoint for what you are looking for. I once decided on a hack to then discover the API was not actually exposing the info I needed. APIs usually come from the sponsors, so there should be a list on the event’s site. Datasets are less safer. I’ve been at hackdays where the data was in a very messy Excel file and was only available for a small part of London. Not only I had to clean the data, but to then discover that to obtain the rest of the data I had to go to the Fire Brigade’s Archive and manually consult some record books. Only having part of the data made my hack kind of useless. Some companies/organisations have provided datasets in PDFs (!!!) or messy Excel file, so if you decide to use this data you will have to import it in a database and I’ve seen hackers spending HOURS doing that blocking the progress on the hack. So at least bring an CSV reader script as a base.
6. Think about where and if to store the data.
What data do you actually need from the API? If the hack is just a quick one then querying the API on every page load won’t hurt. But think about  daily/hourly query limits, the last thing you want while building and testing (yep, happened to us) is to be blacklisted from an API provider who will not be on hand to give you unlimited access for the day/weekend (the sponsors who provide APIS will instead be on site and able to whitelist you, just ask them). So think of all the data you need and only put through a request when you have a spot on query – I know this is hard, but ask some help and work on the perfect query on paper. Then cache your request or save it against the current user in the database. Or if you need for example, a list of venues, make a search query once, then write a script to save it into your DB. That way you don’t have to make a query to API any longer.
7. Plan
I don’t know quite how much to stress this, but I’m a rubbish planner, I’m an impulsive coder, so I will just follow the flow rather then architect my hack. So don’t waste your time like me, plan everything, write wireframes, think of all the options.
8. Eat healthy
I know it’s easy to be glued to the chair/bean bag/bench/floor when you are deep in code, but if you want to be productive you have to eat. So when dinner/lunch are served take a deep breath and go get some. It’s also a great time to socialise, find some help for something you are stuck on and your break will really help you going back refreshed. There will be TONS of sugar snacks and drinks. Watch it. I’ve spent hack days surviving on sugar and felt so ill on the Monday. Eat fruit and drink plenty of water.
9. Prepare an awesome presentaion
It’s essential that you take at least an hour to prepare for your presentation. Appoint the best person for the job. Ideally you want somebody with a sense of humour, with a clear and loud voice. You only have about a minute and you have to use it wisely. I am no expert (I have indeed pitched and forgot a big bunch of features I was meant to mention and made jokes nobody laughed at – that was really hard to accept) but the trick is just to plan it properly and write a simple speech. Imagine you have to explain how your hack works to a very non techy person. You must have spent the last day building this so you might be very comfortable and knowledgeable on how to use it, but remember you are presenting it to complete strangers who will have to judge your work.
10. Test, test, test
Most importantly test your demo. Demos is where it can all go wrong. Try it many times before you go on stage, you won’t have time to wait for it to load… Â Excited? Then come to Titanium App Camp, an uncoference and a hackathon on the 2nd and 3rd February!
Recent Comments