A hackathon is the worst parts of the job, unpaid

Every writeup of a hackathon opens by saying that we all love them and it isn’t true.

There are two groups it isn’t true for and between them they cover most of the developers you’ll actually meet. The first is the large majority who go to work, write code, go home and then do something else with their evening. For those people writing software is a job and a good one and not a hobby that happens to pay. Offer them a weekend of it and you’ve offered them a weekend of work. That’s not a failure of enthusiasm on their part, it’s an accurate assessment of what’s on the table.

The second group is smaller and I’m in it. It’s the people who enjoy the process of building something properly rather than the specific pleasure of getting a thing on a screen fast. If what you like is the craft, a hackathon is not a compressed version of your job, it’s an inversion of it.

Look at what the format actually asks for. There’s practically no planning because there is no time to plan, very little testing for exactly the same reason and zero documentation because nobody is going to read any of it on Monday morning. No sleep. Bad food. Two days of not seeing anyone who isn’t also in the room. Every single one of those is a thing that makes real projects fail, assembled deliberately into an event and then described as fun.

I’ve worked on real, paid projects that were run in more or less exactly that way, under a deadline somebody else had promised without asking, and the experience is uniformly awful. The code is bad, the people are tired and the thing you ship has to be substantially rebuilt by somebody who wasn’t in the room. Having done it for money and disliked it, the offer to do the same thing at the weekend for a t-shirt is not obviously attractive.

So this isn’t an argument that hackathons shouldn’t exist. They clearly work for a lot of people, the output is often genuinely interesting and I like seeing what comes out of them. If you enjoy them you should go and none of what I’ve said takes anything away from that.

It’s the assumption I’d push back on. The problem with opening on “we all love hackathons” is that it quietly redefines who counts as a developer and it always redefines it in the direction of the person writing. If your evidence is the people who turn up to hackathons then of course they like hackathons and you’ve learned nothing except that self-selection works.

That matters a good deal more than it sounds, because the same assumption turns up in hiring, in what gets treated as evidence of enthusiasm and in who gets quietly read as serious about the work rather than merely competent at it. Someone who writes great code between nine and six and then goes to see their friends is not less committed than someone with a weekend full of side projects. They’ve just noticed that it’s a job.

If you think every developer loves a hackathon, the useful conclusion isn’t about hackathons at all. It’s that you need to know more developers.

There is a version of the format that avoids all of this and some companies do run it. Give people a couple of days inside working hours, let them pick the problem and judge nothing. What is left is time to think about something other than the roadmap, which is the part everybody actually says they valued when you ask them afterwards. The sleeplessness and the pizza were never the point and they were never what produced the good work either.

The reason the compressed weekend version persists anyway is that it makes a better story and a better photograph than a quiet Tuesday where four people read some documentation and tried an idea out.