Hackathon: What Not to Do
So over this past weekend I participated in my first and I believe Tucson’s first hackathon. Overall, it was an awesome experience and I met some really cool and interesting people. I saw some cool hacks/apps created in a short amount of time. Tucson desperately needs this kind of curation of tech and tech culture. To be honest, I had no idea that so many like-minded people called Tucson home.
However, in contrast to the awesomeness of the event, I can say with complete honesty, I failed at the hackathon. I failed hard. This is partly the reason I am writing this, so I can look back and remind myself what not to do in the future.
I went into the hackathon with a few ideas that played to my strengths as a developer. However, when I quickly could not get anyone excited about my ideas, abandoned them and joined with another team to work on something different. Not that this is inherently bad, but I needed to take a step back and ask myself first if I thought I could execute anything with this idea in a 24 hour time-span. So this is lesson one for future me-
Be completely honest with yourself about your ability to deliver something in 24 hours
Learning new things is great. Learning new things while trying to compete in a time-based competition? Not so great. I tried to tackle a new physics engine in which I had no prior experience. I told myself I could do it, however I don’t think I was being very realistic with myself about my abilities.
So what happens if you cannot partner with a team or idea that plays to your strengths? In retrospect the only thing to do in that situation is to pivot. Brainstorm about your MVP (Minimum Viable Product) for the competition and set some hourly goals.
If you or your team members cannot meet these hourly goals, then pivot the goal, or the whole idea until you can
I got stuck up on one problem, and spent most of the 24 hours trying to solve it. In that time I could have made numerous additions to other portions of the idea, or pivoted the idea completely, and made more progress. 24 hours goes faster than you think, too many hold ups and you’re done. From another perspective, 24 hours can be a lot of time with enough people on the team.
Ensure everyone on the team has something to do that contributes to the final product. Play to their individual strengths if you can
This feeds back into checkpoints into the goals you set before you started coding. If you have team members sitting idle, then get them working on some other aspects of the idea. Every product or idea can have multiple platforms targeted or other resources created. Have them make a website, a storyboard or a slide deck. Anything will help the polish and “execution” of the final product.
The last of my numerous failures was I forgot to enjoy myself. Don’t get me wrong I love coding, but I treated it like I treat a day at work, head in the computer working away. I feel regretful about this, as this was a gathering of great people that I should have spent more time getting to know. So had I managed my team and time better, I could have enjoyed the atmosphere a little more. So -
Have fun! Use this advice to manage your team and time. Get up take a break and chat with some of the most interesting people in town
The one thing that I think we did right for hackathon 2012 was partner with a designer. The Tucson hackathon was not about creating a certain kind of hack or project but more a loosely themed free-for-all. With this kind of environment a designer can really help a fledging idea stand out in the final presentation. So here is a shoutout to Theo Klipnis for helping bring some credibility to a poorly executed project.
So if you’re interested here is a video to what we were able to accomplish in 24 hours. The game and character are named Spleegle. The idea was a grappling based vertical platformer with a chameleon that can only use his tongue to get away from some rising threat. I think the game is an interesting idea and I will continue to work on it to see if it can turn into something good. What this video does not show is all of Theo’s awesome drawings he did of Spleegle in different positions.
Your mileage may vary
I think a key point I should make is that I think these points are things that will work for me in future events. Your mileage may vary, and you or your team might work very differently than this and still accomplish your goals. But if you’re not having fun while doing it, you’re doing it wrong. Can’t wait for the next hackathon!