Kin Lane

Rules for Hackathon Organizers, by Ravi Singh

I just wrapped up the AT&T Mobile App Hackathon in Las Vegas. I had a great time hanging out with developers at the Palms Hotel, and watching everyone compete for the 30K in prizes.

My primary goal at these events is to get to know developers and hear what they have to say. I was fortunate to connect with one such developer, Ravi Singh (@Code4Ever), and he was so kind to share Ravi’s Rules for Hackathon’s:

#1: Use Eventbrite or Meetup to organize the event. Don’t spin your own system because it is a waste of time. Eventbrite has it’s own systems to market and get info about your event out.

#2: Build a messaging network BEFORE the hackathon and register a hash for it. So many times developers leave the main area to work out their idea and miss critical information. Establish a simple back-end for all messages and let the attendees now and blast all important information about the even through it.

#3: BEFORE the event setup a Google Spreadsheet so teams can register for the final presentations and send that out in the first mails. Do not wait to do or announce it late or in slides.

#4: FOOD: Do not waste your money in lots of cheap items that are bad for the developer. Pounds of candy and jerky don’t help your developers become more productive. There is a reason Google has 640 chef’s cooking with organic and healthy foods. Instead of wasting your money on that stuff, find a good local cook or chef to make a hot lunch for the developers. Do not invest in Red Bull or 5hr energy or other food items that are actually bad and questionable for the health of the developers. This doesn’t mean you serve tofu and fruit , but that you actively consider making food and providing drinks that are in the benefit of making the best apps.

#5: Networking, test the network before and get a clause from the facility that states what the maximum they can support is and hold them to it. So many times the wifi connection is the blocking point for developers to make something great.

#6: Judging and Rules. Make sure you post information about all of this upfront and be consistent and transparent. Do NOT have hidden or “soften” requirements when they are declared as hard ones. There is nothing more frustrating then when a team plays by the rules and gets beat by another team that hasn’t. Create simple, clear and clean rules and enforce them. The more complicated the rules it is inversely proportional to the quality of the applications produced. Instead of making something great people make something to appease a set or rules. Always , Always , Always focus on making great software.

#7: Vet all API’s. If a particular requirement is to use an API , you must thoroughly examine the API ahead of time and if you have to hire someone to write a sample app for the intended app that you can distribute. There is nothing more negative then presenting a badly written or untested API to a potential group of developers , it actually creates negative market impressions.

#8: Choose to make several smaller prizes instead of just 1 super prize. A lot of times the difference between #1 and #2 is negligible, reward the effort.

Ravi is what I’d label as a hackathon veteran with over 30 hackathons under his belt, he has a good idea of what developers are looking for when attending hackathons.

Thanks again Ravi(@Code4Ever) for sharing your thoughts, and I’d love to hear what other developers have to say about the event, now that we have all gotten some rest, and had time to reflect.