The Dark Side of Hackathons

HBO’s Silicon Valley accurately depicts working next to other coders (and is the show that the Big Bang Theory should have been).

I used to be super big on hackathons (I still kind of am). I’ve competed in them, won them and even organized them, urging new developers to compete. After all, the best of the development community is embodied through hackathons. This is still true; however, hackathons serve a very specific purpose and to attend for other reasons can actually be a bad thing.


The major problems with hackathons stem from the fact that they are often isolated incidents. Not to say the apps written and the projects worked on can’t be relevant outside the competition, just that they just usually aren’t.

For every one hackathon project that gets becomes a company or gets acquired by Google,
there are thousands that never make it past a localhost.

The mentality that your projects are disposable in this way can affect your long-term performance. Hackathon code is quick and dirty; it isn’t meant to circumvent technical debt because it probably won’t ever be maintained. However, outside the competitive you typically strive to write clean and efficient code. As a result, this discord between coding styles can make quick and dirty code become a habit if you begin to neglect the longevity of your work.

Uneven Competition

Ever felt like you’ve been snubbed for an award at a hackathon? You aren’t alone. Hackathon prizes dictate projects and since a weekend isn’t enough time to develop a vast amount of projects, winners are often decided by a pitch rather than a project.

Some hackathon teams even have a dedicated business development member for this exact reason.

The teams that are judged for their technical merit still aren’t always judged fairly. Hackathons operate under the “honor code”, which can allow unethical teams to get a head-start on their projects. When the stakes are high enough, a million-dollar prize for example, corruption is likely to occur. Sponsors have little incentive to be more strict with judging since they will have already benefitted: raised awareness for their companies and more projects using their APIs.

Why Compete?

Everything wrong with hackathons that I mentioned doesn’t necessarily apply to a certain group of people: new developers.

For people new to the coding world, hackathons are an invaluable foray into the development community. Especially for cities that aren’t technologically prominent (mine for example), they can often be new developers’ first interaction with other coders. Hackathons even host booths for job opportunities and give new developers the opportunity to network with industry experts.

Hackathons also serve a strong purpose: to learn new skills. Many venues will have separate “classrooms” for learning a specific framework or API. Although this can compound the time constraint problem, it’s a really productive use of your time at the competition, forcing you to apply your knowledge to a breathing project. I personally learned how to use Meteor at a hackathon, and I use it today across all my web projects.


Instead of using hackathon projects as portfolio pieces, developers are better off working on projects at their own pace that they flesh out themselves, and getting involved with open source to collaborate with others.

To learn new skills in a fun and social environment, there’s nothing better than a hackathon. However, the notion that hackathons are flagship events that every developer MUST attend in order to become a coding guru is false.


    Table of Contents