Hacker News new | comments | show | ask | jobs | submit login
From Hackathon to Production: How to Turn Your Hackathon Idea into Reality (medium.com)
21 points by ebibi 3 months ago | hide | past | web | favorite | 6 comments



I hate hackathons.

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.


Hi there, I'm Tai and I wrote this article.

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.


Well, I won't disagree on the 24 hours in a row thing. However, in a slightly different format, I would really welcome this kind of thing. Say 3 days where you get to build something -- anything -- with or without your teammates.

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...)


Nobody forces you to stay awake the whole time or eat unhealthy. Take your own approach, the core takeaway is trying to build something start to presentation worthy.


Running a marathon is also unhealthy.


Definitely agree about putting tying the value of a new product or system to metrics, if possible. It makes it easier to argue about the worth of the product and can often tie into important metrics that you'd want to track across projects.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: