Completed my first hackathon!

Published: 2016-03-10

It was such a amazing experience. There’s no such thing that make you, and your teammate pull a all-nighter and still gives you one of the best times of your life, except hackathon. (Hackathon rocks!) I want to share with you what it was like, if you don’t already know, and some thoughts about it.

My company started its first ever hackathon last Thursday at 8 am. All submission were done on Friday, 12 pm and the whole afternoon is for presentations and demonstrations. The basic idea of hackathon: it is a project competition that’s done during days of marathon-like intensive working/hacking. Participating teams get unlimited supplies of coffee and red bulls. Indeed this sounds very terrifying.

When I use the word “hack” it is not exactly the same thing we pictured of what computer hackers do. For here it is more generic. Hacking is “to interact with a system in a way that the system don’t want you to.” For example, to gain access to another person’s online credentials without permission. Obviously, in usual use cases, the system wouldn’t want you to. Another example, to write a backdoor in your company’s commercialized software even though your company does not allow you to. Yeah, these are hacking.

During the hackathon, not only did our team hacked a backdoor in the system, but also did we hacked the system software architecture (a little) in order to get our parasite-like software running on top of it. I believe we had embraced the true spirit of hacking.

But those did not really matter. The biggest enemy in hackathon, in my opinion, is perfectionism. The 80–20 rules works very well here — if you can make 80% of the things to work with 20% of the efforts, why spending the rest of the 80% of time? If spending 20 mins hacking the system could get the software to work, why spend the extra hour or so? That’s what we ended up doing a lot through the hackathon.

Honestly, this isn’t my first ever hackathon I’ve attended. However, this is the first ever hackathon that I finished. The difference is, I didn’t understand my tools well enough the previous time so I ended up spending a lot of time on the web searching for answers I should’ve known by the time. This time was different. I gain much more experience in building Flask web app throughout the course of past few months. Knowing my tools well enough, I’ve built-up the necessary coding muscle memory that I don’t need to consult the documents so often. This gave me the edge to be able to construct my idea into code more quickly.

A little bit about my hackathon project: the software stack I’m using is Python Flask for backend, and my crappy Bootstrap skills for frontend. The project idea is to build a automated task scheduler web service on top of the existing system. Writing the web service wasn’t the hardest. The most difficult challenge is to integrate the web service into our existing system. OMG, I can’t tell how much relief it felt to see those pieces working together for the first time.

I’m very proud of what my team had achieved in the hackathon. However, there’s one thing till today I still think that I could have (and should have) done better is the demo. I admit that we didn’t put too much thought into the demo. All I think was that we were going to BLOW EVERYONE’S MIND just by showing it. Turned out it didn’t. Our way of presenting the software wasn’t very engaging to the judges. If I could go back in time to where we started the hackathon, I would’ve punch in my nerdy face and told him to sit down and think about the demo. Think about what you want to present in the demo. And be focused on making that happen. Everything else is the extra 80% burden that drags you along the way.

It’s amazing how things are so clear afterwards. I got two lessons learned in the end: 1. Know your tools well — go build up the coding muscle memory! 1. Design for demo — keep demo in mind all the time!