How to hack a Hackathon: Hackathon 101
The Low-Down
(The main article and links to the other posts on How to Win and Industry are linked here)
The Myths and the Truths
Programming (and its related events) has a reputation. A general scene tends to be described as such — introverted nerds in their mom’s dark basement spitting out green text on black screens like a scene straight out of the Matrix.
This is not entirely wrong. Green on black is fairly easy to read and, let’s face it, it does look cool. But tech events, especially hackathons, are much more than this.
A hackathon, in 99% of the cases, has nothing to do with the hacking that one knows of from the movies. That is, no one is breaking into computers and stealing information during the course of the event. The 1% of the cases probably are badly named Capture the Flag events which focus on such themes. Rather, a hackathon is an attempt to build (“hack”) a clever solution to a tricky, often associable problem. (How can we help the aged? What can we do to solve problems in country X? Can technology enable women in less-developed countries?)
There are a whole array of events that fall under the ambit of a hackathon but all of them have something in common.
- The event operates under a time limit. A typical hackathon lasts anywhere from 24–48 hours but they could be anywhere from an 8 hour design/prototype sprint to an activity that happens over a week. The level of deliverables changes accordingly but suffice to say, a time limit means that only a finite amount of work can be done.
- It is common to encounter a theme or a multitude of themes. Having a theme is great — it provides a frame within which one can brainstorm and execute, especially when time is of importance. It’s like writing poetry; if you write free verse it’s quite likely you’ll end up staring outside the window while sucking the end of your pen, getting nothing done in the process. But if someone told you to write in, say, iambic pentameter and obey certain rules then it would feel like filling in the blanks and would, overall, be an easier task. Hackathons I have attended have spanned topics from healthcare and ageism to beer consumption experience and everything in between. Even when events don’t have prescribed themes I personally find it easier to go in with a problem to solve or, at the very least, a domain I would like to build for.
There are other things that are common at hackathons such as swag which comprises a whole bunch of sponsored goodies including (but definitely not limited to) stickers, t-shirts, hoodies, socks, water bottles, portable chargers, and more. Everyone likes free, functional goods and brands get a walking billboard in return. Everyone wins, sort of.
And, of course, there are prizes for your work. It could be $$$ or a bunch of things that come from the sponsors. As a cash-strapped university student, actual money was always welcome but free credits for AWS/Bluemix or even opportunities to travel were always great. (My personal favourite prizes were from Tech In Asia’s Hackathon which sent me to watch Manchester United at Old Trafford and from Angelhack Singapore which provided an opportunity to attend CES in Las Vegas.)
Must I be a programmer to enter one?
Absolutely not. Hackathons are great places for people from different domains to interact and build cool things together. Whether you’re a UI/UX Designer, a Product guru, a domain expert in, say, advertising, or a programmer — everyone is welcome to join a hackathon. Obviously, your area of expertise will lend you support as you conceive a solution to a problem but hackathons are perfect avenues to pick up new skills; I remember going to our second hackathon and wanting to build a heatmap to plot out dengue outbreaks but both my teammate and I didn’t know how. A lot of Googling/Stack Overflow and tinkering later we had our product patched together, ready to be presented, and we had managed to pick up a nifty little skill that oversells in today’s world as Data Visualization. Neat.
What else happens at a hackathon besides making new things?
A lot of hackathons, especially those that are beginner-friendly or domain specific, offer various avenues for learning. Some events like the #startathon in Singapore includes masterclasses that are held through the event in specific software and hardware skills as well as in business logic to allow teams to make products that aren’t just technical but also address real-world problems. Other hackathons like HackingEDU in the USA provided for panels through the night with keynote speakers like Sam Altman from Y Combinator and Salman Khan from Khan Academy, both of them being great names to learn from when building a product and while operating in the education space. A lot of learning opportunities all around.
Why should you go?
See I have no intention to evangelise and force you into the cult of hackathons. People are busy and have things to do, and that’s fine. You might convince yourself of moral upsides or downsides for activity Z but at the end of the day it’s all about utility.
So, what’s in it for you?
- You get food, drink, mentorship and a venue to sit and work on a product you don’t usually get to do, that too with a group you generally don’t work with and with an opportunity to win good prizes. I can’t even see the downside here. Rarely do we venture outside our bubble to solve problems that bother us and hackathons are the easiest place to do this. If not for the problems, then at least the confluence of so many factors makes it a unique experience.
- You can’t fail. We always worry about what could go wrong, the utilititarian humans that we are. Hackathons allow you to fail. There is no real-world repercussion if you work on something that does not work. This allows for participants to experiment and find more unconventional ways to solve problems. Furthermore, it builds confidence in some of the new skills that you might choose to acquire during the event. It’s one thing to learn skill X and a totally different thing to not only learn X but also see it in action. See the fruits of your labour and take pride.
- Hackathons are the easiest way to ramp up ones portfolio and the breadth of domains it encompasses. Conversely, you’ll find yourself reading about fields you wouldn’t usually explore; I, admittedly, don’t read or care much for how I can influence fields like healthcare or the environment beyond the usual methods but hackathons forced me to explore more issues within these fields, create empathy with people who face these problems, and try to use technology to address them. I wouldn’t have had any easy motivation to do this otherwise.
- Teamwork and communication are skills that are sold as byproducts of any team activity and hackathons are no different. The pressures of a timed event brings out the best and worst in people and this, quite interestingly, mirrors the working world where communication breakdowns are passive-aggressively tweeted about. Hackathons form the microcosm that allow for that experience. Masochistic, but important. Communication extends to beyond the team i.e. product presentation. Clarity of thought and the ability to explain what you’ve done and why you’ve done it is critical in ANY line of work and hackathons zero-in on this. When you have 3–5 minutes to make a pitch, being clinical in your delivery goes a long way in selling the judges and the audience on your product. I had practice doing this, in a way, when I was a debater but hackathons provide nearly the same adrenaline and pressure to pick this skill up.
- Networking. Ugh. I hate the word because of what it’s become — a meaningless interaction focused on getting a namecard — but, yes, hackathons are a great place to meet people in your ecosystem. All the cool kids are there — Professionals, fellow designers or developers, matter experts. There are not many events that bring an audience as diverse as this under the same roof at the same time. Some of my best friends in the tech space were people I met at hackathons
What do you need to get started?
(The obvious step before the matter below would be to find a hackathon near your location. A quick Google search should get you going but some groups like MLH maintain calendars for hackathons in their region — this one’s for North America, for example. Some websites like Devpost and HackerEarth also have postings of global hackathons/online events.)
Before the event
It is important to set expectations. Things that can go wrong will go wrong and it is OK. Code will break, ideas will change, it will be freezing cold and the WiFi will drop because someone decided to hog the bandwidth and watch Netflix. It helps to mentally be in a state wherein you’re adaptable to changing scenarios at an event like this; remember, you can’t fail!
Embrace the chaos. Zen.
If you’re going to stay overnight at the venue pack a change of clothes, a snack/energy drink or maybe some toiletries to wash/freshen up later in the day. I’ve even seen some ambitious participants (including one of my teammates) carry sleeping bags to the event. By all means, prepare yourself once you have the event plan at hand. It will make for a more productive event for you!
Take some time to think if you know your theme ahead of time. I’ve wasted plenty of time at hackathons not knowing what I want to work on, and consequently not having enough time to build what I started. We’ll discuss brainstorming in the next post but, suffice to say, think about what you might want to do with your time at the event.
At the event
Most hackathons provide for team formation opportunities and if you’re a solo participant you might want to make the most of this. The reason I asked for thinking before the event is because it’ll make your life easy while looking for teammates. The usual pitch is this:
I am X.
I do Y/I am good at Y.
I am looking for Z to build/work on ABC.
You could skip out ABC if you’re not sure on what you want to do but at the very least you should manage to introduce yourself and form a team, preferably with skillsets different than yours. A diverse team provides for a variety of opinions and complementary skillsets — all important while brainstorming and building a new product.
When deciding what tools to use for programming/building out the product remember one thing — no one gives a sh!t what new language or hardware you used to build whatever you made. At the end of the day, a hackathon is a show and tell. If you can show what you’ve built to work and why it matters then you’ve done your job. Additionally, it is worth considering setup time as well as the skillsets of your teammates who will jump in to support you. So give this a thought — if you want to work on an ambitious product involving VR, do you have the tools/people at hand? Is download and installing Unity and its plugins the best way to do this or could you build something over the web with ThreeJS, which would be less comprehensive but easier for your teammate to help you with and get the job done? Similarly, if you’re planning to build for a mobile phone, do you need the solution to be mobile-first and written in Android Studio/XCode along with all the emulators set up? Or are there easier ways to get your product and your point across?
Regardless of your choice of tools, there are many starter kits and boilerplate code templates available for you to build upon. Don’t reinvent the wheel — focus on the value that you plan to create.
Having a clear decision roadmap helps me allocate time and responsibilities across my team effectively. We get plenty of sleep and often produce a polished product.
Conclusion
This piece is a painful reminder that I should be writing more, and often.
It is also a clear low-down on what a hackathon is, why you should be at one and what you need to get started. In the next post I will share with you some of my secrets on how we win at hackathons.
