My Ideal Hackathon
This post is mainly a response and expansion to this post. Go read it now, it's a great read.
(Disclaimer: I have never organized or run a hackathon so I have no idea how much work or time goes into getting one off the ground. Some of my ideas may be too hard to feasibly do in real life.)
The first hackathon I went to wasn't even a hackathon. It was a game jam on campus that took place over a weekend in Snell Library. I went because I thought it was a good chance to make something and meet people in my major (Game Design) since it was fall of my freshman year at Northeastern. I ended up working on my own game that didn't really come to fruition so with like 5 hours left in the game jam I make a game called Flixel Push. All you do is hit the spacebar as fast as you can to try to move a pixel towards the top of the screen and there are particles and colors and explosions and it's one of my favorite games that I've made.
These are the three most important things that I think should go into hackathoning.
- Meeting cool people.
- Learning cool things.
- Making cool shit.
Hackathons should be about going somewhere to meet new people who love coding or designing or building things, learning new things about languages or frameworks or hardware, and then making cool shit with these new people and the new things you learned. My ideal hackathon would incorporate these three items.
The hackathons I've enjoyed the most have been smaller (around 100 people or less) and have allocated longer than 24 hours for coding. HackBeanpot and the game jams I've gone to get it right pretty much every time. With only 24 hours to work on something I feel pressured to stay up the entire time. You really shouldn't force yourself to stay up for 24 hours (on top of the other hours you will be awake getting to the hackathon and leaving the hackathon). My ideal hackathon would allocate around 36 hours for coding. You have time to plan, you have to code, and you have time to sleep and take care of yourself (eat, shower, etc.). This means that the hackathon would start Friday afternoon and ideally end Sunday afternoon.
The hacking space is also important. HackBeanpot and YHack both provided a great space to hack. HackBeanpot the last two years took place at the at the CIC building in the C3 space. I'm not too sure what the name of the hackspace YHack had their hackathon in but the most important thing is that both had varied spaces for people to hack in. There were rooms and smaller open spaces, hallways and corners. Basically it wasn't a large open gym filled with tables (sorry HackMIT). This goes back to the size of the hackathon. It's hard to fit 1000 people into one place. It's much easier to fit 100 people into one place. During hackathons it's fun to just go around and see what the team did to the space they are occupying. It almost becomes a secondary temporary home. If all hackathons could happen in the C3 space that would be awesome.
A weird thing about hackathon signups is that they usually ask what you've worked on or what you're interested in doing at a hackathon and then seem to do nothing with that information (or maybe it's used for mentors?). For my hackathon I would ask if you want to work alone or in a group. If you want to work in a group then I would ask if you know the names of the people you want to work with. If not then you enter what you are interested in working with (a language or a framework or some hardware or something like that). Then I would match people together with similar interests into groups of 3 or 4. This helps people meet new people pretty much instantly and helps with team formation. Really proficient in Python? Cool, here's someone who is interested in snake programming and another person who is a designer. Go introduce yourselves and make something cool.
Sponsors are great because they give money and hardware to broke ass students who want to run hackathons. They usually also have APIs that you can do cool things with and have people who can help mentor people in the ways of building cool shit. They also give out prizes. Prizes are great because who doesn't want a new MacBook or $4000. But hackathons shouldn't be about expensive prizes. They should be about feeling great because you spent a weekend building something new with people you only met 48 hours before. I really would want some way of allowing everyone to show what they did that weekend at the end of the hackathon and then have everyone vote on what they liked the most or thought was the coolest or the silliest or whatever and then award prizes that way.
Something that I think gets in the way of me having fun at hackathons is the pressure to succeed. The pressure to make something good and impress (insert person/sponsor/company here). If you do impress them maybe you'll get to work at (insert company here) because who wouldn't want to work for (insert company here). And that's great but I feel like that clashes with what I think hackathoning is all about. Everybody wants to work at their dream job and companies want to find the best talent. If I want to impress (insert company here) I might make something that they would be interested in with a language and framework I'm really good at instead of trying a new language that sounds cool but I have no experience with. The incentive in doing something new is that you learned something new but is that better than possibly winning a new MacBook or flying out to (insert company here)'s campus. I'm not saying that you can't win when trying something new, I just think the chances are lower.
I'm going to keep attending hackathons because I think they are a great excuse to spend a weekend coding new shit instead of doing homework. I'm going to keep attending hackathons that line up with what I think a hackathon should be. Smaller, provide ample time for coding, and encourage building cool shit with cool people. Hackathons should be about the experience even if you didn't get to build in all the things you wanted your project to have, that is ok. You still made something and we should all celebrate that.