Four years ago, I went to my first Hackathon in the basement of the Biltmore building in Midtown Atlanta. I had worked two years as an engineer in a Fortune 50 company and had never been to a Hackathon before this. I also had never spun up an environment – from the database to webserver to the actual dedicated machine – by myself before then, and I felt lost while working with the other members on my team with the speed at which they worked through the terminal and cranked out code.
Two years at my job had taught me that every resource needed an approval and all your access came with strings attached. I realized how far behind I was compared to the other guys sitting at my table. This was just the beginning of the move to the cloud. Everyone in 2012 was still hosted locally – most companies had server racks next to the HVAC room in their office.
The guys at my table didn’t work at small start-ups with unlimited rights to the servers they used. Most of them worked at large or medium sized companies like me, but they were much more comfortable setting up an application from the ground up than me. I realized I needed to branch out from my everyday work – but I couldn’t do that with just my day job.
I started going to Hackathons almost every week after that. At first, I worked with guys I had known previously and who I knew could do the work. Then, as time went by, I started to work by myself – even though almost all hackathons encourage you to work in large teams. I still remember getting in front of two hundred people at city hall by myself to present an app I built that used real time voting to predict the diversity of the crowd in attendance. It was probably as nerve wracking for the crowd as it was for me. To show off my app, I had to touch on a pretty sensitive subject: our heterogenous backgrounds (my app predicted the racial make-up of the audience) and the preferences we have because of our different up-brings (by giving random questions for the crowd to answer before telling them what the purpose was).
The more I did this, the more I became at ease with working by myself. I could arrive at an event, sit down, and spin up everything with boilerplate code in 30 minutes. Then spend the night working on the features I knew I wanted to incorporate. I became a better developer because of this – not only at hackathons, but also at my day job.
As a developer, one of the biggest disadvantages we can pigeonhole ourselves into is to become too comfortable with the little slice of space we occupy on the assembly line. It’s much more rewarding to not only understand the different parts of the application that touches what we’re working on, but also have the ability to do that work yourself.
There are a lot of ways to achieve this goal, but hackathons are a pretty good option. Does this mean you should drop your social life and spend 36 hours each weekend coding at hackathons? No, but doing a few can be immensely rewarding.
