It’s Time to Rethink the Hackathon

It's Time to Rethink the Hackathon Featured Image

As we head into December with the largest COVID-19 spike of the year, I figured I’d take some time to talk about something that is essentially meaningless in comparison: the state of the hackathon.

That said, this was something I wanted to talk about because I just experienced my third hackathon over the past weekend. While three hackathons isn’t a ton of experience, I’ve noticed some trends that I think are worth discussing.

Also, as someone interested in hosting a hackathon at some point (shameless plug for one of my far away PatreonOpens in a new tab. goals), I think it’s useful to talk a little bit about what works and what doesn’t—if for no other reason than to reflect on my experiences. So, let’s get to it!

Table of Contents

Defining the Hackathon

Before I talk a bit about my experience with hackathons, it’s probably worth it to take a moment to talk about what a hackathon even is. After all, if you’re stumbling here for the first time, it’s going to be pretty hard to talk about where hackathons should go without talking about where they currently are.

First, a hackathon is basically a team-based competition where individuals come together to complete various coding challenges. In general, the goal is to try to create something within the time limit. In my experience, time limits have been anywhere from 12-48 hours.

Ideally, each team would create something entirely from scratch within the time limit. To ensure this happens, teams are often provided a list of unique challenges during the event. Usually, the host will have some overarching challenge while sponsors will have some as well. You can choose to complete any challenges that you would like.

In practice, challenges are fairly easy to predict—especially right now in 2020. In my experience, challenges are almost always related to huge issues like climate change and racial injustice. This year you can throw in COVID-19.

At the end of the event, teams are judged and scores are collected. Then, the winning teams are asked to present their work before receiving prizes ranging from money to gaming systems to laptops.

In the next section, I’ll give a quick overview of my hackathon history.

Quick History

Prior to grad school, I had never attended a hackathon. As an undergrad, I was often way too busy, and I didn’t exactly have friends in my major that I could team up with. Of course, as I got older, I realized that I had been missing out on something cool, so I decided to put myself out there when I became a grad student.

In my first year, I teamed up with a bunch of grad students. Over the course of the first day, we argued to the point of producing nothing. By the evening, we packed up and went home.

In my second year, I teamed up with a several first- and second-year undergrads. While things went much better—as in we actually developed some software—our solution at the end of the day was pretty underwhelming.

Ultimately, this year I teamed up with a couple upperclassmen who were fairly ambitious but motivated. Unfortunately, I wasn’t able to help as much as I would have liked, but I was quite please with their effort.

Over the span of three years, I learned a lot! That said, I have always left sort of disappointed or underwhelmed. While it’s possible that this is mostly on me and my expectations, I figured it wouldn’t hurt to take a look at some ways we could improve hackathons in general.

What Works?

Generally, I tend to be of the opinion that we need to blow systems up if we want any real progress. However, in this case, I think the format of the hackathon is already quite good. In fact, let’s talk about what works!

Building Community

One thing I find lacking in much of the tech space is a sense of community. After all, spaces like Stack Overflow prioritize gatekeeping and elitism over community, so it’s no surprise that much of the community has adopted similar values. Where else do you get to throw around a phrase like RTFM and not be perceived as a jerk?

That said, I think one space where this rule doesn’t apply is the hackathon. After all, hackathons are one of the few spaces in tech that actually bring people together. For instance, students get to come show off their skills in front of companies while having a little bit of fun with their friends. Likewise, companies get to build relationships with students while marketing their brand. All-in-all, hackathons seem mutually beneficial to everyone involved.

Naturally, this idea of building community played out in every hackathon I’ve attended. In all three, my teammates leveraged the event as an opportunity to chat with companies casually about internships. Similarly, I made a lot of friends along the way.

Creating Value

For the average student, there isn’t a lot of opportunity to create something valuable. After all, most professors refuse to assign open-ended work, so it’s unlikely that students will have a chance to explore their creativity until their capstone.

Of course, you might argue that students shouldn’t rely on their education to provide them opportunities to express themselves. Surely, if they want to create something, they should do it in their free time.

Beyond the reality that most students don’t really have the time or energy to be coding outside their courses, I don’t think it hurts to provide them a little bit of structure (and maybe even a bit of extrinsic motivation) to get them started. One way to do that is to provide events like hackathons where students get a chance to express themselves in a low stakes environment.

During this past hackathon, my teammates had come up with a cool idea that they seemed really passionate about. Had it not been for the hackathon, they might not have brought that idea to life.

Now, I have no clue if they’ll continue working on the project, but I suspect that initial fear of trying to build something is gone. Now, they’ll be inspired to try to bring other ideas to life.

What Doesn’t Work?

While I generally like hackathons, there are definitely aspects of them that could be improved. In this section, we’ll talk about a couple, but they basically boil down to one thing: competition. Granted, I’m sure there’s a bit of anti-capitalist propaganda in there as well. What can I say, I’m an angry lefty.

Solving Half-Baked Challenges

As I mentioned in the intro, hackathons tend to provide challenges when you get there. I suppose these challenges serve two purposes. First, if you don’t have an idea, challenges can help you come up with one. Second, challenges can help discourage working on a project in anticipation of the event (i.e. cheating).

That said, in my experience, challenges tend to be pretty boring and predictable. As I mentioned, if you’re even moderately in tune with what’s going on in the world, you can probably anticipate the challenges. Hell, if you can get a hold of the sponsors list prior to the event, you can probably guess what type of work they’re going to want you to do.

Now, this wouldn’t be a problem if companies actually took the time to develop their concepts. Over the last three years, I’ve tried working on company challenges, and I’ve almost always ran into issues because the resources they provide are outdated or underdeveloped.

For instance, this year I worked on a project for Microsoft. They wanted us to use their Graph API for whatever we wanted. However, their sample code to get us off the ground was bugged and never ended up working on of our systems.

Similarly, in the year prior, I had worked on a project for Engie who gave us energy data to visualize. Unfortunately, I spent most of my time cleaning that data instead of trying to do anything useful with it.

Given how short these events are, companies need to provide significantly more developed concepts for challenges. Or at the very least, they need to provide tools that actually work.

Also, side note: don’t make teams do your work for you. I’m so tired of companies crying about professional skills while simultaneously being incredibly underprepared for hackathons. It seems like half the time companies are just using hackathons to steal ideas. That’s gross.

Competing for Prizes

Look, tech is extremely competitive; I get that. Companies compete for contracts. Graduates compete for jobs. Students compete for grades. Competition is all around us.

Unfortunately, this culture of competition is deeply problematic. After all, it’s often tied to the idea of meritocracy which suggests that success and failure are tied to individual effort. As a result, a lot of folks are excluded, and this exclusion is rationalized as a natural process. I mean have you seen how many women graduate with degrees in computer scienceOpens in a new tab.? I’ll give you a hint. It’s much less than 50%.

Even during a hackathon, this culture of competition is going to cause some form of exclusion—whether it be outright sexism in teams or the implicit hierarchy between teams. As it turns out, this exclusion phenomenon has shown up in engineering education research:

“Are girls allowed to be on the teams?” a question asked by a high school junior, National Merit Scholar, female prospective student touring our campus engineering facilities. While we do not know if this observation deterred this female future engineer from majoring in engineering, it points strongly to the potentially negative impact of showcasing the preponderance of white males in SELECT membership.

The RISE Institute

That said, the exclusion piece is not really why I dislike competition in this context. Honestly, competition just gets in the way of trying to make cool stuff. Instead, teams hyper focus on satisfying prompts, companies, and judges rather than creating something that they’re actually passionate about.

The Future of the Hackathon

Look, I still really like the way hackathons are setup, but I always feel a little disappointed when things are all said and done. As a result, I’m wondering if there’s any way we can change up the formula and create something great. So, here’s what I was thinking.

Focus on Learning

Hackathons are usually targeted at university students. And unless you’re near the end of your degree or you’re particularly privileged, you’re not going to have the skills to create anything meaningful in 24 hours. Even worse, you’ll probably pick up some bad habits in the process. Take it from me! I’ve tried three times, and I have industry experience. As an alternative, I propose a hackathon where learning is the focus.

For this to happen, companies have to come to the hackathon with more of a game plan in mind. Rather than reacting to participant questions, companies might be a bit more proactive by spending the first few hours holding a workshop to teach folks how to use their toolkit.

While some companies do hold workshops, they tend to be of the “show & tell” variety. As an educator, I’d tend to advocate for something that involves more active learning. Maybe they could have a GitHub project that you clone and work through. Anything would be better than a quick presentation.

Another way you could promote learning during a hackathon would be to provide a project-based structure to the event. Currently, these events sort of run like the Wild West. Instead of saying “Ready, Set, Go” to kick off the event, organizers should take the participants through stages. In a 24-hour event, the first 4 hours could be for planning while the next 4 hours could be for workshops. Then, the remainder of the time could be spent working and practicing self-care (i.e. sleeping).

Overall, I think any effort to prioritize education over competition would be a breath of fresh air.

Teach Teamwork

One thing that we never really talk about in education is teamwork. For whatever reason, it seems like a given that we’ll eventually have to work in teams, but does anyone really know what they’re doing when they end up in one? As it turns out, teamwork has to be taught, so why not take some time out of the hackathon to teach teamwork?

In the previous section, I discussed dedicating an early portion of the hackathon to planning. Perhaps that portion of the hackathon could also be used to develop some team skills. Personally, I would have loved having some simple tools or strategies I could use to make working with people a bit easier—especially when I barely knew my teammates.

At the very least, it would be nice to have some structure in place to help teams work together to plan their projects as well as determine if their projects have the right scope. After all, few things are more frustrating than shooting for the stars only to face plant in your back yard.

Overall, I think teams could benefit from a little bit of help with planning projects and working together.

Promote Progress

One of the things I’ve noticed while putting together a project is that not a ton of time goes into planning. Sure, this year I was a bit spoiled as my team drew up an entire diagram for our project, but we still fell flat during implementation. It would be nice if there was some sort of process to hold us accountable for our plans. That’s why I propose using some of that planning time to set milestones and deadlines.

In my experience, teams tend to grind away and hope they have something on the other side. This causes all sorts of problems that could be easily resolved by setting some milestones with deadlines. Naturally, these milestones should be shared with a mentor. That way, if milestones aren’t met, mentors can jump in and help.

Having some sort of accountability mechanism built into the hackathon would make the process of trying to put something together a lot less chaotic. For example, I would have loved if a mentor would have checked on us during our tenth straight hour of trying to get our environment setup. Instead, we sort of buried our heads and kept making mistakes. Surely, you could argue it was our fault for not asking for help, but having some structure in place would help a lot of folks like me that are shy.

Overall, I’d say having any sort of accountability built into the hackathon would at least improve retention. After all, a lot of teams tend to leave when things start to feel hopeless. Having someone around to provide support and ensure teams are making progress would certainly improve morale.

Moving Away From Competition

When I set out to write this article, I had already been thinking a lot about the issues we see in terms of retention in computer science education. One of the topics that comes up a lot is competition and its negative effects on learning outcomes. At the very least, competition promotes and culture of gatekeeping and elitism, and I think that’s unsustainable long term.

Don’t get me wrong though! I love competition. After all, I’m a huge gamer, and I enjoy watching sports like hockey. In fact, a lot of my life revolves around competition.

That said, I’ve seen competition sap the joy out of a lot of my favorite activities including practicing trombone and learning to code. Suddenly, “being the best” (extrinsic motivation) takes priority over “getting good” (intrinsic motivation), and this obsession with being number one perpetuates Imposter Syndrome. Hell, I felt bad after this last hackathon because I was competing with my past self; surely, I could have done better.

Ultimately, what I’m trying to say is that we could really turn the modern hackathon into something really great if we just took a step or two away from the competitive atmosphere. If I ever get a chance to host my own hackathon, I’ll do just that!

With that said, that’s all I have for today. One thing I’ll leave you with is an article by Alfie Kohn titled “The Case Against Competition.” I think it’s really quite good at capturing some of my gripes with competition. Also, here’s a great video that summarizes a lot of Kohn’s work:

Okay, I lied. Here are some other great resources I found while writing this piece:

As always, if you liked this article, head over to my list of ways to grow the site. There you’ll find other ways you can interact with me including Patreon, Discord, and my Newsletter.

If you want to stick around, here are some related articles:

Otherwise, thanks for stopping by! Take care.

Jeremy Grifski

Jeremy grew up in a small town where he enjoyed playing soccer and video games, practicing taekwondo, and trading Pokémon cards. Once out of the nest, he pursued a Bachelors in Computer Engineering with a minor in Game Design. After college, he spent about two years writing software for a major engineering company. Then, he earned a master's in Computer Science and Engineering. Today, he pursues a PhD in Engineering Education in order to ultimately land a teaching gig. In his spare time, Jeremy enjoys spending time with his wife, playing Overwatch and Phantasy Star Online 2, practicing trombone, watching Penguins hockey, and traveling the world.

Recent Posts