Hackathons represent everything that's wrong with development. People put no time in to really think about an idea (just go with what sounds 'best' in the 15 minutes at the start), no time to plan (code the first approach that sounds like it'll work), an unhealthy environment without sleep, exercise or decent food (pizza and beer are ace, but they're not healthy), and as the article says, usually no buy in from managers or team mates afterwards. Plus they tend to be exclusionary because anyone with a family or responsibilities, or who needs a good night's sleep, is effectively excluded from a team because they're going to miss a big part of that 24 hours.
It's quite incredible that a health startup like Oscar Health would actually encourage hackathons.
However, Oscar's hackathon is the second healthiest hackathon I've ever attended.
- It's closed to employees only.
- It's opt-in only.
- We get 2 workdays dedicated to the projects and there's no expectation to stay after work.
- There's catered healthy food as usual (via soripe.com)
- The deadline is soft and you can do work ahead of time. If you don't finish your project this hackathon, you can pick it up in the next one.
- You're encouraged to work on passion projects that are not directly related to your team
- There are prizes for not just Judges #1,2,3, but also People's Choice, Best Design, Best Product, and Best Engineered.
Any competition can be good, bad, or rotten.
I agree with you! It is quite incredible that a health startup like Oscar Health would actually encourage hackathons. And it's more incredible that Oscar seems to be doing it right.
Quite a lot of people have never actually built anything from scratch in their life. And while 3 work days is not much time, that's really the point. You have to make decisions quickly, which allows you to see your mistakes -- quickly. Quite frequently when you're on a team (especially in a large corporation), you never hear anybody say, "Hey, let's try it and see what happens".
Again, I'm all with you on controlled development and I have a reputation for being extremely stringent on trying to reduce risk. But that's exactly why you need to let your hair down sometimes and experience what happens when you don't do that. Developers who follow "rules" without knowing why they exist become poor developers.
And... occasionally, that 24 hours of work you do turns out to be interesting for more than 24 hours. You fix up the initial problems, or even start it again from scratch. It's not like you've invested that much. But for me, it's usually fine to retire my projects after I've learned what I wanted to learn.
And, yes, I write code in my own time for exactly this reason. But, I'd be ecstatic if my employer was happy to pay for my learning (actually, the current one does give me some time for that kind of thing... though I tend to continue to just pay for it myself... weird...)