How to Succeed and Thrive...

One of my first times coding outside of class was at a hackathon during my first year of college. It was late February, and we drove through a snowstorm to an industrial building near the Iowa State University campus. Inside, we checked in at a folding table, and fortunately the person handling registration didn't examine my ID carefully, as I was 17 at the time. For the next 36 hours, two friends and I developed a client-side JavaScript isometric map maker, trimap. As I started from essentially zero knowledge, I had no choice but to learn more in that weekend than I had in the preceding weeks of Introduction to Computer Science combined. What we made is, without a doubt, a terrible piece of software, and to this day I am inordinately proud of it.

Since then, I've been to a few more hackathons around and beyond Iowa. I got my first programming job from a hackathon and have won several prizes. Most importantly, I've now had several of these weekends to accelerate my learning on specifics topic. I think that every student studying programming should try a hackathon, and if you're a college student in the United States, try a MLH (Major League Hacking) hackathon. They are an organization that provides structure and support for hackathon organizers nationwide. Here are my tips for crushing it at a hackathon.

Before

Some hackathons you have to register for, others you have to apply to. For your first hackathon, find a smaller, no-application hackathon if possible, as the big names can be fairly selective. Figure out your travel at the same time as registration, hopefully the hackathon is within driving distance and you have access to a car or bus. If you go to a larger university, there may be a hackathon at your school! If it is a well-known hackathon or organized through MLH, you should see plenty of new faces at the event from other schools.

In my experience, while larger hackathons offer more prestigious sponsors and produce impressive projects, the experience is fairly standard from hackathon to hackathon. By all means, seek out hackathons at universities that you are interested in visiting, but don't feel like you're missing out if you stick to events within your state or region.

Get ahead on your homework before the event. Ideally, you want to be able to focus on making the best project possible for the duration of the competition. Afterwards, the last thing you'll want to do is a reading or problem set. Walking into the weekend event with your homework in the bank through the next Monday or Tuesday sets you up for success.

I love working on projects with my friends. While most hackathons will let you work alone, and they all say that you can find a team there, most of the enjoyment is doing this crazy thing with people who you care about, or at least like. Hackathons test a friendship, good bonds will come out stronger, and it's a great mutual interview for working on larger projects together. Plan and register for the hackathon with your team.

In my opinion, three people is the perfect team size, and two also works. Working alone, it's easy to run out of steam and hit a road block. Most hackathon projects aren't of a large enough scope for four or more people to effectively contribute, and even if yours is, your devops setup probably isn't good enough to handle changes from that many developers, but if you can, more power to you and you'll probably make something great. If you're going with four or more people, I'd recommend splitting into multiple teams and supporting each other, though be aware of event rules about inter-team collaboration.

While you shouldn't start your project before the event, it's a good idea to establish what problems people are interested in working on and which technologies the group already knows. Hackathons are a great environment for learning a new technology, but if you plan to do so make sure you have a development environment set up and write a "hello world" before the event

Don't pack light for the event if possible. Bring a couple changes of comfortable clothing and toiletries. Expect that an offsite hackathon will not have showers, but bring a towel anyway. Bring as much bedding as you can, especially if you're driving. A camping pad can make a concrete floor possible to sleep on. Bring your computer and any peripherals, and make sure your development environment and software are stable and up-to-date. I have a beat-up external monitor that I bring to events in driving distance, it helps for development, presenting, and intimidating the competition!

During

When you get to the venue, find a table with outlets, good chairs, and everything else you need and set up camp. Locations tend to go on a first-come, first-served basis, and competition is fierce even if you get there early. Factors of a good spot are proximity to amenities like the food table and bathrooms, noise level, comfort (availability of tables, chairs, cushions, walls, etc), and cleanliness. Some hackathons are a single room with mostly homogenous campsites, others let you spread throughout a building, with those who arrive first claiming private offices and stragglers programming on folding chairs in the lobby.

Build

Generally, hackathons start with a kick-off meeting, where the judges go over the rules, categories, and prizes. In my experience, it is a good idea to orient your project around one or more categories. Some are use-based, like best financial product, while others are tech-based, like best use of a given API. Working on projects that fit a few categories is great because the organizers and sponsors are more likely to know about the technologies involved, plus your project enters for more prizes.

That said, don't focus everything on winning. When the judging happens, it is fast; judges can often only spend a couple of minutes per team. A judge usually spends the whole time looking at some aspect of the project that took you five minutes and completely ignores the stuff that you spent hours debugging. A good judge will value execution and project completeness, but some are unfortunately fooled by a convincing visual with not much implementation behind it. While it is a good idea to pick a project that qualifies for multiple categories, the most important thing is to build something interesting that you learn from and can use or reference later.

With this in mind, start brainstorming after the intro meeting. As my professors love saying, hours of coding can save minutes of planning. A hackathon is so short that you feel the pressure to start coding right away, but it is better to spend an hour or so planning. Once you have agreed on a project, try to map out the work that needs to be done and figure out what you can do individually and when you will need to integrate as a team. Also, set up your source control and double-check your development environment.

From there, it is a crazy sprint to implement your grand vision. Don't worry if the feature set of your project changes drastically from what you planned, just take note of it to improve your future estimations. Make sure that every working version is tagged in your version control system, come together every few hours to make every piece work together.

A couple hours before the project is due, stop making new features (unless you have something you desperately need to make the project work, in which case by all means work up to the last second). Spend some time polishing your user interface and figure out how to demonstrate all of your work in a 3 minute presentation. Make sure your submission to the event's project repository is complete, then practice your demonstration until it is smooth.

During the judging period, you will likely have a judge from each relevant category view your project, as well as a few judges from the event. They may travel in packs or alone, in a fixed pattern or randomly. After you're pretty sure you've seen all of the judges, take turns looking at the other projects. You'll definitely learn something from seeing everyone else's creations.

Network

Hackathons put hundreds of interesting people together in an intense environment, so they are a great way to make connections. Talk to the sponsors early, before the kickoff meeting if possible, as they're still fresh. Keep your hard pitch in reserve for the judging, just make sure they'll recognize your face. Also, try to meet the other attendees, just make sure not to interrupt people while they're working on their projects. Meal lines, side events, and presentations are good times to meet the other competitors.

Survive

Keep reasonably sane personal care habits during the event. Change clothes as often as you would normally, and bring an effective deodorant. Drink plenty of water and move around every so often. I try to walk around outside every few hours during the event. The hackathon should provide food, and I always am surprised by how much I eat during the competitions, I imagine it is a combination of intense, focused work and lack of sleep.

That said, the more I sleep, the better I do at a hackathon. Some hackathons are one night, these often run Saturday morning into Sunday afternoon, while others are more dangerous: Friday evening to Sunday morning. No matter how you feel, you are not working effectively on little sleep. Despite how much needs to happen for your project to succeed, in my experience the best way to operate is by sleeping as much as possible during the event, though uncomfortable sleeping arrangements often make that difficult.

After

After a successful hackathon, I'm mentally exhausted. It is difficult to stop thinking about the problem I've been obsessing over for the past days and to reengage with the real world. Despite my best efforts, I am probably dehydrated, sleep-deprived, and have forgotten what vegetables taste like. After staggering back to campus, there are a few things I do to recover.

First, I go to the gym and do a long workout. I don't push too hard: I don't try for max lifts or record times. Instead, I focus on having an extended, moderately vigorous workout that will leave my body as tired as my mind. Then, I take a shower to wash off two or three days of accumulated living and, if I can, take a nap. I wake up in an hour and a half (I don't want to ruin the coming night's sleep) to eat something nutritious for dinner (get those vegetables). Ideally, I wouldn't have any homework left, but I usually do, so I try to do a decent job on that. I go to bed early and expect to be more tired and need more sleep than usual in the coming days.

Once you have recovered from the hackathon, make sure to add your project to your resume, personal website, or LinkedIn profile. If you're interested in continuing to work on what you made, talk with your team about what work needs to be done and who wants to do it. Realistically, the first step would be shoveling hundreds of lines of spaghetti code out of the code base and writing a unit test or two.

How to Succeed and Thrive at a Hackathon