Last weekend I participated in Hacktucky, the Society of News Design's first annual hackathon (held this year in Kentucky). The goal of the hackathon was to build and ship something of local interest within 24 hours. It was an amazing learning experience and it reminded me that habits that are absolutely essential at hackathons should also be used in the real world.
The team I worked with had very a diverse background and it was hard for me to imagine how we would come together to combine our expertise, but we eventually gelled perfectly. Larry Buchanan, interactive designer at The New York Times, took care of all the front end development, design and illustrations, while I created interactions with javascript and the foursquare API. Daniel Johnsen from The Learning House helped problem-solve and together with Diane Hawkins, a copy-editor at the Louisville Courier-Journal, curated content that populated the site.
In the end, our team created an app called LouPass. We wanted to foster community involvement and get kids excited about their city. LouPass allows families to check in to places through our app and to earn stickers that they can print through our site.
By the end of the weekend, I'd gone form meeting some strangers, to hacking for 24 hours to creating something that I was proud to put my name on. Here are a couple of lessons I took away from the hackathon that are also relevant in everyday hacking.
1. “Ship it or it didn't happen”
One of the criteria for the hackathon was to ship a live product. This mandate really helped us plan a manageable project and pushed us to finish on time. This was also my biggest takeaway from the hackathon: You can work on a project infinitely on your own, but it never really exists unless you push it online and let other people see it, use it, compliment it, or tear it apart. The hackathon really made me less self-conscious about my shoddy code and more excited about pushing stuff out to the world.
2. Commit often
Our team used GitHub to collaborate on the project. Larry created a GitHub repo and we started collaborating through Git. Our commits came in really handy when I pushed a change to the stylesheet that wiped out the styles on our badges page. Larry went back through his commits and found one named 'badge styles' and pasted it back. While it's sometimes tedious to document every change, you never know when that information will become handy.
3. Deploy Early
We decided to deploy our site at noon on Saturday — about five hours before the competition ended. We didn't have a finished product at that point, but we wanted to see how everything worked live. Our team bought the domain loupass.com and redirected to the GitHub page of our repository. Larry pushed the code live and...
Ahhh!
CSS links were broken, images were missing, and our redirect page after login gave us a 404. We spent half an hour working to fix all the links and probably another hour fixing the 404. All told, we spent two hours getting our project to work online. Another team started deployment with an hour left and wasn't able to get the project online. The lesson: deploy early.
Hackathons are generally unlike real-life situations in terms of the intense time constraint and the work environment. But all the things I learned at the hackathon felt extremely relevant to my everyday work. I'll be keeping an eye out for other hackathons to help improve my work!
About the author
