What it’s like to host a hackathon
How organizing a hackathon brought my team closer together and helped us explore.
We have to find the time to do cool stuff
We’re all busy. Sometimes, like, way too busy. I work in “professional services”, which means every hour I spend should, ideally, be billed to a client. Sure, there are administrative things that pop up, but by-and-large, if something isn’t tied to money coming in the door, it’s pushed aside. Gotta keep the lights on…
Our technological expertise is often our differentiator, yet it can be difficult to be the “expert” when we’re so busy delivering for our clients. We win because of our expertise, and while we’re busy building, then industry breezes past us.
So, when do we get to do our own shit? When do we get to “play” with new technology? How can we explore new ideas with the freedom to fail?
I think it requires our own investment. In the past, our office has shut down for an entire day to hold a “Hack Day,” where many disciplines combine to play with novel solutions to innovative problems. The problem is, it’s expensive, hard to schedule, and tough to justify with regularity.
Scheduling
Instead of organizing an entire office of designers, developers, and managers (over 80 people), I focused on one discipline: Front End Development. Reducing the head count made the budget, and scheduling much easier.
Saturday won.
We’re Better Together
We could all explore technology on our own time, this is true. I’ve just never been that developer. The one who built a new templating framework “for fun” over the weekend. I’d like to think it has something to do with experience, once you’ve learned a handful of frameworks and have seen them rise and fall in popularity, you start to become a more guarded with your time.
That’s the flattering justification. You could also comfortably say that I’m just too lazy.
The truth probably lies somewhere in the middle. I’m a little lazy, and I have more fun working with other people. I justlove being a part of a team. I love learning directly from other people and being challenged that way. If I didn’t, I’d probably be freelancing right now.
“Together we’re better” isn’t a ground-breaking hypothesis, but it’s something I’d hoped to test during our Hack Day. Would we come up with some cool shit that we wouldn’t have on our own?
It’s hard to say scientifically that one Hack Day can prove a team of people are better than a group of individuals, but I think it’s something we all intrinsically understand. There’s a sense of gravity between people, intuitively making groups and order out of chaos. This Hack Day was no different.
We came up with some really cool ideas and took the first steps to making them “real.” I’ll chalk that up as a win.
We ended up with two teams of 2–3 developers.
Manufactured “Fun”
I’m the ninth developer to join the team (of nine total). Although we happen to sit together and chat in between meetings, we’re almost always buck-shot across a handful of projects at any given time, meaning collaboration is a rare commodity.
That means our opportunities to come together have to be manufactured: team lunches, brown bag sessions, and project demos. Those can be great for knowledge-sharing, but a Hack Day actually allows us to develop together, on something we’re excited about.
Out of nine developers, five agreed to attend. Considering I was asking folks to come in on a Saturday morning to hack on stuff for fun, I think that’s pretty good.
We met the day prior to the event, and discussed ideas to work on and how to delegate, so that we could hit the ground running. We brainstormed for about an hour and ended up with two very different ideas, and split into two teams for the Hack Day.
Idea #1 — Blockchain
Blockchain is something our team has long hoped to work with, and has the potential for client work “down stream,” as my consulting brethren would say. Those two factors make it ideal for a hackathon!
Idea #2 — Spotify
This idea was more light-hearted: Spotify app for use at office happy hours. We’re not unique to the tech industry — our team often caps off a week’s worth of work with a beer/happy hour in the kitchen. We thought it’d be fun to bring some personality into those ad hoc get-togethers by creating an app that would create a playlist based on all the attendee’s music history on Spotify.
Time Flies, Cut Scope
Both ideas went unfinished Saturday. They’ll eventually get done, as time allows, but each team bit off more than they could chew. We had six hours allocated to hacking, and we probably needed about double that to actually complete either idea.
I vastly underestimated the time we’d spend spinning up environments, mapping out ideas on white boards and figuring out stupid configuration bugs.
It’s hard to estimate what is the right size for a project you’d like to complete in a day. It should be big enough to be exciting, but small enough to be realistic. That sounds easy enough, I learned that I turn into a terrible client when I have an idea that I’m excited about. As my excitement builds, so does the scope. It’s a familiar situation to all developers, but I thought I’d know better. I sure didn’t.
Although I regard the day as a success, it would have been even more awesome to have something concrete to show for it at the end of the day. If we had cut our scope down, and perhaps done some more preparation up front, we might have built something we’d be able to demo.
Balancing Learning & Production
Ostensibly, a hackathon is an excuse to learn new technologies and improve your skills through collaboration. In practice, however, you find the same struggles that you encounter during a project: learning new things takes time, which slows down your progress.
That dilemma is brought to the fore-front when you’ve compressed everything into one day. What is more important, finishing your idea, or learning something new? Ideally, it’s a bit of both, I think.
Conclusion
Finding an excuse to get together with the people you work with and do something fun and share your passions is pretty awesome. I recommend it.
You end up learning a lot about your colleagues, beyond just what frameworks or languages they prefer. You learn things like who can “own” a whiteboard, who prefers to just get started building something, and how tolerant everyone is of 90’s hip hop played through an Alexa (I got a mixed response to the Nelly-and-Ja-Rule-heavy playlist).
Pros
- Fun factor
- Opportunity to work on something “different”
- Stretching skills and learning from peers
Cons
- Takes extra time — coming in on a Saturday not only takes a lot of organization, but obviously eats up a half a weekend.
Have fun hacking!
