Ahoy hackers!
Jon and Swift here. From this week on out, we are going to do a post a week about stuff we see at hackathons and in the hackathon community. This weekly column will give us the opportunity to reflect on the experiences we’ve had participating in and organizing hackathons all over the world, and we hope these posts will become a resource to all of you. This week, we’re going to talk about the top 10 ways you can ruin your hack when you’re running deep at a hackathon — hey, it can happen to the best of us.
Let’s jump in:
1. Doing A Startup, Not A Hack
Hacks are hacks, not startups. If you want to go build a business, do it on your own time. The hacks that become startups do so by accident, not by intention. It’s almost always a complete waste to limit yourself to things with a business opportunity that is obvious enough to be discovered in 24-36 hours.
2. Building For Prizes
Hacking is about creativity, not big cash money. Every time you build in functionality just to qualify for a certain sponsor prize, you are doing your hack a disservice. Plus, it looks pretty amateur-ish when you tack on an unnecessary feature just to have the potential to win a prize. We can tell ya – from the perspective of someone who has given out prizes before for APIs, I never give them to people who tacked it on at the end. I give it to people who built something cool and creative.
3. Not Doing A Live Demo
Always, always, always give a live demo if you can. People tune out the second you pull out a powerpoint deck or a video.
The best demos leave a taste of “is this even real?” in the mouth of everyone watching.
Remember: you only have a few seconds to capture the attention of your audience (whether that’s on stage in the final 10 or in the expo). A live demo keeps people interested in what happens next.
4. Not Practicing/Being Unprepared
Even the best hackers practice their demo. After all, presenting in front of a big crowd is really unnerving, especially when you have just one shot to show off your amazing weekend project. So: practice, practice, practice. Run lines with your team. Make sure you can plug your laptop into the projector. Work your demo into your muscle memory. Once you have the basics down, it’s much easier to relax on-stage. And when you’re relaxed, you’re in a better position to concentrate on getting your enthusiasm and your excitement out there. Enthusiasm and excitement is great, because it gets you to convey your hack in a compelling way, and when that happens, other people get excited too.
5. Being A Perfectionist
You’ve heard of the motto “Fuck It, Ship It”, right? Nothing is useful if it never gets done, and worrying about getting the details perfect is a sure-fire way of slowing you down to the point of incompletion. This is especially the case at a hackathon, where there is a hard time limit. At a hackathon, the emphasis is on the awesomeness of your project, not how clean the code is. A great hacker is somehow who knows when to walk away from a feature or a bug to get back at taking on the big picture.
6. Not Being A Team Player
Nobody likes a cowboy coder — remember, hackathons are a team effort. Teach your fellow team members even if they’re less experienced and get outside your own comfort zone with technologies. Don’t argue which framework is best, or which language is better. Ain’t nobody got time for that.
7. Giving Up
No one cares if your hack is half finished. My first hack barely worked, but demoing it got me tons of people who were interested in helping out with it in the future and made me feel like I’d achieved something. Always demo in the expo, no matter what state your hack is in. People love to hear what problems you encountered, what you wanted to accomplish, and how you came to settle on your current project! In many cases, the process is more interesting than the output.
There’s a relevant story in an older blog post: Jon Maltz was going to give up on a hack at PennApps and Swift pushed him to make something and demo it anyway, even if it was silly or trivial. They ended up winning a ton of Mashery prizes and getting a lot out of the event.
8. Tunnel Vision
Everyone hates the feeling of not being able to solve a bug. You can stare at a computer screen for hours trying to figure out where a syntax or logic error is to no avail.
Three quick fixes are to: (1) get a mentor, (2) get a second set of eyes to look, and (3) do a lot of googling.
Sometimes the way you planned on solving something just isn’t going to work out and you have to know when to switch gears and try another approach. If you find yourself patching libraries or spending too much time fixing environment problems, it might be wise to switch gears and try a new angle of attacking the problem.
9. Team Is Too Big
Having a large team might seem like a perk at first. I mean, take the amount of work that one person does and multiply it by the size of your team, right?
The problem with that logic is that as your team gets larger, there’s more coordination that needs to happen. At some point, the managerial overhead becomes so great that you actually need one person to coordinate what other people are working on and piece components together instead of hacking.
Also, depending on the complexity of your hack and your understanding of version control, having a ton of people edit a small number of files will inevitably lead to tons of merge conflicts which will just slow things down.
Here at MLH, we think the optimal team size is 3 people.
10. Siloing
You’ve all seen it. That team where every person is working on a different part, in a different language. It doesn’t work. Teamwork requires you to collaborate from the beginning to make a successful hack, plugging everything together at the end is almost always janky and a time crunch.
11. Off-By-One Error
– – –
Alright, that’s it for us today. Have a great week, and we’ll see you next time.
Happy hacking!
– Jon and Swift