An awesome and inspiring weekend at East Sweden Hack 2013

By Kristofer Palmvik ·

I have just spent an awesome and inspiring weekend at East Sweden Hack 2013, hacking at our project Inspirr.

After my first ever hackathon I just want to summarize some of my thoughts in a short blog post.

These are my own thoughts and do not necessarily reflect the opinions of anyone else.

Iterate quickly

Move fast and break stuff. Work in short iterations and only do one big thing a time. When it breaks you fix it and make it work. A good versioning system (we used git backed by github) is worth a lot here as you can easily revert to a known stable version.

Fear of breaking stuff without unit tests

When our internal API started to return intermittent errors about two hours before deadline, I felt a strong fear that we might not even have a working prototype to show at the end of the hack. Then you realize the value of having unit tests so that you know what is working and not. At one point we ignored that practice because "it takes too much time". Bad decision, I think.

Automation is awesome

Being able to type git push heroku master (that’s it!) to deploy the most recent code version to the live production site is just fantastic.

Setting up the build system might take some time, but automating as much as possible of the common time consuming tasks is well worth it.

The right amount of pressure is good

I really thrive when there is a healthy amount of pressure.

The last hours before deadline are always the most fun, especially if you know you need to fix something or write some complicated code. No idling, just make it work. And the seconds before you take the stage, feeling your sweaty palms, hearing your own heart beating...magic!

Competition and cooperation at the same time

The ten different teams in the hackathon were competitors, but we also manage to have a good time together, only being limited by the natural time constraints.

I heard some competitors discussing different approaches on how to solve the problem of fetching data from the same crappy API. Discussions about the different tech stacks popped up every now and then. So even when each team is trying to win, helping and learning from each other is still valued.

Don’t overdo it

Before the weekend we had a looong list of features and good ideas that we wanted to implement. But 24 hours is only 24 hours (or actually slightly less), so you have to make sure you only spend time on the most necessary stuff.

And when you have a product that is good enough to show, don’t add more bells and whistles just because you have the time. Instead make sure what you have works really well.

Now I just want to do it again! Soon!