What I learned at the CODEX Hackathon

I was excited to have the opportunity to attend the CODEX Hackathon in San Francisco this weekend. It was scheduled at the same time as ALA and Pride (just days after the Supreme Court’s ruling about same sex marriage). Needless to say that San Francisco was buzzing. I had a few things that I wanted to get out of the hackathon, so it’s interesting, now that it’s done, to reflect on whether or not I “have” those things in hand now.

See a large hackathon in motion

I have been interested in hackathons for a while. The idea of people quickly organizing themselves into productive working teams is really interesting to me. I was a very passive participant at a National Day of Civic Hacking event in Chicago two years ago. More recently I helped plan a teen hackathon for the library. Both events were smaller. And, I missed the teen hackathon because I was sick.

Clearly there are advantages and disadvantages to having a larger event. I believe there were roughly 100 participants at the hackathon–the numbers were very fluid. This allowed people to come and go and it didn’t severly impact the critical mass it takes to run this type of event.

One clear advantage is that there is larger pool of people and abilities to pull from. That said, it doesn’t necessarily increase the odds that you’ll get the right people (or exactly the right people) on the team. I was very happy with my team, but we definitely had to scale our work to our abilities.

I think a major disadvantage is that attendees increasingly fragment in to their teams, making it harder to make connections later in the event.

Challenge myself and learn new skills

When you show up at a two day hackathon and say, “I’m going to help make something”, you know that you are standing at the base of a mountain looking up. And, you have no one to blame but yourself for the difficult terrain you’re about to traverse. For me though, the hackathon was an opportunity to stretch myself and get out of my comfort zone.

This was especially true when it came to the collaborative parts of the event. Even though I have a web developer on my team at the library, we don’t collaboratively code all that often. One of the more enjoyable parts of the hackaton was stretching my git and Github skills a bit.

One of the more difficult problems my team faced was modeling and building out a simple backend for our project. On the first day our team member with backend skills said he couldn’t attend the second day. So, we had to quickly adjust our ideas about what would constitute a deliverable “mvp” by the end of the event. We ended up making a static site with Jekyll.

So, being able to quickly build up a simple backend would be a very helpful skill to have at this type of event. I had built a very simple web app in about two weeks with Meteor, but the memory was just distant enough that I didn’t feel confident leading the team through it.

While being able to quickly prototype a backend would be helpful, I think it placed a constraint on the team. Early on, the constraint was helpful because we had to pare down to bare essentials to “make it work”. But without a backend holding us back, I think we could have let our imaginations run a little wilder.

Doing versus teaching/learning

In addition, to these goals, I found that I enjoyed the process of teaching and learning as much as the “doing”. I helped a few team members get their bearings with a few technologies they weren’t familiar with. The learning opportunity was rich and exciting because the exercise wasn’t hypothetical and abstract. We needed to get something done and here was an obstacle in their way. So, we did our best to clear it together. Knowing this, I think it would be worthwhile to try to imagine a hybrid hackathon that combines doing and learning in a very intentional way.