Ugh, not to get on a grumpy-old-man tangent, but I recall when 'hacking' and 'hackathon' had fairly specific and nerdy meanings, and not 'let's try to knock something up we could do in Figma or another wireframe tool to sell to investors'
Back end developers on hackathons are not needed
31–40 of 100 posts
Re: Back end developers on hackathons are not needed
#32Let's cut out the middleman entirely and say that Hackathons, as such, aren't needed ;)
Re: Back end developers on hackathons are not needed
#33I guess it depends on the type of hackathon and project. Not to long ago I participated in a hackathon in which we make a super simple video game. Even though the majority of the work was making the game, the 2 hours used in making the scrappiest ever node.js/express server for arcade-style high scores was the most popular feature by far.
So, in that case, being a scrappy backend proved to be very valuable.
Like 3 hours some people realized that they could just POST whatever to the server and the high scores where pointless, but nonetheless, that small backend (20 lines?) proved a very important point
Re: Back end developers on hackathons are not needed
#34This assumes the "business-y" type hackathons that are popular these days. Back when I was young, we used to organize hackathons where the point was to hack together something cool, and "winning" was not the point. If you are just making a "clickable prototype UI" that's not cool in my books.
Yep, "hackathon" got co-opted into "free labor" the moment business types sniffed it out. Hackers caught on, left, and now "hackathon" means "business types hyping each other over demo sketches" -- which is fine, but not my cup of tea, and about as far as it is possible to be from the original spirit of hacking.
I had this exact experience. We had a successful hackathon led by the engineering team where we just built cool things that somewhat aligned with the business.
The "Innovation" team decided we were pushing into their turf and took it over. Then it was decided that requiring actual development wasn't inclusive enough. The next "hackathon" was just a parade of PowerPoint presentations.
Re: Back end developers on hackathons are not needed
#35The next logical extension of this is: "Front End Developers on Hackathons Are Not needed."
After that, it's "UI/UX Prototype Designers on Hackathons Are Not Needed."
If you want to turn your Hackathon into a Pitchathon, then okay, yes, you don't need any developers or designers of any type, you just need someone with an idea who can communicate that idea. But, that's not really the same thing, is it?
Re: Back end developers on hackathons are not needed
#36> The main goal of the startup hackathons (or any other) is to validate the idea in a limited time that the product you build is needed by the people in the room. No, that's a Startup Weekend-type event: https://www.techstars.com/communities/startup-weekend . They rightfully don't call themselves hackathons. A hackathon should be related to software development, not entrepreneurship. Nothing wrong with either, but la…
The term hackathon nowadays is almost never related to software development. You can win most "hackathons" with a powerpoint slide, doing actual programming won't win you a price.
Re: Back end developers on hackathons are not needed
#37We've restarted doing 2-day hackathons at my work, and in the spirit of being as inclusive as possible for all team members, we don't require teams to submit code at the end.
Some still do though, but in the end we want teams to play to their individual strengths and deliver anything they want that fits the theme.
We do pick themes that are relevant to the business, but there are no other requirements, and we do it over 2 days during working hours (and even provide Doordash and Starbucks cards to the teams for meals and coffee), so there's no "free labour" shenanigans or weekend work.
So far it has been a great success, and I believe we've had much higher participation than if we had stuck to the more traditional definition of a hackathon.
Re: Back end developers on hackathons are not needed
#38*For one very narrow definition of Hackathon Seems like the author needs to attend Hackathons where the sole purpose isn't to sell a SaaS prototype to investors and clients. I have been to enough of them where no one cares how fancy the CSS styling on the page looks. Or even that there's a GUI at all. One time the winner wrote a CLI script. I routinely demo API calls using Postman.
Yeah, I've co-organized and attended multiple hackathons, and one of our organization principles is "code is key", to combat powerpoint-only submissions.
That means that there is a code-screening after the submission deadline that ensures that what was demoed was also implemented, and also gives some points in the overall scoring based on execution. We have seen submissions that include a fully-fleged backend including tests, as well as completely faked demos (which were easy to pick up, as what they promised was too far removed from reality).
Re: Back end developers on hackathons are not needed
#39Most people who go to hackathons have tons of boilerplate already put together, at least in my experience. The coolest thing I ever saw built at a hackathon in boston was a fellow NU student who built a filesystem that completely operated within network traffic flowing between a number of network switches. Totally novel, not fake tech backing a half-baked "business" idea with the IBM watson API.
I stopped going to hackathons after one kid at Hack the North U Waterloo literally tore a muscle in his eye from looking at a screen too long...
Re: Back end developers on hackathons are not needed
#40We've restarted doing 2-day hackathons at my work, and in the spirit of being as inclusive as possible for all team members, we don't require teams to submit code at the end. Some still do though, but in the end we want teams to play to their individual strengths and deliver anything they want that fits the theme. We do pick themes that are relevant to the business, but there are no other requirements, and we do it o…
The working hours thing alone is awesome -- it sends a signal that "this is a good and valuable thing that you're doing, even if no software for our business comes out of it"