Hacking 101 — Lessons Learned from My First Hackathon

Advice from reflecting as a 4x hackathon organizer

I attended HackNC during October of my freshman year — barely two months after I’d written my first line of code in my life. At the time, I didn’t know a thing about hackathons. I persuaded my best friend to sign up with me, but she had other obligations during the morning of the event, so I ambled around alone in Venable Hall at UNC, trying to figure out what exactly I was supposed to do.

Somehow, I entered a conversation with a group of other freshmen who were equally as confused as I was. We snowballed into a team of seven — eight, once my best friend was able to join us in the afternoon — and decided pretty early on that we were going to say “forget it” to the prizes because we’d be lucky to get a project done at all. It took us half the day to decide what we were going to work on before we settled on a text-based maze game in Java — a language that only two people knew in our group of eight. The rest of us were in Intro to Programming at UNC, which was taught in TypeScript at the time.

The Grind

The specifics of what happened after that were a blur as I tried to figure out Java, GitHub, and programming in general. Our maze project was… not the most beautiful project out there, which solidified our “forget it” approach to prizes. We took breaks to go to workshops and, of course, eat the free food that was provided. As night settled in, we relied on sugar from donuts, handfuls of Awake chocolates, and many cups of coffee to stay awake as we continued to plink away at the bugs plaguing our simple maze game. I don’t even like coffee, but I don’t think I’ve ever gone to a hackathon without drinking at least a cup.

Around 2 or 3 in the morning, my teammates were ready to call it a night. Our maze game had transformed into a tool for kids to learn math. As the player navigated the maze, monsters popped up at random, and only solving a simple math problem could vanquish the beasts. Answer wrong, and the player would lose health. At the time, however, we were stuck trying to code in the health (HP) system. In fact, it was somehow crashing the rest of our game, so we agreed to drop it for now and come back to it in the morning if we had time.

While my team returned to their dorms to sleep, I found myself unable to pull away from my keyboard. I spent the entire night trying to implement the HP system alone in my dorm room. Looking back on it more than two years later, I can’t imagine why it was so complicated, but for freshman me with no coding experience, it was 8 AM by the time I’d gotten it figured out. I sent a text to my team letting them know it’d been fixed, and then I passed out.

When I woke up again, it was 11:30 — past the project submission deadline. I ran back to Venable Hall to discover that my team had missed my text and submitted the version without the HP system where we’d left off the previous night, which used hearts to measure health instead. Oddly enough, I wasn’t even upset. I was just glad to have figured something out, and I had to admit that the heart system was more fluid for the gameplay anyway.

The Demo

When I say this project was ugly, I mean… Rather than updating the maze when the player made a move, it printed a new grid every time. The walls were made of vertical slashes (|) and underscores (_). It wasn’t hosted anywhere; we ran it in Java Eclipse when it was time to demo. We made sarcastic jokes about our project the entire weekend, calling ourselves the “Dream Team” ironically, and subsequently naming our project “Hello, Dream World.” If you want to take a look at exactly what our project was like, here’s the repo. But hey, we demoed nonetheless.

The group on our left had created a project using an Amazon Alexa, which I couldn’t even imagine doing at the time. We weren’t fooling anyone in thinking ours was a prize-worthy project, but we demoed it with the same enthusiasm as any other group, using buzzy marketing words and introducing it as “a game designed to help young children master basic math skills,” even though we knew no child would give our game longer than a glance, the way it looked. We also probably looked silly as an eight-person team when most other teams maxed out at four — the number of prizes that were allotted for each category. Still, we got one really enthusiastic judge that was excited for us for completing a project at all when we were all just starting out! Most importantly, we were happy.

From Hacker to Organizer

HackNC 2018 has been one of my favorite college experiences to date. That semester, I would go on to participate in three more hackathons — HackDuke at Duke University, HackGT at Georgia Tech, and Hack110, which was hosted by my Intro to Programming class. At none of these did I ever seriously compete for prizes. I just showed up for the atmosphere. (Okay, and the free stuff.) Hack110 was a particular personal success for me because I surprised myself with how much I’d actually learned during the semester!

I loved the hackathon experience so much that I joined the organizing boards of two hackathons at my university — the Carolina Data Challenge and Pearl Hacks. Since then, I’ve gotten to handle budgets of over $50,000 and reach hundreds of participants across both events.

With Pearl Hacks coming up in less than a month, I’ve been searching for tips to send to participants, many of whom are coming to Pearl Hacks for their first hackathon ever! However, when I Google for hackathon tips, many of the articles are geared towards winning. While winning prizes is a lot of fun, it does not have to be your main focus to have a great time, so here are a few non-technical tips to make the most out of your first hackathon!

Know Your Goals

You can get a lot out of your hackathon experience, but the entire event is only 12–48 hours, so it’s helpful to know what you want before you get started. You don’t need to have a 10-point plan or anything like that, but answering some broad questions for yourself can help you hit the ground running.

Do You Want to Compete for Prizes?

I hate putting this question first because I think hackathons are very valuable whether or not you’re there to compete, and I don’t want it to seem like competing has to be a priority. However, this is one of the first questions to figure out, whether your answer is yes or no!

If your primary goal is to compete, that means you’ll probably spend the majority of your time coding, which limits the other events you can participate in. If not, you get a lot more time to attend workshops, network, and join fun events!

Don’t worry if your answer changes midway through. There have been plenty of participants in the past who surprised themselves by completing a project, and there have been even more who decided partway through that they just weren’t feeling it. Either way, hackathons are flexible enough to allow a change of plans.

What Do You Want to Learn?

More specifically:

• Are you looking to brush up your technical skills?
• Are you seeking new career opportunities?
• Do you just want to see what a hackathon is like?

These are all valid reasons to go to hackathons!

For those looking to improve their technical skills, working on a project is always a great option! Most hackathons have technical mentors that can help you out along the way, and programming is one of those things that’s just best learned by doing. However, if projects really aren’t your thing or you don’t have the full weekend to commit, you can also take a look at the hackathon’s technical workshops and see if there are skills that interest you.

Hackathons can also help you get your foot in the door while recruiting. Many hackathons hold sponsorship fairs where you can interact with their sponsor companies. Sponsors might also interact with participants through the hackathon’s communication channels like Slack or Discord, and some might serve as technical mentors too! If you’re planning on participating in a hackathon’s recruiting events, make sure you come prepared with an updated resume and an elevator pitch.

If you’re just going to a hackathon for the heck of it, that’s okay too! In that case, you can pick and choose events that are interesting to you. After all, the hackathon organizers are creating the event for you, and they want you to have the experience you want.

Talk to People!

We all know the stereotypical image of a programmer — a man slouched over a laptop in a dark room, typing away. By now, hopefully you’ve realized that this is not what programmers are like, and this is definitely not what hackathons are like!

When we could host events in person, one of my favorite parts of being a hackathon director was wandering around the venue, striking up conversations with teams, playing board games with participants, and seeing what awesome projects people were working on. This is coming from a huge introvert. Take breaks when your social battery runs empty, but if you’re feeling up to it, it’s worth a shot to chat up other people!

With the online format, it’s a lot harder to initiate conversations, but that doesn’t mean it’s impossible. Many hackathons use Discord or Slack as a communication channel throughout their event, and that’s one way you can ping people who seem interesting! If the hackathon’s communication app has a channel for casual conversations, take some time to check it out. If they have one for introductions or networking, say hi in there and follow up with anyone who you think you could have a good conversation with.

I still keep in touch with some of the members from my first team at HackNC, and it’s always great to see what neat things people go on to do! Meeting people at a hackathon will make your time there a lot more fun and memorable.

Use the Hackathon as a Launching Point

Once again, (most) hackathons are only a weekend long, so don’t expect your most polished work to come out of it. If you’re working on a project, focus on the big picture — the problem you’re trying to solve, and how your project addresses it. It’s better to have a rough, complete project than it is to have a polished one that doesn’t work because it’s only half done. It’s also better to have a half-finished project than none at all because you spent the whole time thinking about minute details and never actually got to coding. You can always build on the fine details later on if you decide to continue pursuing what you worked on, so take the weekend to crank out some code!

This advice goes for non-project-related events at hackathons too! You’re not likely to build a lasting relationship with anyone over one weekend, so follow up with people that you met if you want to stay connected. 1–2 hour workshops are also not going to turn you into a master of any topic, so continue looking for resources on your own for any subjects you’re interested in.

Hackathons are meant to empower you to pursue technology, but it’s still up to you to do the pursuing!

Originally posted for Pearl Hacks.

Sincerely,

Lindsay