In a recent post regards Hackathons we talked a little about what we think Hackathons should be about. So in this post, we’re going to go into a little more detail, to make things a bit clearer. Applies primarily to: #JoziHack | #CptHack.
Enter the dragon
First, we make the assumption that most people who code for a living these days are in the typical corporate 60 / 30 / 10 trap. That is, 60% of their work is uninteresting / lacks stimulation, 30% is kinda interesting, and then perhaps 10% is the icing on the cake, the really co0l w00t, w00t, super interesting, I wanna do more kinda stuff. It’s not abnormal, so we’re not trying to change that – but we can offer a nice distraction 😉
Secondly, we make the assumption that most devs work in teams that are less than 10 people (and if they’re lucky the team is 50% real developers / engineers), and so their proximity to other people like them is pretty low. As a result, feedback loops are limited to what is read online and in forums (which is cool, we all do that), but that also means limited potential for peer reviews, some closed mindedness and narrow perspectives, fewer super technical discussions which make things interesting, and of course simply people who understand that Dependency Injection and Factory Pattern can be complimentary to each other.
Third, we make the assumption that most non-technical people who sign off on projects don’t know enough about technology to make good decisions (they’re driven and motivated by different things), and so the potential for trying new things is also pretty low.
In fact, most teams are probably still deploying code from 3 years ago, or they’re caught maintaining code that was written 3 years ago because there is no budget to update. Very, very seldom is there an opportunity to try new things, change old things to work better, or just improve skills. And so the typical developer ends up continually doing change requests, small features, maintaining old code to keep the site from breaking when new things are tried, and of course good old releasing 4 week projects by next week Friday.
So, when you put all of that together you get frustrated devs who would like to be challenged more, who would like to meet more people like them, and who want to try new things.
Enter the Hackathon
So our solution to this is to give developers, engineers, hackers, coders, savants, curious folks, learners, students, designers and even sysadmins 😉 a place to get together and do the following:
- Have fun hacking on cool new stuff 
- Drink beer, eat pizza, drink red bull, play poker, eat pizza, go for breakfast, write mad SQL, deploy
- Meet new people, hang out with people they already know and do stuff they enjoy doing
- Take a look at an interesting problem, figure out ways to solve it
- Learn about cool stuff that isn’t on the radar at work
 Hack is not a four letter word
And that’s it. We figure (from experience) that the most important element to this is beer, and for everyone to have fun. After that, all the magic happens!
So what’s the deal?
There are 3 parts to our Hackathons, and they are
a) having fun
b) learning new stuff
c) meeting new people
d) kicking ass.
That’s 4. Glad you can count. Keep up 😉
Free as in beer
For a) We make sure there are people, music, beer, pizza, Red Bull, loads of coffee, snacks, all on tap.
We also think the following principles are important:
Hackathons are free.
Everyone is welcome.
Anyone is welcome.
You don’t need credentials to join us. You don’t have to belong to a particular tribe (I’m talking to you, Mr Erlang).
You can be at school, you should be at university, and you’re never too old.
We encourage curiosity, humour, sharing, communication, open data, open thinking, open source, solving problems, being proactive, being humble, no bullshit, no suits, no ties, no malarkey.
Lastly, execution is everything. Ideas are cheap, indeed everyone has ideas, but execution is what makes ideas happen, and that’s what Hackathons are about.
Learning is good
For b) We make sure there are talks throughout the Hackathon. Some will be longish, some will be shortish, and others will be impromptu. For each Hackathon we’ll find folks who can contribute by helping / teaching / imparting knowledge.
Sharing is caring
For c) We’ll make sure that everyone gets to meet each other, talk about what they’re doing, what they’re interested in, and what they’re working on at the Hackathon.
Everyone wants to kick ass
For d) We get out of the way, and leave that up to the folks doing the Hacking.
We’ll do our best to promote the work that comes out of any Hackathon, we’ll demo good work at the Tech4Africa conference to show people what is possible with a small group of committed people, and we’ll go to bat for you with the larger companies who wish they could innovate but can’t becuase they move too slow, so that you get more time to hack 😉
The truth is that most of the major innovations and success stories in the last decade came from developers Hacking at an itch, and then productising their work. So that’s what we’re trying to encourage. Join us, do something fun, do something cool, solve a problem you care about, and most importantly, just come along for some fun!