I’ve been going to a lot of hackathons recently and one thing that often jumped out at me is how bad many developers are at demoing their hacks at the end of the events. For those that aren’t hackathon regulars, they are events where developers get together for a day or two to make quick little apps. At the end everyone has a few minutes (normally 2-5 minutes) to demo there hack on a large projector in front of everyone else. Perhaps it’s simply inexperience, perhaps it’s because Europeans are worse public speakers than Americans,1 but whatever the cause, here are some tips:
- Close everything on your computer that will not be used in your talk. Private emails or Skype messages popping up via Growl notifications are probably not something you want and may be embarrassing! That being said, several people have surprisingly good recollections of the specifics of my Quantified Self talk thanks to remembering the Coffeeshoppr-related todo items they saw when I showed my useage of Things. Your mileage may vary but, again, keep the extra programs open to a minimum.
- Assume no or unreliable internet. While this is not always possible, download as much of your whole demo as you can to your laptop ahead of time. Videos should be a particular priority. Also, run your app locally if you can. We don’t care if the URL in your browser while you demo your app is http://localhost:8080 instead of http://yourapp.com.
- Related to the previous items, have everything you do need for your demo open, though perhaps hidden. That is, launch all apps, open all folders, select all videos, whatever, ahead of time. When you plug your laptop into the projector you should be ready to go immediately. Then, as you present you can just jump from app window to window as necessary.
- Bring the proper dongle for your device to connect with the projector. You can assume all projectors take VGA input; some also take DVI. I’m shocked how many people get up to the podium to demo and are then amazed that the organizers don’t have iPad-to-VGA adapter or whatever they need. That’s your responsibility, plan ahead. This is one area that non-Macs are perversely superior, as most still have antiquated VGA ports while Apple laptops have an ever-changing set of DVI derivates.2
- Perhaps contradicting my previous item, use a Mac for your presentation over a PC, particularly one running Linux, if you have a choice. While it’s always a dark art for the laptop and projector to see each other, Macs tend to be much better, both in the ability to detect the projector/get the projector to detect its signal and in the speed at which it does.
- If you have technical problems, apologize and take no more than 30 seconds trying to fix them. If it’s still not fixed, begin your presentation anyway, talking over any additional attempts to fix the problem.
- Last but most important: get to the freakin’ point! We don’t want to see you walk us through the account creation process (which is exactly like every other web service ever), we don’t want to hear about all the annoying technical problems you encountered over the last few days, we just want to see your app. I would say show the core concept of your app within 30 seconds, but I have a friend who trains people on public speaking and he says do it within 7 seconds. Either way, don’t mess around! Show us what your app does, then explain why that’s interesting and/or useful, then if you still have time show additional interesting features around the core feature you showed first. Fin.
As you can see from the tips, your demo should be simple, direct, to the point, and have no distractions. Good advice for any presentation I would say!
Bonus section: How to win a hackathon
Since I’ve told you how to present I might as tell you what to present. Hackathons often have prizes for the best creations that are given away by the sponsors of the events, and who wouldn’t want to win cool stuff for a few days work? These aren’t sure-fire rules but if you follow them more closely than I usually do you’ll probably have a good chance of winning something.
- Have a cool idea. Duh. Easier said than done but naturally no one wants to give a prize to something that’s boring. Ideally it should be fun and playful (you’re spending a day or two during the weekend to work for free, right?), but it needn’t be if it’s a compelling, useful idea.
- Stick to the hackathon theme. If it’s a hackathon about mobile music, make something that is ‘mobile’ and ‘musical’. By all means take the theme and push it to its extremes but remember that sponsors are looking for something that they thinking is cool. What will they think is cool? Something that reflects nicely upon them, either because it uses their service or product and/or it validates their market. Either way, it should be something that they would be happy to mention on their blog, put in a press release, or demo to their customers. I’ve never seen this but of course nothing obscene or violent will fly.
- Use more than one API, particularly sponsors’. If you’re at a hackathon where the sponsors give out their own prizes then you can more safely try to please just one sponsor, but otherwise you’ll be better served by using ones from several sponsors. This both implies that you’ve done something more creative (not that this is true, but I think there is a slight assumption that more APIs used = more creative concept) and pleases more sponsors. Judges pick up on that.
- Know your presentation audience. If only or mainly the developers who participated in the hackathon will be in the audience of the demos, developer tools can get a very nice reception. If the presentations have been opened to the general public, then developer tools, which I often work on, won’t get a good response. Focus instead of something conceptually accessible to laymen. Judges are naturally going to be more likely to recognize hacks popular with the audience. And some hackathons award prizes based upon audience applause.
- Create something. It’s only happened a few times but I have seen people give PowerPoint presentations outlining the awesome ideas they developed over the last few days and showing the cool mockups they made. Who cares! Hackathons are for hacking, for making things. Go to another event if you want to just toss around ideas or business concepts. I hear Startup Weekends are good events in that vein, but even there there are people developing stuff.
- And complete it. While an awesome, ambitious concept only partially implemented can still win, it’s harder than if you have a finished project. And if you fall into that first camp, you run the risk of showing little and spending most of your demo time talking about what you would have done if you had more time (see Tip 5). To win with an incomplete project you must have enough developed that the contours of your final creation are firmly defined and what you’ve developed must be really amazing in its own right.
Given this, you should be realistic about what you decide to work on and know what you can achieve in the time allotted. Working in a team can speed development but only to a point. Large teams will just introduce social friction that you don’t have time for, especially if no one is prepared to be the team dictator. Hackathons are for generalists and aren’t the place for the super polished apps created by lots of narrow specialists that a large team can give you. Any team of more than 3 or 4 people should be split into two teams, whether working on complementary hacks or even on completely different things. Just to give an example, at one hackathon there were 7 of us talking about working together. I forced us to split into two teams and then my group of 4 ended up working on 3 distinct but complementary apps.
Another important thing to ensure you complete your hack is to use tools you already know. Of course hackathons can and should be a great opportunity to play around with new tools and techniques, but if you’re looking to have a complete hack to demo at the end only choose one new thing to learn. And ideally that new thing is something for which are people at the hackathon who can answer any questions you have when you get stuck. Beyond that, stick to languages and libraries that you know you can be productive in and keep dependencies at a minimum. Need to save some data? Trying using a flat file or Sqlite instead of trying to setup a complicated cluster of databases. Any time spent on system configuration and installation is time not spent developing.
And prepare your tools. If you’re an iOS developer, that means downloading the latest version of the stupidly large iOS SDK at home beforehand. I’ve recently created a little tool for myself to make sketching in Scala easier. Basically install ahead of time whatever big software packages you think you might need, as the internet connection will probably be flakey.
As for code style and things like that, it doesn’t matter. Of course you shouldn’t be excessively sloppy because you think it’ll save you a few minutes of development time (you don’t want to be introducing bugs which will pop up during your demo!), but don’t sweat the small stuff. For instance, if you’re fast at writing unit tests, great, but otherwise don’t worry about it.
- Bonus tip: everyone likes pretty things. If you’re a programmer and can’t throw together graphics quickly, try to recruit a designer to help you. A nice logo and page layout go a long way!