Foursquare Hackathon Post Mortem

**Note: I wrote this post just after the hackathon, but then forgot to actually publish it! **

There’s a fair amount I learnt from taking part in and helping to organise the foursquare hackathon here at the university that probably deserves its own post. I’ll split it into two parts, the taking part and the organisation.

Organising a hack event

There were a couple of things I learnt from helping to organise the event that perhaps weren’t clear to begin with:

1. Expect dropouts. A lot of them. We ended up with about 50% of the people that said they would attend actually attending. Which is fine because we hadn’t planned on providing catering etc. anyway, but if we had, we may have overspent massively.

2. Get someone in to run the day that doesn’t actually want to code. All three of us organising the event really wanted to get involved and create stuff, so there was no-one left to organise the other essential things like food. Too often people would talk about ordering food, or going out for dinner and then get sucked back into programming and it would get forgotten about. By the end of the weekend we’d all eaten really badly, often very late at night. Having someone there to do things like order pizza or make coffee runs would probably have helped things go a lot smoother.

3. If you’re going to be communicating with the world at large using twitter or something similar, make sure you communicate with each other within the organising team about posting updates. Often two people would try and reply to a query at the same time, which made us look a bit silly. Not a major issue, but it might help give a more professional feel, event if you’re total amateurs.

Participating in a hack event

We also learnt a lot about participating in a hack event. My top tips for a successful project would be:

1. Do your research. If you can, go into the event with an idea already, just in case no-one else has any. It’ll help you get started quicker.

2. Keep it small. Don’t over reach. 24/48 hours is not a long time to code something, and by making it too complicated you’ll be disappointed with the outcome. Simple is best. Add extra features later if you have time.

3. Small, agile teams. These projects have to be small because of the time constraints, so if teams get too big there won’t be enough for everyone to do. People will end up feeling useless or left out, which is never good. I would say a maximum of 4 people per team.

4. If you want to learn something new, a hack event can be a great place to be forced to up your skills in a particular area very quickly. It can also be a great place to learn new skills and tools from others. However, this may lead to the end result not being ideal. If you can live with that, great, you’ll walk away happy. I personally upped my javascript knowledge over the weekend from approximately 0 to something approaching a passable working knowledge, which was great.

5. Know your tools. This is pretty much common sense, but if you’re not after learning something new and you just want a successful app/outcome, pick and use the tools you know really well. We went with django on the back end because myself and Matt know it pretty well, and we were able to get that part of the site running really really quickly. Had we gone with something else it may not have worked so well.

6. Get coding. Screw the design, you can worry about that later. Start coding early, and code fast.

So thats the things I learnt from the weekend. Hopefully we’ll be able to use this knowledge again in the future, both organising and participating in future events.