24 hours is still a bad idea
Many of us who attended the first hackathon said “never again” to 24 hours, but here I am doing a write up on another 24 hour event…so something’s gone wrong!
I think everyone who attended can agree that trying to force quality work and creativity in such a short period of time is, at best, ill-advised. Over 24 hours, there are pockets where, you’re of no use to anyone; a tired stupor where you stare at a piece of paper for five minutes straight, for example.
With that being said, I felt I didn’t suffer half as much as the last time. This is likely down to a combination of breaking my no caffeine rule, the better sleeping arrangements and the fact that the hackathon wasn’t sandwiched either side by a 90 minute drive. I managed to sleep for a good 4-ish hours and when I was awake, I got a decent amount of work done.
I think it should be noted that 24 hours solid does have some merits. No allotted sleep means no hotels and no hotels means the event, as a whole, is much cheaper. Including the event tickets (£20), two taxis, train tickets, snacks, an evening meal and beers, my entire weekend cost under £70. Had we spread the session across more days and forced hotels, I think we’d run the risk of out-pricing potential attendees; by slumming it a bit, it made SummitAwesome a bit more accessible. As much as I’d like to trash 24 hours hackathons, I think this is a point worth remembering for future events.
A little scheduling goes a long way
This hackathon had a real sense of structure to it; which I liked. It wasn’t anything strict, but it laid down enough basic rules so everyone knew where we were expected to be. Time was also set aside at the end for project presentations, and Michael opened and closed the entire event with a few words.
With a group of 25 people, it’s pretty obvious you need some sort of schedule, but having that underlying structure to the event made things run a hell of a lot smoother.
A massive thumbs up for TechHub Manchester, it’s an amazing creative space and was absolutely perfect for this event. As well as the expected work stations and amenities, TechHub has a loftspace annex, which was well suited to our attendee size and needs.
A relatively small but important touch were the Beanbag Bazzaa beanbags; without them I doubt any of us would’ve grabbed much sleep! TechHub also supplied us with unlimited
hackthon fuel Red Bull. Our 25 strong hackathon smashed through 72 cans of it, even though many turned up with their own personal supply. To date no-one’s been diagnosed with Diabetes or gone blind, although Nathan had enough to swap out his entire bloodstream with Red Bull so my bets will be on him.
And finally, TechHub is just a stones throw from Picadilly station, which meant that even with a 21″ iMac, I could comfortably commute in on the train instead of driving. I didn’t really save much money by commuting, but it saved me the headache of leaving my car parked in central Manchester overnight (I’m a bit OCD, it stresses me out).
GifMe is a twitter service where you tweet it a hashtag and it automatically tweets you back with an appropriate animated gif. The archive is crowdsourced, so if you want to help GifMe grow, go to gif-me.it and submit some gifs.
At the moment the library is pretty sparce, so to see it in action I’ll need to tell you a few working keywords…
The idea is that Populite would be a central hub for updating your social network information; saving you from logging into each one individually.
Unfortunately, much like Citee in the last hackathon, Populite fell prey to unsuitable / difficult to work with APIs. It currently stands in an unfinished state, but I hope the team manage something soon, as I think there’s a market for it.
This was a network dreamt up by Michael and Ben H, where developers share code. Unlike other existing networks – like Forrst or StackOverflow – the objective is not to share broken code that needs fixing, but to share code that others can help refine. The end goal is for developers to help make each other better developers.
This is a product management tool that focusses on quality control and crisis management. You tell CureEight about your company’s projects – what platforms, plugins and technology it uses – and a combination of automated and manual flags will tell you something goes wrong and more importantly, which projects are affected.
I dreamt up this project way back in October 2012 and was originally pitched at the first SummitAwesome hackathon. It wasn’t really an appropriate project for the team sizes back then, but it was great to see it come to life this time around.