Relevant Ideas

Do what you’re good at


Created: March 31, 2014 | Modified: March 31, 2014

It took us five days to get Culture of Yes, or what I affectionately call: “Our project on crack: A story of brainstorming, prototyping, development, and deployment in the span of five days,” up and running live.

The five days

We received over 300 hits within our first 24 hours of going live.

Full disclosure: I’m not going to go into detail about Monday – Wednesday; it’s really the least exciting part of the project/story. Trust me.

In case you’re really dying to know, the picture on the right (or possibly above depending on your screen size) is from Tuesday (AKA the time everyone decided that I was benevolent dictator of our project).

Here’s what you really need to know:

When I think of hackathons, I typically imagine events where teams of people (all of whom are probably wearing hoodies) get together, stay up all night writing code and drinking lots of coffee, and end up producing some sort of awesome (and possibly bizarre, eclectic, or whathaveyou) program or application.

I’m not a computer science major. Nor do I know 10 different programming languages. But here are a few things I knew then that would still ring true now:

  1. I know that I can build a damn good application.
  2. I know that if I’m going to devote my weekend to something, it’d better be damn worth it.
  3. I know that I’m ambitious (we did indeed write 50 scrapers) and that I don’t like to lose.
  4. I know that if we even want to have the slightest chance of winning this thing, we need to do what we’re good at. We’re journalism majors. We need to tell a story.

While the first three points were only ever (explicitly) stated in my head, the fourth was one that I voiced to my group during lunch on Saturday before the hackathon even started. And as I said this, I could see myself shoving my (now former) dreams of absolving myself of back-end work during this hackathon out of a 10th story window.

I had no doubt in my mind that we’d be using Django as our framework for whatever idea we landed on. This is, essentially, what it was built for – to get projects up and running fast. And as the one most familiar with Django, I logically became the best choice for setting up the project.

Producing an awesome project > not wanting to do back-end

After we finally nailed down a topic, much thanks to some of the more “idea” oriented people in my group, we set to figuring out what exactly we wanted our app to do. We chose to incorporate a narrative element, and to allow for a comparison of sorts. If you’re interested in seeing more of exactly what I mean by that, check out our application.

As we shifted into a more serious mindset post-dinner, we were on the hunt for a quiet, but brainstorming/prototyping friendly environment to work in. I admittedly have a propensity for seeking out remote spots in a particular building on campus, so our decided location kind of ended up as a no-brainer. While the actual name of this room bears little importance, our entire team now refers to it as “The Batcave.”

And thus we toiled away in “The Batcave” all of Saturday night through Sunday at 2 p.m. when we presented our project. (We were technically there on Tuesday night as well, but that seems less relevant.) Take note of how mentally fried the two of us in the back of this picture look. It was roughly 5:30 a.m. at this point.

I will not lie to you. As on top of it as we were, we SCRAMBLED to get this thing “done” on time. I use these quotation marks hedgingly because I don’t want to imply that the project was perfect at this point. It was presentable, but we definitely had a few kinks to iron out. That said, we were all immensely pleased with our product. We did not, however, expect to win the competition.

While we were proud of our application, we didn’t necessarily expect the judges to view it in the same manner that we did. But apparently they did, which was awesome. And I honestly believe that sticking to our aforementioned mindset is THE reason that we were able to pull off the victory that we did. Sure, everyone on our team could write code, but none of us do so solely for the purpose of “writing code.” At the end of the day, we’re j school kids who see value in learning technical skills. We use code as a means of telling our chosen story, whatever that may be.