The do’s and don’ts of hackathons

This past weekend I attended a hackathon in New Haven. Over the 1.5 days that we were given time to work, the organizers held various workshops and training sessions where sponsors would teach how to use their software in our projects, or a group of competitors would meet to talk about some specific subject related to hackathons. Th e first thing I was told when I attended a meeting about organizing hackathons was to define what it actually was before I said anything more about it. I can imagine how, if I didn’t do this, I could be misinterpreted as attempting to train Mines students to hack into a secret government database.

I am here to tell you that no, despite the name that suggests it, hackathons are not about hacking. Rather, they serve as environments for students to meet and work with other students on a project focused on any technology-related subject (I will note that sponsors usually give out challenges that aim to focus your project on their software or technological interest). Th ey tend to operate in a very short time frame– typically around 48 hours– and chances are that you’ll be ripping your hair out in a dark room at 4:00 am the morning before your project is due to be submitted. Th at is what I did, and here are some tips so that you don’t.

1.) DO pair up with people you haven’t met before:

I went with a group of Mines students, but we ended up pairing with another student from Yale, and they had a lot of insight to offer as a front-end visual designer. Plus, you make new friends that can tell you about life at their colleges!

2.)DON’T spend the entire time in the hacking space:

You’re in a new place (most likely)! Feel free to explore campus when you get the chance and snap some pictures of the misty graveyard or gothic buildings. Many of the small meetings offered by organizers will also likely relocate somewhere outside of the hacking space– one of mine went to get ice cream from a historic downtown district!

3.) DO accept that your stress personality will come out:

If you’re doing everything right, then you’re likely nowhere near being finished with your project by the last evening of the hackathon. This is when you pull an all-nighter to get a minimum viable product out, cutting corners (or probably more than just corners) to have something to present the next morning. This puts a lot of stress on you; you can expect your stress personality to rear its ugly head, and you may scare your teammates. At least I did.

4.) DON’T be a perfectionist:

This was my biggest mistake. The products coming out of hackathons are not by any means expected to be usable; essentially, you are rapid-prototyping a way to communicate your vision to the judges. Just that can get you a long way– take my team’s product, for example: as I was attempting to demo our virtual reality art therapy software to Facebook’s judges, my character was teleporting onto roofs of houses, falling into voids, and launching around the terrain at speeds that were not at all “therapeutic,” all while I desperately tried to paint something in 3D space for the judges to see. We didn’t even have other player’s viewable in the game– we just said that there was multiplayer functionality and showed on another computer that two people were connected to the room. Despite all this, my teammates were able to explain the premise of the simulation, as well as how it addressed Facebook’s challenge to develop a virtual reality game that brought people together, and the judges liked it! To sum it up: make something generally functional, rather than perfect in some aspects and completely broken in others.

5.) Most importantly, DO enjoy your time!

Hackathons are meant to be a learning experience! If you didn’t have fun by the end of it, then you did it wrong. And that’s the only way to do it wrong. Now that I’ve bestowed upon you my infinite wisdom (coming from my experience at one entire hackathon, mind you), go sign up for a hackathon! I promise you that it’ll be worth your weekend.