It was too late: I’d taken off my headphones to look for water to drink, but got cornered by a business person: “Hi there, I’m Bob, and I’m looking for a developer to work with on this idea I have.”
This happened at a well-known Singaporean hackathon late last year. My friends and I were camped on the second floor of The Hub – prime spots for programming – and we were all working on personal projects. I’d attended enough hackathons in Singapore to know I would need to bring obnoxiously large headphones when I program. The idea is that I would leave the headphones on and people would leave you alone, free to hack in peace.
And indeed I was left alone for the most part, until I got up to get water. Any time your headphones are off (especially if you’re not staring at the code editor) is interruption-prone. But this doesn’t have to be the case. Hackathons are opportunities to celebrate technical innovation under competitive constraints.
Yet increasingly in Singapore they’ve become badly designed avenues where the secondary goals of the hackathon’s organizers overwhelm the very purpose on which hackathons are created for.
The example I gave above illustrates one such problem: in many hacking events in Singapore, developers who want to, you know, hack would first have to beat off the number of non-technical people who arrive and proceed to recruit various developers.
The last thing you’d want to happen, when you’re trying to focus on coding, is someone tapping on your shoulder and pitching an app idea you have absolutely no interest in.
There was also that hackathon which awarded the intellectual property of all projects completed during the event to the sponsor, outraging many developers in Singapore.
This has become enough of a problem that developers I know would check with each other on the reputation of a hackathon before deciding to attend. Their fears are not unfounded: for example, a friend of mine came back from UP Singapore complaining to anyone who would listen about his experience.
Now, UP Singapore proposes to have technical and non-technical people come together to solve socially important problems using applied data (whether these problems can really be solved in a 24 hour period is another story entirely).
But the problem wasn’t with the premise, my friend said. In fact, he argued UP Singapore deserves some recognition for focusing exclusively on socially relevant problems.
The real issue was that he couldn’t get much done at the hackathon: whenever he tried to code, some business person or idea guy would interrupt and ask him what he was working on. Indeed, most winning projects at UP Singapore haven’t been particularly impressive from a technical perspective1; seriously good developers I know tend to stay away from it.
How to do it right
In some of the best hackathons I’ve attended, event organizers enforced policies making sure secondary event objectives did not overwhelm the quality of the hacking. While product placement, marketing, recruiting and company advertising were important parts of hackathons, they were never allowed to get in the way of the projects.
This meant they could attract a pool of quality developers, and have competition entrants impressive enough to justify API or data sponsorship from various companies.
Some of these policies are small, but thoughtful. Sponsors are only allowed to talk before and after the hackathon, not during programming hours. More importantly, sponsor time at the end of the event is intentionally limited, as most participants would be dead tired and rather irate by then. Visitors are discouraged from socializing with participants except during meal times. Intellectual property is always owned by participants.
It’s fine to have events that aren’t purely hackathons. Startup Weekend, for instance, attracts a diverse crowd of developers and entrepreneurs. And it works for them because people know going in that it isn’t a hackathon.
My point, however, is that when you advertise your event as a hackathon, you have the responsibility to make sure actual hacking gets done. Not doing so will reduce the quality of the developers attracted and projects created, undercutting not just the primary goal (again, to build innovative things) but also the secondary purpose of the event as a place to recruit, advertise, or push digital products with.
At Hack&Roll, a hackathon I’ve organized, we’ve implemented a rule that says visitors are not to disturb hackathon participants unless participants are available. We’re so annoyed by this problem at other hackathons that we color code attendees, visitors, and organizers, and tell participants to alert us when they’ve been distracted by the visitors.
For hackathons to be considered successful, they’re usually judged based on the quality of the projects that emerge from the event. To produce good projects, attract good programmers, and help grow Singapore’s developer community, let hackers do what they intend to do: build cool things, for fun and glory.
Hack&Roll 2014 will be held from 1pm January 25 to 6pm January 26 this year, at the COM1 building in National University of Singapore. If you’re a student, sign up at hacknroll.nushackers.org. If you’re a developer or visitor and you’d like to hang out and work on your own projects, head down during the competition and remember: leave the hackers alone when they’re programming!
(Editing by Terence Lee, photo credit: NUS Hackers)