While hackathons can be all fun and games, they can also be incredible opportunities for learning and growth. To tap into this value, though, you need to consider things carefully. As a regular hackathon attendee, I've picked up a few helpful strategies. Here are the things I now do to get the most out of each hackathon. Check out the infographic below!
Before the hackathon
1. Decide your goal
Initially, I wanted to use hackathons to build a public profile. Because my aim was to win prizes and get recognition, I focused on competition-type hackathons. I soon realised, though, that the real untapped value of hackathons was exposure to new technologies, meeting interesting people, and long-term business opportunities. This led me to start looking for hackathons that could cater for these goals.
At the outset, I find it useful to ask myself: "What do I want to achieve by attending?"
1.1 If your goal is experimenting with new technologies...
I decided to purposefully start choosing hackathons based on whether they'd offer me the opportunity to learn new languages and play with new tools. In my everyday life, I would keep a list of cool tools and technologies that I wanted to explore, but didn't have time for in the daily grind. Then, once I heard of a hackathon, I could return to the list to see how it matched up with what I wanted to learn.
To figure out if a hackathon would give me the chance to play with my technologies of interest, I would:
- Look at the hackathon's details to infer its focus and culture.** From this, I could figure out what kind of individuals would attend and whether they'd be working on the things I'm interested in.
- Look for suggested tools, technologies, services, and so on on the hackathon's website. Using this, I could get a good feel for what kind of tools and technologies I would be able to use. I would specifically look out for access to restricted tools, for example expensive proprietary software, that could be downloaded from the hackathon's website. If these were available, I knew that there would be an expert on hand at the hackathon — a free one-on-one tutor, essentially!
TIP: Apart from giving you a chance to explore technologies that you've been interested in, a hackathon can also be a good place to discover new technologies. If you see someone using new tools, technologies, services, or techniques, ask them why they use those ones instead of the ones you usually use.
Key question: Will this hackathon give me the chance to play with my technologies of interest?
1.2 If your goal is networking and building community...
Get a feel for the culture to figure out who'll be there: The more you attend hackathons, the more sensitive you'll be to their different cultures. The individuals who join a FinTech hackathon will have very different interests and skills sets to those who would attend a WebDev or Medical Hackathon. Going forward, you'll be able to infer the culture beforehand more easily.
A common question: Should I take my buddies along? In most hackathons, I'm looking for the cross-pollination of my ideas, approaches, and so on. In those cases, I make a point of not organising a group of friends to go along, because this creates the temptation to just stick together and not meet other people. However, when I know that many people will be attending a hackathon and that I need some extra "eyes and ears", I'd organise a few buddies with different skills to come along. We would work with different groups, meet different people, and then debrief with each other afterwards to share details of whom we met and what we learnt. If we don't find solid people to work with at the hackathon, we can always fall back on working with each other.
Don't forget about the organisers: It's easy to forget that the people organising a hackathon are often very interesting in themselves! I try to get more information on the organisers beforehand to make a call on this. At the event itself, I would then make a point of talking to the organisers, figuring out what matters to them and their organisations, and determining if that's similar to my goals. That way, I can build a solid connection with them.
Key question: Who is organising the hackathon and who is likely to attend it?
Remember, it's a great way to develop social confidence! As a heavy extrovert working in a small team, it sometimes feel like I'm not getting enough social interaction. Hackathons give me the 'social boost' I am looking for. As I've attended more and more hackathons and worked with different people, I've gained a deeper confidence in my social skills as a software developer. That confidence in myself has rewarded me in my daily ability to build things with other people, and have useful interactions with my clients.
1.3 If your goal is creating long-term commercial value...
Put yourself in a business mindset: Once I had attended a good number of hackathons where I focused on tools and technologies, as well as meeting interesting people, I shifted my focus. I asked myself how I could create commercial value from the things I was experimenting with and the collaborations I had with other hackathon attendees. I started asking myself: How could I find or create concepts that would be valuable in my current work environment? Or even: How could I come up with ideas that could turn into new businesses?
I realised that I needed to go into hackathons with a business mindset. For the things I'd be involved in creating, I would ask myself:
- Why would I purchase this product?
- How much would I be prepared to pay?
- What benefits would this give me?
I would then ask the same questions to my group members at the hackathon, other groups, as well as the organisers. In this way, I'd essentially be doing basic market research. I found this 'instant feedback' from other similarly-minded individuals to be very helpful, particularly when it came to technological concerns about a particular business idea.
Be mindful of intellectual property (IP) issues: The key concern with creating long-term commercial value in or through a hackathon is obviously IP. It's important to remember that at some hackathons, the organising company can claim ownership of all IP generated through the hackathon. In others, it's up to the group you're working with at the hackathon to determine who owns the IP.
Key question: Does the hackathon in question have a friendly IP policy?
2. Find a hackathon
Search online: Once you have a clear idea of why you want to attend a hackathon, you can start looking for hackathons that match your needs. I keep an eye on these sites when I'm on the lookout:
Keep your ear to the ground: I've built up a network of 'hackathon friends' whose goals are aligned with mine. When we hear of cool hackathons, especially when they're not advertised publicly, we'd send each other invites to keep each other in the loop.
On the day
1. Be prepared to take notes
I always keep a pen and notepad next to me to scribble anything I observe that is interesting. I make a point of keeping notes about the outcomes of the hackathon. I go into the hackathon asking myself:
- What was developed?
- Who attended with me?
- What was valuable?
2. Have the practicalities sorted
Always have your developer essentials with you. For me, these are:
- My laptop and charger. I always make sure my laptop is fully charged before I start.
- A solid IDE.
- Any tools or technologies I want to test out.
- A portable drive with enough free space for virtual machines. That way, I can easily spin up testing environments and explore things without any risk to my daily system.
- A comfortable USB keyboard. I can easily plug this into a group member's machine if I need to type something on their computer, so I still have the comfort and speed of my own keyboard. You'd be amazed how much a millimeter of difference in key presses matters!
- Any specialized hardware.
Bring the creature comforts! Most hackathons I attend span over 48 hours, just long enough to need the good things! They are:
- A pillow
- A blanket. I like to show off with the one I assembled from geeky shirts!
- Paper and reliable pens
- Clean clothes
- A headset. Given that the hackathon is a collaborative environment, I rarely use these. When it comes to grinding on the actual development work, though, it's really useful to be able to zone out. Headphones help me give others a visual representation that I'm trying to focus.
3. Find a group
For the first hour of the hackathon, I try to be as social as possible, networking with everyone and showing others that I'm open to forming a group. I try to make mental notes of who's who:
- Are they willing to form a group?
- What are their expectations for the event?
- Are they knowledgeable about the tools or technologies I'd like to learn more about?
TIP #1: Don't plug any of your equipment in until you've found a group of the hackathon have passed. You don't want to be anchoring yourself to a specific spot, thereby removing your flexibility to join people in other spots. You also don't want to make yourself seem inaccessible to others. (Not plugging in anything also removes the risk of people tripping over your power chords as they move around!)
TIP #2: Don't be afraid to be upfront with people regarding your goals. For example, I sometimes say: "Hey, I'm here to meet new people and build something awesome. You look like someone interesting to work with. Are you keen to work together?" That way, you can quickly find out if people's goals are aligned with yours.
TIP #3: Build a human connection; it's not just about the 'transaction' of working together at the hackathon! This creates the base for lasting, long-term collaborations.
4. Brainstorm ideas, set expectations, and take stock of who can do what
Once I've settled into the group, I try to talk to my group members about their ideas and help us move towards a project that all members can be involved in. Here, the business mindset is of particular importance: If some of my group mates and I intend to create long-term commercial value out of the hackathon project, I try to encourage everyone to buy into that approach.
It's important to set the expectation that we see the hackathon project as something reaching beyond the 48 hours of the actual hackathon. It's also important to chat about IP considerations from the start. Setting expectations early on creates an environment of trust; it also lets you quickly spot if someone isn't on board with that.
Next up, it's useful to get an idea of who can and wants do what. The idea is to explain your skills while still stating your needs. This format works well to do this:
"I am skilled in [your skills] and can contribute to [what part of the project you can contribute to] this project. However, I have been interested in [what you've been keen to experiment with], so I'd love to pair up with [person has said they're skilled with those things]"
5. Don't jump into coding immediately
Planning trumps code. In one hackathon, my group and I spent 12 of the 48 hours just understanding problem and planning a solution, while others jumped directly into coding. We ended up finding an interesting business problem, came up with a solid way to solve it, and learned more about each other's skills and abilities. In the remaining 36 hours, we created an MVP. I feel this approach was instrumental in helping us win the event.
6. Time to grind!
Given that hackathons are so short, it's really difficult to build something cool. How you approach your project is key. These strategies have worked well for me:
- Break your project into small, easy-to-understand sections. This makes it easier to identify the expert for a particular task, and makes it easier for all group members to contribute something valuable.
- If you get stuck, split up and try different solutions. When my group and I get stuck on a particular problem, I find it useful that we split up, each try a different solution, and then get back together to decide the way forward. It's important to timebox this: we made sure that we met up again after an hour of experimentation. Splitting up meant we could quickly get a good grasp of each approach's advantages and pitfalls, helping us get to the correct implementation faster.
7. You're building an MVP, so focus on the front-end and remember the presentation
Because you have so little time in a hackathon, it's important to remember that you can build an MVP at best. This means that you need to build the minimum to prove your concept. In my experience, the frontend of the concept turns out to be a lot more important than the backend. The backend does need to be sufficient for the job, but further than that, it can be completely bare bones. Instead, I find it useful to spend more time on the front-end, because that's the interface between your product and your users.
TIP: Don't forget the "wow" factor for the presentation! I've never heard a judge say "I really love the back-end, but the front-end needs a bit of work. Great job!" The frontend comes at a premium.
TIP: When you present your product and something goes wrong, don't get discouraged! Smile and remember that no-one expects you to have a perfect product after 48 hours. Be like Howard Stark in Captain America where he says: "I did say a few years didn't I"!
After the hackathon
1. Rest first!
Once the hackathon is done and the dust has settled, it's important to reflect. However, get some solid sleep before anything else! It's important to properly recover, because a 48-hour, sleepless hackathon can be super exhausting!
2. Reflect on the learnings
After I've gotten good sleep, I start reviewing my notes. When I do this, I try to remember interesting things that I might have missed. I try to ask about:
Tools and technologies:
- What tools and technologies did I work with?
- What did I learn about them?
- What problems did they help me solve?
- How can I action these learnings in my daily life to make myself a better developer?
People:
- Is there someone who was interesting with whom I wanted to spend more time? How can I stay in touch with them?
- Who seemed like a good mentor? How can I stay in touch with them?
Useful resources
Download the 'How to get the most out of hackathons' infographic here
Jo Pearl is an independent software developer who loves working with others on the on the next big thing.
