Why bother? How hackathons can become more female-friendly

Hackathons seem the antithesis of what we want to promote about computer science. On the one hand, they emphasize the Geek stereotype (it’s all about caffeine and who needs showers?), so they don’t help to attract the students who aren’t interested in being labeled “geeky.” On the other hand, it’s completely against the idea of designing and engineering software. “Sure, you can do something important by working for 36 hours straight with no sleep or design! That’s how good software ought to be written!” It’s not good when facing the public (thinking about the Geek image) or when facing industry and academia.

So why tryto make them “female-friendly”?

OK, so there are a number of valid reasons women tend to stay away from hackathons. But what can hackathon planners due to get more females to attend their events? I found some women offering advice on this subject. Here are some suggestions for making your hackathon more female-friendly.

Amy Quispe, who works at Google and ran hackathons while a student at Carnegie Mellon University, writes that having a pre-registration period just for women makes them feel more explicitly welcome at your event. Also, shy away from announcing that its a competition (to reduce the intimidation factor), make sure the atmosphere is clean and not “grungy” and make it easy for people to ask questions. “A better hackathon for women was a better hackathon for everyone,” she writes.

I agree w/ Max (and Mark, later down) on this. However, I don’t think Hackathons are the only or even main culprit. This problem is manifest all over the programming space. Also, it may be easier to address here: surely nobody is surprised that the output of their one day is not a “product”, they just need to be reminded of it. (On the other hand, note that most hackathons let you bring in whatever you’ve been working on earlier, so it’s also not fair to assume that their Rome really _was_ built in a day.)

Great question as always, Mark. I would dismiss the idea of hackathons for women, but I recall the “24 hour theater project” my kids’ (large public) high school ran. It was great fun for the kids and the school, and the participants were at least half female. I actually don’t know much about how hackathons are run, but the idea of trying to create a “real” product under those circumstances sounds really bad. What about gathering information on the user? Testing the user experience? But if hackathons could be used to produce some kind of public performance at the end (live coding music, interactive data visualization, ?) that might be pretty cool, and very much in the spirit of 24 hour theater.

Your points are similar to Shriram’s, and I agree. Hackathons that produce a piece of art (live coding, animation) mesh with longstanding traditions in art. I don’t have a problem with that at all. I strongly agree with Max. The idea of producing a piece of software that someone will USE, with no user involvement, no testing, and no support or maintenance afterward isn’t what we should be encouraging.

One of the things I used to enjoy seeing is the output of the 48-hour film festival. To ensure freshness, you are given prompts that you need to incorporate in your film. E.g.:

Many of the films are bad. Some of them are truly awful. A small number are quite clever. And a very tiny fraction are sublime: something about the pressure-cooker really brings out a spark of genius (or at least of luck). But I go not just to see the sublime but to see the entire range of output, I think because it confirms that power-laws are alive and well in nature.

Naturally, those screenings remind me absolutely of hackathons. And I imagine the output quality is exactly the same. And I imagine auteurs rail against 48-hour film contests the same way we do against hackathons.

But I don’t confuse this output with a “proper” movie. And I don’t imagine anyone else is similarly confused, either. The difference is, the output of a film sprint is not a supposedly useful object that one might download and run. So I see the main problem as the labeling, and the danger that @Max refers to.

And you could pretty much copy-and-paste it for hackathons. It’s not a great article (or all that surprising) — and notice the emphasis on PRish things rather than true learning — but it has some useful elements. Moving it to our context, it tells students to shift from “doing assignments” to “producing products”. Our courses rarely do that, and I really do want students to understand the transition.

2. Hackathons seem at least no worse than the ridiculousness that is the ACM programming contest. (Yes, I know, now I’ve moved the bar to some sort of theoretical minimum.)

3. There is something to be said for periods of intense concentration. I find I am most productive on flights, and often need to create a “retreat” for myself to get certain kinds of work done. And I’m not even someone whose computer or phone beeps on every social media notification. Similarly, our students — besides any social media distractions — have tons of competing and clashing demands through courses and campus life. Having someone help them put that all aside to hone their craft for 24 hours…not too bad an idea.

Sigh. Conflating hackathon-ing with actual software product development just contributes to the problems I see – companies do not value solid processes when developing software, and computer science majors graduate without understanding how to build solid software.