Houston Mini Hackathon

First Mini-Hackathon Lessons

Aspen, a Digitalcrafts graduate, organized a mini hackathon. Their slogan is: the hackathon for busy people. Cool idea, right? I’ve only ever been to 24hr hackathons; they’re super fun. Every time I attend one I get so inspired by the energy of the collaboration. The rush of motivation trickles throughout the month depending on if the team wants to continue the project. I’ve learned a few things:

1. Keep the project scope small. 24 hrs is not a lot of time.
2. Smaller teams are best. (I was once in a team of 15.)
3. Prepare for demo-day Armageddon.

So a mini hackathon is the size of a regular work day — what can we do in 8 hours? The night before, I drew up some ideas. I didn’t want to go in without any preparation —been there, done that, that’s for newbs! I decided on one project that I could pump out in 8 hours if I worked in a team of 2.

Potential project: I would build an image recognition alt-tag generator. It’ll be built with Microsoft image recognition API, Amazon S3 storage, and with NodeJS Express framework. In one click, a user can upload multiple images to S3, it generates a URI that gets passed to the API. API returns a string of a sentence that describes the image. The string is passed back to the uri which updates into S3.

It was simple, I already had the component features working separately together. All I had to do was mash it up in 8 hours.

When I went into the mini-hackfest, I felt prepared.

Lo and behold, none of what I planned happened.

1. Beware the scope injection. It’s a nefarious idea injection that always pulls the project out of scope. It’s too easy to get swept up in the energy and the hype.
2. 10% New stuff. 90% Stuff you know. Usually judges will give extra points for teams that challenge themselves with unfamiliar territory — but that does not mean dive into a completely new language or an unfamiliar API with crappy documentation.

The Solution

1. Make an MVP and stick to it. Pick out 3 main components and focus on building that functionality. It could something like ‘user can login’, ‘user can search foo’, ‘results are displayed on a map.’ That’s your MVP. You gotta make it work before you start adding additional features.
2. Have a backup plan. Anyone who codes knows that things break all the time. Especially when the pressure is on at a hackathon. After your MVP is fleshed out and working beautifully, you’re going to want to additional cool things. You need to have a backup functionality for if it fails. For example: If the results won’t display on a map, be ready to list it out. If an API is not returning the data you were expecting, be ready to use filler data.

That’s what I’ve learned and I’m better prepared for the next mini-hackathon!