Three lessons from Hacktucky on how to build and launch projects in real life

Screenshot from

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 and redirected to the GitHub page of our repository. Larry pushed the code live and...


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

KK Rebecca Lai

Undergraduate Fellow

Latest Posts

  • With the 25th CAR Conference upon us, let’s recall the first oneWhen the Web was young, data journalism pioneers gathered in Raleigh

    For a few days in October 1993, if you were interested in journalism and technology, Raleigh, North Carolina was the place you had to be. The first Computer-Assisted Reporting Conference offered by Investigative Reporters & Editors brought more than 400 journalists to Raleigh for 3½ days of panels, demos and hands-on lessons in how to use computers to find stories in data. That seminal event will be commemorated this week at the 25th CAR Conference, which...

    Continue Reading

  • Prototyping Augmented Reality

    Something that really frustrates me is that, while I’m excited about the potential AR has for storytelling, I don’t feel like I have really great AR experiences that I can point people to. We know that AR is great for taking a selfie with a Pikachu and it’s pretty good at measuring spaces (as long as your room is really well lit and your phone is fully charged) but beyond that, we’re really still figuring...

    Continue Reading

  • Capturing the Soundfield: Recording Ambisonics for VR

    When building experiences in virtual reality we’re confronted with the challenge of mimicking how sounds hit us in the real world from all directions. One useful tool for us to attempt this mimicry is called a soundfield microphone. We tested one of these microphones to explore how audio plays into building immersive experiences for virtual reality. Approaching ambisonics with the soundfield microphone has become popular in development for VR particularly for 360 videos. With it,...

    Continue Reading

  • Prototyping Spatial Audio for Movement Art

    One of Oscillations’ technical goals for this quarter’s Knight Lab Studio class was an exploration of spatial audio. Spatial audio is sound that exists in three dimensions. It is a perfect complement to 360 video, because sound sources can be localized to certain parts of the video. Oscillations is especially interested in using spatial audio to enhance the neuroscientific principles of audiovisual synchrony that they aim to emphasize in their productions. Existing work in spatial......

    Continue Reading

  • Oscillations Audience Engagement Research Findings

    During the Winter 2018 quarter, the Oscillations Knight Lab team was tasked in exploring the question: what constitutes an engaging live movement arts performance for audiences? Oscillations’ Chief Technology Officer, Ilya Fomin, told the team at quarter’s start that the startup aims to create performing arts experiences that are “better than reality.” In response, our team spent the quarter seeking to understand what is reality with qualitative research. Three members of the team interviewed more......

    Continue Reading

  • How to translate live-spoken human words into computer “truth”

    Our Knight Lab team spent three months in Winter 2018 exploring how to combine various technologies to capture, interpret, and fact check live broadcasts from television news stations, using Amazon’s Alexa personal assistant device as a low-friction way to initiate the process. The ultimate goal was to build an Alexa skill that could be its own form of live, automated fact-checking: cross-referencing a statement from a politician or otherwise newsworthy figure against previously fact-checked statements......

    Continue Reading

Storytelling Tools

We build easy-to-use tools that can help you tell better stories.

View More