Hackathons are really fun. Unlike college, where most projects in class are set in stone, hackathons are loosely structured, which gives a lot of flexibility on the wide range topics that can be pursued in 24 hours. Things can become easily scattered, though, even when there is a set theme behind a hackathon. Which means one of the first (and hardest) steps that need to be taken is to come up with an idea to work on.

The thing that is most important to ask is: What do I want to achieve at the hackathon? What do I want to make? Why am I here? Without any set direction in a hackathon, there is no point to hacking. I may attend several events, enjoy good food, and meet many hackers, but if I initially plan to create something, and end up not building anything, I've just wasted my time. And that is one thing I absolutely cannot stand. That's why the first thing I do at a hackathon is brainstorm.

Brainstorming is important because it helps create ideas. Once a feasible idea is found, the possibilities are endless, and a team can have its foundation rest upon it. In that moment, everyone in the team has a goal. I love that moment when an idea comes to fruition, especially when everything seems hopeless. At times when everyone is sitting around, trying to dig up a plan to follow, someone may casually throw something that causes everyone's ear to perk. In that second, the group experiences an epiphany, and everyone immediately jumps into action, fleshing out the idea from the mere figment of thought it once was into a page long plan that can be worked on throughout the hackathon.

Once the idea is created, assigning tasks must be completed. Each person must be willing to take on some responsibility throughout the hackathon, and these tasks cannot be randomly picked. This is where team composition becomes very important for a hackathon, and diversity is key. Not everyone can just know the same thing. I am not discrediting developers, designers, managers, etc... as being unable to handle tasks amongst each other. But with diversity, there is so much more potential to be achieved; more pizazz that can be can be tackled and accomplished together as a team.

After a sleepless night of planning and coding, the final thing to prepare for is a pitch and a presentation. 24 hours of hacking can all go down the drain if a presentation doesn't catch a person's eye (especially my own). When presenting something, if judges glance over my project with disgruntled side eyes before walking away to talk to a more interesting hacker, I will feel devastated. I've experienced this before, and honestly, it's hard to remind oneself in the moment that a project's value is subjective to the viewer. This is why no matter what, in the last few hours of a hackathon I always make sure to work on the presentation of the project, whether it's a small demonstration of the app, a powerpoint slide, or work on a quick blurb that defines the problem solved; something to give credit to the work I spent a sleepless shower-free night over. 

And once judging is done, a hackathon is pretty much over. It all comes down to waiting, sitting through the awards ceremony, and battling sleep depravity. No matter what, though, whether a prize is won or I leave caffeinated and empty-handed, if I did my best and look over my  project at its face value, especially with all the challenges and obstacles I had to overcome in order for it to come to its final form, I believe that I can disregard all those worldly things, such as prizes and other people's comments and views, and truly see that the experience gained at the hackathon was worth it all.

The views, opinions and positions expressed by the authors and those providing comments on these blogs are theirs alone, and do not necessarily reflect the views, opinions or positions of UT Computer Science, The University of Texas or any employee thereof.