10 things I learned from my first hackathon

May 24, 2016 · 5 minute read · Comments

Or rather: 10 excuses why I failed.

So today I took part in (and I guess, ran) my first full hackathon - IWDev Crimbo Coffeehack. We kicked off at 9am today, and finished at 4pm and apparently threw some code together in the middle of it. We had a random theme which we announced shortly after getting together and then flew at it. Since it was our first hack day at a coffee shop - we rolled with coffee as the theme.

So I learned a few things, and thought that I’d dump them down here:

(for future reference - duh!)

1) Have a good internet conneciton

By good I mean both reliable and fast, but most importantly reliable.

We were not really blessed on this - but it would seem that whatever tech was being used as the router wasn’t playing well with the Apple tech (both one other guy and I were using a MacBook, and we had a really bad connection).

This caused me a lot of pain struggling to pull/push commits to Github etc. - but also made looking up API documentation pretty hard, especially when using/learning completely new stuff (see also point 2).

This wasn’t really the fault of the venue - they had the kit but never had to cater for a group like ours.

2) Don’t try and learn a new X, Y or Z

Our team (4 guys) had 3 devs and 1 graphics guy. We decided to build a HTML/JavaScript/node/websockets multiplayer game.

One of the devs (GarethIW) had done a couple of games using a JavaScript stack this year, so the the client part of the game was sort of “in the bag”. But I’ve not touched JavaScript properly for quite a few years now, neither had the other dev.

But also - node, websockets and JavaScript games dev; were all new ground to a couple of us. So yeah - learning during a hackathon is a little too hard. In a 7 hour hackathon? It was near impossible, particularly when trying to find API docs was so hard (see point 1).

It was a great excuse to get some exposure to something new, and to spike my knowledge on a few new topics… but if I cared about the competition I would choose something I know in future.

3) Don’t ignore ‘best practise’

I don’t think I was alone in the team to fall into the Panic Driven Development mode:

• Bad code (hard to reason about)
• Zero testing (hard to refactor into code you can reason about)
• Monolithic files (harder to work on as a team)
• Working harder (not smarter)
• Didn’t spend enough time setting up a nice dev/test environment (for fast feedback)

We spend a lot of our careers as developers learning that all of this is actually quite important, particularly when working in teams trying to meet deadlines. They all take some time to do properly… but ignoring them seems to be a false economy.

4) Talk to your team-mates

No brainer huh!?

We spent at least 50% of the time working in silence almost, completely siloed.

Bad.

5) Taking part is INSANELY fun

Regardless of what you manage to aceive.

I would totally recommend hackathons - and although hard to say since I’ve only done one of them; doing so as a team is all the better:

• Hone your focus (on a single task, to meet a short deadline)
• Hone your team-play skills (working with a new team is fun)
• Nice to see things shape up fast
• Fun to be part of a dev event
• Awesome to see how many great little projects people come up with (loads of ideas)

6) Games-dev is best-dev

I’ve done a little games development now - and every time I enjoy it more than the last time. It’s such a refreshing break from the normal line-of-business development.

7) Don’t overload the caffeine intake…

It seems like a good idea - you need to think fast, act fast and keep alert and awake; but too much will break your concentration and you’ll be all over the place until you can come down.

8) Figure out your workflow

Really important if you’re working in a team.

Obviously you’ll be trying to avoid lengthy commit conflicts in your code, so in a fit of paranoia you spend time trying to avoid working in the same files etc… which also leads to a sink in time as well, and some people can get locked out of adding-value for a while. This is really bad.

It is probably worth spending some time:

• Structuring your project/solution/repo.
• Figuring out who is responsible for what.
• Finding a way you can all get a dev/test environment locally.
• Ensuring you are all totally up-to-speed with basic git usage.

9) Always take a graphics guy with you

Adding some polish to any project is hard when you’re completely ignorant to graphics/design/ux etc. (just like me!). To get some WOW! factor from others, make sure you have somebody on board that gets it.

It’ll make you feel better.

10) Always take a domain expert with you

Or maybe, don’t try and build something that nobody understands in your team. It’ll be a massive time sink much like point 2 (above).

Closing thoughts…

It was a great way to finish a year of some great developemt fun.

We joked during the start of the event that we should have been plumbers - and then took the joke futher, wondering if plumbers would use some of their Christmas holiday to hang out with other plumbers and plumb an entire house in a few hours… in the name of fun!

Probably not - it seems a completely crazy idea.

So I guess as software developers - we’re pretty blessed; we do something that earns money, that we rather enjoy.