What has been your experience attending to hackathons?
If you've been on a hackathon, I want to know how it's like, what to expect and so. There is a 48 hours hackathon next week in my city, I'm planning to attend, but I've never been in one and have no idea how it is like.
Hackathons are brilliant! I've been to about 4 or 5.
The format is generally:
Turn up
Get tech/product intro (if sponsored)
Hear pitches
Meet people
Form teams
Lunch break
Start programming
Break for dinner
Continue programming
Go to bed really f-ing late (some don't bother!)
Get up, continue coding
Finish coding some time in the afternoon
Everyone presents
Judging
Winners announced
There are various things to get out of the process:
Testing your skills, esp. under pressure
Working with others, breaking down tasks
Creating something that will live only for the weekend
Creating a project that will live on and will need further collaboration
Making contacts / potential future partners
Most hackathons usually start (after the intro) with pitches if they are the team-type events. People will go up to the front and say "My idea is / I'm interested in, and I need a team / I'm looking for". Make notes, there will be a lot to remember!
Afterwards, you have the meet and greet. This is especially important as it will decide the entire weekend and potentially the (as it has with me from one hackathon) a substantial part of your next few years, as we now have a product.
Aim to meet all the people on your list. Don't feel you have to commit to anything, this is networking / dating. Then again, some ideas will be very popular and teams may suddenly get filled up, so if you want it commit (you can always uncommit).
I've ended up by myself, in teams of two, teams of 4 and teams of 7. It's not so much the size, it's the fit. Personalities, mixes of skills, range of skills, do you have enough people to front end, back end, design, admin (yes! there can be research and marketing for some of them!) even project management. It's a mini-project.
I've been in a team of 4 where I ended up quitting after the first day as the actual idea, though interesting, didn't have legs, and mix of skills and personalities was terrible - it was clear we were going nowhere. I ended up talking to another team who needed my skills, so I quit the first and joined the second and we had so much fun and won 3rd prize:
Loads of info about the work and team here, but briefly, the new team had seven members and the range of skills was perfect. Team lead / PM, marketing, back end, front end x 2, and design.
Teams are also crucial to project scope. If you pick a small team (1 - 2) you will only be able to achieve as much as 2 people can in effectively in 1 x 12 hour sprint (including planning) and 1 x 6 hour sprint (it's never 48 hours!).
Therefore, pick something really small, or you simply won't get it finished and it's so incredibly disheartening to see everyone else presenting when all you have is a bunch of notes and files that don't look like anything yet. That's happened to me a couple of times, and was a great teacher! You also don't want to present "this is what we wanted to do" as no-one really cares when the next team is going to show a NodeJS powered drone with AI that the crowd can interact with from their mobiles.
This is where being on a larger team helps. Everything gets done. But again, think REALLY HARD about what you can achieve in the time. In your head you have an app, but in reality you will complete a screen or two.
Talking of completion, and I mentioned this earlier, some hackathons form the basis for larger projects. It should be clear at the start whether the project is weekend thing, or a longer project, perhaps a product or business. Both are fantastic, but you will have completely different experiences based on how you take the work on, and how much you'll build in your few hours together.
My advice would be, even if the idea looks like a long term one, build SOMETHING! Don't waste your time planning, just get building.
The other thing to remember is that setup – on any project – TAKES A LOT OF TIME!
Under no circumstances go in thinking "Oh, I'll probably use technology X, or maybe Library Y"... go in with a starter project READY TO GO, all the libs already in place, basic routing set up (or whatever you build) and build off that. If you have a previous site that looks great and you think you could strip back and re-use, do that, but AHEAD OF TIME. You simply will not have time to start from scratch, making architectural decisions / mistakes, you will be too busy desperately trying to code and hack something together whilst wired on coffee / free food.
Hackathons are also not the time to be learning new tools, they are the time to be relying on the ones you know inside out (though that's not to say you can't!) so make sure you get enough practice time in before you go.
Essentially, you do not want to be in the position on Saturday night at 2am, absolutely knackered, thinking "I have to build a whole project tomorrow". By this point, you should be looking at everything you've built and planning down the last 6 hours you'll have in the morning before judging and presentations which will probably be in the afternoon (lucky you if you get longer!).
Now, of course I'm talking about this with the idea that you want to go there and smash it, but there's also just the experience of being there and meeting lots of other passionate, self-starting types, and you should defo make time for that!
Meet people, say hello, chat to other teams (though don't spy :P) and get inspired. That is really the whole point of the weekend.
So that's it for now. Top take aways:
go with a starter project
take notes in the presentations
meet as many people as possible
commit to the right team (idea, goal, size and mix)
keep research / planning to the bare minimum
plan your work to the available time; likely 12 hours + 6 hours
make sure you can present something!
enjoy yourself and get inspired!
Let us know how you go and what you build!
Cheers,
Dave
Good luck! Maybe take on a 4th person? It could increase your productivity by 33%...
Dave Stewart
Web developer from London
Hackathons are brilliant! I've been to about 4 or 5.
The format is generally:
There are various things to get out of the process:
Most hackathons usually start (after the intro) with pitches if they are the team-type events. People will go up to the front and say "My idea is / I'm interested in, and I need a team / I'm looking for". Make notes, there will be a lot to remember!
Afterwards, you have the meet and greet. This is especially important as it will decide the entire weekend and potentially the (as it has with me from one hackathon) a substantial part of your next few years, as we now have a product.
Aim to meet all the people on your list. Don't feel you have to commit to anything, this is networking / dating. Then again, some ideas will be very popular and teams may suddenly get filled up, so if you want it commit (you can always uncommit).
I've ended up by myself, in teams of two, teams of 4 and teams of 7. It's not so much the size, it's the fit. Personalities, mixes of skills, range of skills, do you have enough people to front end, back end, design, admin (yes! there can be research and marketing for some of them!) even project management. It's a mini-project.
I've been in a team of 4 where I ended up quitting after the first day as the actual idea, though interesting, didn't have legs, and mix of skills and personalities was terrible - it was clear we were going nowhere. I ended up talking to another team who needed my skills, so I quit the first and joined the second and we had so much fun and won 3rd prize:
Loads of info about the work and team here, but briefly, the new team had seven members and the range of skills was perfect. Team lead / PM, marketing, back end, front end x 2, and design.
Teams are also crucial to project scope. If you pick a small team (1 - 2) you will only be able to achieve as much as 2 people can in effectively in 1 x 12 hour sprint (including planning) and 1 x 6 hour sprint (it's never 48 hours!).
Therefore, pick something really small, or you simply won't get it finished and it's so incredibly disheartening to see everyone else presenting when all you have is a bunch of notes and files that don't look like anything yet. That's happened to me a couple of times, and was a great teacher! You also don't want to present "this is what we wanted to do" as no-one really cares when the next team is going to show a NodeJS powered drone with AI that the crowd can interact with from their mobiles.
This is where being on a larger team helps. Everything gets done. But again, think REALLY HARD about what you can achieve in the time. In your head you have an app, but in reality you will complete a screen or two.
Talking of completion, and I mentioned this earlier, some hackathons form the basis for larger projects. It should be clear at the start whether the project is weekend thing, or a longer project, perhaps a product or business. Both are fantastic, but you will have completely different experiences based on how you take the work on, and how much you'll build in your few hours together.
My advice would be, even if the idea looks like a long term one, build SOMETHING! Don't waste your time planning, just get building.
The other thing to remember is that setup – on any project – TAKES A LOT OF TIME!
Under no circumstances go in thinking "Oh, I'll probably use technology X, or maybe Library Y"... go in with a starter project READY TO GO, all the libs already in place, basic routing set up (or whatever you build) and build off that. If you have a previous site that looks great and you think you could strip back and re-use, do that, but AHEAD OF TIME. You simply will not have time to start from scratch, making architectural decisions / mistakes, you will be too busy desperately trying to code and hack something together whilst wired on coffee / free food.
Hackathons are also not the time to be learning new tools, they are the time to be relying on the ones you know inside out (though that's not to say you can't!) so make sure you get enough practice time in before you go.
Essentially, you do not want to be in the position on Saturday night at 2am, absolutely knackered, thinking "I have to build a whole project tomorrow". By this point, you should be looking at everything you've built and planning down the last 6 hours you'll have in the morning before judging and presentations which will probably be in the afternoon (lucky you if you get longer!).
Now, of course I'm talking about this with the idea that you want to go there and smash it, but there's also just the experience of being there and meeting lots of other passionate, self-starting types, and you should defo make time for that!
Meet people, say hello, chat to other teams (though don't spy :P) and get inspired. That is really the whole point of the weekend.
So that's it for now. Top take aways:
Let us know how you go and what you build!
Cheers,
Dave