I want to spend a few minutes sharing my thoughts about hacker culture, hackathon culture, and why there is a divide between the two.

First, a brief introduction to what these things are.

“Hacker culture” is a mentality of using technology in new, often unconventional ways. It comes out of the original computer science groups at universities such as MIT and UC Berkeley. As far as I can tell, in the earliest days, before the internet, most of these groups had separate cultures. The rise of the internet helped encourage collaboration between these groups. Additionally, the rise of Unix and later Linux gave everyone a common language to speak.

Today, Hacker Culture is alive on college campuses across the United States (and presumably the rest of the world). It focuses heavily on sharing, learning, and collaboration. Most often, hackers will work on projects because they are fun or interesting, not because they are useful or practical. At least as it exists at CWRU, it emphasizes quality over quantity, learning over profit, and collaboration over competition.

Hackathon culture is (naturally) the culture that surrounds college hackathons. A “hackathon” is a 24 to 36 hour competition, in which participants essentially lock themselves in a room with caffeine and pizza and build some product, program, or application. Hackathons are rather new, but have quickly grown in popularity and come to have their own culture.

In many ways hackathon culture is similar to stereotypical startup culture, emphasizing concepts such as “move fast and break things” and “fuck it ship it”. This is somewhat to be expected, given the nature of hackathons. In 36 hours, an individual or team can only do so much. This leads to half thought out apps and sort of finished websites. It’s not all bad, of course: useful ideas can come out of hackathons, and if an individual goes in with the right goals in mind he or she can be productive for that time.

The rest of this post talks specifically about HackCWRU, the hackathon put on by Case Western Reserve University’s ACM group, a part of Hacker Society, which generally embraces hacker culture as I described above. This year I helped plan HackCWRU, and I think it went rather well, with over 200 students in attendance. What I am about to say will be rather critical of our hackathon, however. I think these criticisms are valid and important, and we, and other hackathon planners, should consider them in the future.

The problems arise when “hacker culture” hackers attend, or worse plan, a hackathon.

First, we, the organizers, often don’t care much about prizes. The result of a weekend of hacking should be its own reward, so why give material prizes? Additionally, many of the older and alumni members feel disillusioned by the quality of the winning hacks. Like I have said, hacker culture and Hacker Society members often value correctness and technical merit over marketability or flashiness.

The final consideration is when hackers attend a hackathon (including our own). We’re not against the idea, but if we go it probably won’t be to win. And that is perfectly reasonable. A hacker at a hackathon is probably there to spend 36 hours learning something new, or working on an existing project.

To conclude, I’m going to say that I don’t think these differences are irreconcilable. In high school I went to a series of 24 hour hackathons called “Code Day”. It still had many of the competitive qualities of a hackathon, but did not give hugely valuable prizes. Instead, winners got a cool laser cut wood box. This, coupled with the shorter time, smaller attendance, and beginner workshops on various technologies in the first few hours, led to a much more relaxed, community focused event.

Of course, I can’t force any hackathon to change to satisfy my complaints, not even HackCWRU (we still need to attract students and sponsors, and re-imagining the whole event may not be the best way to do that). However, I hope the attendees of hackathons will read this, and stop being so focused on building an app that can win and never be used again, and instead build interesting, well engineered projects.