kinlane-productions2.s3.amazonaws.com
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.
#9: Let the developers present to you and give them feedback if they request it. I have seen a few times where hackathon's ask for Video's or PowerPoint slides and don't let the developer present their idea in person. A developer that can not give a good presentation is still a million times better than the best powerpoint. Hacakthon's are usually compressed time events let the developers focus on making a great app and not waste time on presentation materials. Simple is always best. Ask the judges to keep notes and if they feel comfortable share with teams how they did. Give the developers a chance to get better.
#10: Think about app display BEFORE the presentations. I have seen elmo's used, or projectors with VGA cables but the best setup is a an elmo or projector attached to video camera because it allows people to show their app on their computer or mobile device without a lot of fuss. You will need ideally 3 people in dedicated positions, A: Someone to host and take care of announcements and queueing up teams B: Someone near the display device adjusting and helping the nervous hackathoner's setup C: Someone to advise and keep the queued up teams in order. The video setup has maximum adaptability and the least amount of change over time between devices.
#11: Give them time. I always find it weird that the developers spend 500 to 700 minutes creating something great and the presentations get limited to a 2 or 3 mins. Average hackathons have 30 teams , if each team was given an extra minute that is only about half an hour of extra judging time. If the developers have spent the time to make something they believe is great let them share it with you and the group and give them that extra minute.
#12: Along the lines of being upfront there has been a new trend I have been seeing at hackathons that has me bewildered. One of the great things about this profession is that we are color and age blind. All we care about is if someone can make something great and not what they choose to do in their personal life or look like. The troubling trend that I have seen is discriminating against developers because of age. I have heard this a few times now where a judge has said outside the chambers that a particular developer was "too old" or they were looking for someone really young. This is insane. This should only be based on merit , who made the best app, nothing else.
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.
