Ask HN: Are hackathons anything more than a lame distraction?

My company had done a few. I’ve never participated, because the vibe I got from my management was that we shouldn’t have enough time to work on something like that.

Some of the winning projects seemed way more involved than what would be done within the hackathon. It seemed like these were things that had been in the works for a while, and they used the hackathon as a means of internal marketing, to get the idea out there and give the team recognition. It felt like a dog and pony show in some respects. Though I could be wrong. Some data to support this is a video contest we also had, and my team was one of the winners. No one on the team had any idea about it, going 3 levels up to the VP level. They had the marketing team (or something) throw a bunch of fake videos together with made up information, and presented it as if teams were participating. This is one reason why I question the validity of the hackathon.

One thing that kind of upset it, or made me jealous, was that those working on the hackathon had a portal with a 1 click setup for the internal CICD system, so they could jump in and start coding right away. When working normally, trying to get into the corporate CICD seems to take months, with countless meetings, hoops, and tests of strength, followed by significant manual setup and a steep learning curve. I’ve seen more people fail than succeed, and some leave the company defeated over it. Why time would be invested to make it seamless for the hackathon, while everyone else is left to struggle, I will never know.

I don't really see any real personal benefit to participating in company internal ones, especially when you're not given any reprieve of your normal tasks (i.e. your main job will be accumulating a backlog of work while you're busy doing the hackathon that you'll have to work extra to catch up on).

Both my current job, and the client I'm working for on behalf of my current job (I'm in consulting) have hosted a couple of hackathons each, and I didn't participate in them. I remember one of them was over a weekend, so I would have had to give up my weekend in order to participate, and essentially work 12 straight days for my company (two weeks of weekdays with the weekend in between) without a break.

If I'm going to do extra work above and beyond my main job, I'm going to work on my own projects and release them myself. And the main things I want to work on are game-related anyway, which my current job doesn't care about at all.

I like public hackathons, I like the energy, I like meeting people, I like seeing how other people do things.

I worked at one place that had an internal "hackathon" where the CEO wanted us to deliver something small in two hours. My immediate take was: "it takes 20 minutes to build our system (I knew because I just did it) so we have at most 6 trial-and-error cycles, a realistic plan takes that into account". The engineering manager said "no way it takes that long", I said, "let's go ahead and I'll time it with my stopwatch", and it took 18 minutes.

In that sense it was representative of how well we were planning in general. I felt I learned something from it, I'm not sure that management did.

The trouble with hackathons is they don’t solve the other blockers to innovation, such as resource constraints, internal politics, and poor incentives. I’ve done dozens of hackathons and hundreds of innovation challenges. Earned my university tuition in prize money from them kind of thing. Even the supposedly guaranteed interviews didn’t materialize though. The outcomes were purely cash and resume material.

As far as I know, none went anywhere. Not a single idea went beyond my presentation.

People see them as a magical way to unlock new ideas, but the problem was not really a lack of ideas in the first place. Rather, the new ideas people already had got stuck and all the hackathon was doing was adding more stuck stuff.

> that we haven't had the time to work on due to other commitments

This problem doesn’t go away by hosting a hackathon. At the end of the hackathon, resources would need to be allocated.

Don’t get me wrong, I love hackathons. I spend a lot of money every year flying to attend hackathons. But they don’t produce much for the sponsors it seems.

The feeling of working with a deadline without the slowdown of project management can be exciting. What I have noticed at the company level is the output is wasted and the praise or prizes become political. Management thinks its a vacation for you and goes hard next week to catchup meanwhile you are burnt out.

It doesn't work because it's a fake scenario. When you work for a startup sometimes you end up in a real hackathon where you have to finish the product right before the biggest presentation in the companies life. Those are exciting times with a real outcome. That's the feeling a hackathon is trying to manufacture.

I don't know about corporate hackathons, but I think college hackathons are more than a distraction. I've learned useful technical skills from hackathons (including React).

Most importantly, I've been able to reference my experiences in hackathons in behavioral interviews. They're great places to talk about things like working in a team and conflict resolution. Maybe in a corporate environment this could also help employees learn each other's working styles and what works best.

With that said, I don't think I've seen anything massively impressive and important technically. The timeframe is just too short.

Hackhatons are fun. Internal "hackhatons" are not hackhatons, they are work. Work is not fun.

I participated in (and hosted) some hackathons in college, and I think those were useful in that they gave you an opportunity to drive your own project - a lot of people otherwise had only done coursework, served to introduce students to companies/potential employers, as most sponsors had some kind of presence, and were fun.

It hasn't come up, but I might still do an internal or public hackathon now, just for something to do. If I had a family and lots of responsibility/time pressure, maybe not.

I do think the short time window is a real limitation though. The only way to make significant progress in 24-48 hours is to already be really familiar with your tools. If half your team knows a stack and the other half doesn't, you don't really have time to teach them and build your project. It's also very difficult to find an idea which can be built in the available time while also being actually interesting.

I'll participate in a hackathon for fun but I won't ever compete for one for a 'carrot' or a 'stick' again.

Way too easy to create unnecessary bad blood if it is an internal hackathon. People should participate because they want to, if they choose not to, that's a culture mismatch between leadership's actual actions and leadership's desired results.

I think even prizes are a bad idea unless the prize is something silly like a little trophy or something without value. Again, it's about cultural alignment.

A good internal hackathon should be stress-free, fun, catered food, have spaces to blow off... it should less be like "work all night wooo" and more a relaxed tech-oriented get-together.

We've done them regularly at FusionAuth, every 3-4 months. I like it for a number of reasons:

* fun to see what other people experiment with

* lets folks investigate latest tech without having to justify incorporating it into core work

* offers freedom to explore something with low risk

We've definitely built things that made it to production, though often it was more the concept than the code. It's also been great for exploratory work that let us understand the domain or possible solutions more.

Examples of stuff from our last hackathon:

* building a rust SDK

* re-imagining in-app search

* hacking on a low-level different approach to building our client libraries

* multiple approaches to simplifying the upgrade process

* setting up a FusionAuth themed appsec CTF

I love them myself, but we do timebox them to 1 day of effort. When I used to run them, I also said that having nothing to show but learning about what didn't work was a perfectly valid use of a hackfest day.

I love them, even the internal ones. If you don't enjoy them or find them to simply be 'work', they're probably not meant for you. To me, they're a party. The fatigue and focus bring out the kind of vibes you'd get from late nights and alcohol. The focus on a topic means you have an icebreaker. There's low stress socialising like lunch, and there's high stress socialising like go karts and hackathons.

The goal of hackathons is to fail, but fail hard enough to have a spectacular demo. You're not building anything to last. You're experimenting with a new stack. You're building a feature that wasn't there. Whatever you end up with, you have to throw it away, so you're not attached to the code and go deeper than you otherwise would. This failure gives you data that you otherwise would not have.

I haven’t seen any incredible outcomes from them, but I think they can be nice if they’re low key with no real expectation of productization. Definitely shouldn’t be any “prizes”.

The best uses of hackathons I’ve seen are for experimenting with things that will have a direct workflow improvement for your team/org. You’re not gonna impact the company product roadmap with a hackathon project. If you do, it’ll feel lame because it’ll be a product manager lifting your concept and throwing away the implementation.

I’ve spent hackathons getting team members together and working on things like a bootloader rewrite, toolchain improvements, adding that one API to our SDK that I really wanted personally, etc. Stuff that’s hard to find time to work on day-to-day, but can be marketed internally and if it works out, merged to immediately improve things for your team.

More often than not, yes. I’ve worked companies of varying sizes for 15 years and all have done atleast one hackathon a year. Over that time I’ve seen exactly 3, maybe 4 hacks that could have been an amazing product.

In two cases legal said hell no after the prototype. One was mine and the state of hardware and the ux wasn’t good enough to release.

Legal said no to: Listen to songs for free by taking meta data of freely available radio station recordings (like what’s available for 7 days after broadcast) and just playing the x many minutes of the show that the songs on.

Taking sports f25 sports data and generating a live top down 2d view of the event. Legal said no.

Playing html5 games on a tv using your phone as a controller via a chromecast. You could probably do this now with a QR code and web sockets or something.

It’s a way to “keep to code monkeys happy” that doesn’t involve paying them more or actually making them happy.

The company I work for does 3 a year, over 3 work days. Being given 24 paid hours to work on ANYTHING is pretty cool. I usually look into interesting technologies not strictly work related.

I’ve spent some hackathons doing open source Rust project contributions. Some people just do things like build bookshelves.

It’s meant as a benefit to the employees.

I don’t mind too much doing them as long as they are within working hours and the expectations are not high.

Anything else, no thanks.

I feel the same as you - they're mostly a distraction to boost morale. They're also extremely political.

There's sort of a silver lining. Sometimes the ideas that don't get fully built or selected as a winner do end up evolving into features in the future.

I have seen cool ones, where hackers shared cool personal projects, people contributed to them, had shared learnings and fun together. others were really lame 'make an AI app' type of boring corpo stuff. it really depends on the organizers and participants.

Independent hackathons that are open to the public can be fun (though frustrating at times as well). Internal corporate "hackathons" are horseshit. They're just a way for executives to feel like they're part of the big boys.