The closest I’ve ever come to running a marathon was a 10km “fun run” that was part of a marathon event—but, even at a quarter of a marathon, the type of endurance training that long-distance running required gave me a new perspective on pacing. Before that, I had always thought “running” was synonymous to “speed,” so this idea that you could set your sights on a destination, no matter how far, and get there eventually by controlling—and, over time, iteratively improving—your pace was pretty inspirational to me. It wasn’t about sprinting at your fastest from the get-go, but more about increasing the pace that you’re comfortable going at.

No wonder then that marathon metaphors are often used to describe long, oftentimes gruelling feats—most notably life—so much so that portmanteaus of the word exist, from telethons for fundraising to hackathons for building software. Having recently participated in my first hackathon, I couldn’t help but think about this analogy as I reflected on my experience: How did my first hackathon compare to my first quarter-marathon?

It’s a marathon, but also a sprint

Like a marathon, a hackathon feels like it’ll never end—except, before you know it, it does. It’s an unusual event where you need to build a proof of concept in an extremely short period of time; in other words, you need to hustle. As a lover of taking one’s sweet time to come up with a plan and then following said plan, this proved challenging for me, but it also helped me realize a few things.

First off, it’s a good idea to go for hacky solutions straight away, and not as a fallback 5 hours into the start of the hackathon when you’re knee-deep in fixing an irrelevant error and haven’t yet started building your actual idea. Hacky solutions can be difficult to recognize as viable—and sometimes even to think of—when you’re used to trying to find the “cleanest” way to do things, as most of us are with our everyday work. This includes the code you write; your fingers’ muscle memory may block you from writing nested if conditions and try to encapsulate everything into its own pure function. It also includes any pre-implementation work like planning and architectural design. While some of this may be necessary, it’s a good idea to avoid the temptation to fine-tune all the details before you start. Don’t stretch too much.

Taking all the shortcuts you possibly can at first—including writing “dirty” code, or code that is as dirty as code can be while still maintaining a level of intelligibility—doesn’t just save you precious time. By removing layers and roadblocks, you can focus on solving your actual problem, and not a problem in another service that you added as a gateway because that’s the “right” way to do things. (Remember, you can always go back and do it the “right” way if there’s time.) Because of this, practicing hacky approaches challenges you to come up with the simplest solution. By removing garnish, getting to the core of the problem, and working iteratively, you avoid overengineering your idea, while simultaneously building your appreciation for aspects of the “right” way (clean code!). Also, it can be liberating to just jump right in with no red tape—a fun day (and useful life exercise) for those of us who usually plan everything to a T.

Eyes on the finish line

What gets people through long, gruelling journeys? Recognizing that the only way out is through. What’s your goal out of this? In a marathon, is it just to participate? Is it to finish the whole thing? Is it to beat a certain time? Similarly with hackathons, it’s a good idea to keep your end-goal out of the experience in mind. Your choice of idea and team may differ based on whether your goal is to network, win, or learn a new technology. And you can always aim to do all three.

Your personal goal isn’t the only finish line in this race, however. Most hackathons will also have a theme or an objective. Choosing an idea and an implementation strategy that will have a strong impact towards the overall hackathon objective will not only increase your chances of winning, but will also help you have more relevant conversations and learn more about the topic at hand. It’s also not a bad idea to reflect on how you can achieve your personal goal given the theme of the hackathon—how do the two match up?

Running as a team…

In most hackathons, you don’t work individually but in a team. This means that, unlike marathons, you need to factor in other people, and not just as competitors. It’s a good idea to base what you’re building on the backgrounds of the team members or vice versa to make sure everyone gets something out of the experience. Working in a team also means you will need to coordinate. Although you don’t want to spend too much time planning upfront, you can take some time getting everyone on the same page at the beginning and continue aligning throughout the hackathon to ensure that stays the case and to support each other when needed. This was actually one of my key takeaways from the hackathon: Sometimes you need to remember to ask for help and to let people help you. This goes not just for your fellow team members, but for everyone at the hackathon, including other software engineers who may be more familiar with what you’re working on, product managers and designers with more business and UX understanding, and hackathon runners familiar with the event format who can give you tips on how to move forward if you’re stuck

In fact, a lot of your time at a hackathon will be spent communicating. Aside from discussions with your team members and other relevant stakeholders, you will typically need to pitch your idea at the beginning and to present your outcome at the end. It can be challenging to shift from build to present mode, but it helps you practice discussing your work with other sentient beings. After all, if a tree falls in a forest and no one is there to ask it if it’s ready for production, did it really fall?

…and giving it your all

A hackathon, like a marathon, is an intense experience. The chance to throw yourself completely into a new adventure for a few hours or days can be rejuvenating. (I always knew side projects were important but now I can feel that importance.) Since it’s communal, you get to bond with your team members and other participants as you collectively crawl to the light at the end of the tunnel. After months of working from home, freaking out with other people was a welcome change to doing it solo.

But hackathons can also be too stimulating, maybe to the point of being stressful. The collective aspect of the experience may help you avoid getting sucked into the wormhole of a looming fast-approaching deadline where food, sleep, and sanity are forgone. It’s also important to actively remind yourself that your “all” is your all after staying healthy, resting, and having a good time; it doesn’t mean draining yourself.

After all, the best part of the experience? It was really fun.

Thanks to Karim Kamaleldin for his comments on the first draft of this post.