Tuesday, March 31, 2015

Tale of Two Hackathons: In Which I Juxtapose


This is a longer post, which means it’s got even more awesome in it than usual! But, in case you’re short on time, I’ll outline it for you first so you can skip to the best parts if you want. It goes like this:

  1. Overview of hackathons
  2. Treatise on my experience at the Lesbians Who Tech hackathon
  3. Treatise on my experience at Hack The Commute
  4. Lessons learned

Onward!

Never having done anything like a dance-a-thon, like in that one episode of Gilmore Girls when Rory and Dean break up (sorry not sorry for that spoiler), it is unsurprising that I would be attracted to the mythical allure of the Hackathon phenomenon. In the last 30 days, I have made the myth reality (for myself – certainly it is still mythical to other non-me people).

In the last 30 days, friends, I have participated in two hackathons. I have followed their strange customs and tasted their lavish foodstuffs, and now I have returned to regale you with tales of adventure and woe.

A primer on hackathons:

Hackathons seem to vary greatly in a number ways, but there are some commonalities. A hackathon is when many people come together to create entire projects over the course of (usually) about two days. Participants have a wide range of experience (from neophyte to expert) and skills (program management, graphic design, front end, back end, UX, mobile devs, data scientists, and more). Often there is a theme of some kind – it could be themed around a particular issue, such as transit, homelessness, health, entrepreneurship and startups; around a particular technology, such as the Internet of Things; or around a particular population to create an intentionally safe space for folks from marginalized communities, for limited example, LGBTQ folks, People of Color, youth, and/or folks with intersectional identities. (By “intersectional identities”, I mean that many people are not just LGBTQ or people of color or youth or working class or people with disabilities, for instance. Many people belong to many of these populations at the same time – that is to say populations overlap and personal identities overlap, and this is an important thing to recognize and hold space for.)

The overall structure of a hackathon is to start off with pitches, where a bunch of people have a small amount of time to explain their ideas, after which participants form into teams. Not all projects move forward from the pitch phase, depending on whether they garner enough interest. Teams then retire to their corners to work until some abnormally late hour, only to return at 8 or 9 the next morning and continue working through the next day. The point is to create a prototype of the app in time to present a demo at the end of day two. In some cases, judging and prize awarding happens next, as some hackathons are competitivee.

Be advised: also true of all hackathons is that you will be awash in a glorious sea of snacks and catered meals! 

I had very different experiences in my two hackathons, so let me run through a couple of case studies in how hackathons can differ, and how this can affect the experience.


Hackathon #1: Lesbians Who Tech

My first hackathon was part of the Lesbians Who Tech Summit (or LezzieCon, as I like to call it), and it was hosted at the Mozilla offices in SF, which a) are right on the water, and b) house a truly magnificent fantasy snack island paradise. Seriously, I approximate 60% of my conversations were about the amazingness of the snack area.

There was no competitive aspect to this hackathon, and it had a broad theme of social justice. I was really excited for this hackathon as a way to try it out in a safe context. As a butch queer fat lady, you never quite know what you’re gonna get at broader tech events. And, as a generally nervous person, taking out a key piece of potential stress was really helpful. I might not know what I was in for, but I sure know lesbos!

Team Selection Process:

After some facilitated icebreakers and the traditional exchange of personal pronoun preferences, folks gave pitches on somewhere around 15-20 projects, and a piece of paper for each project was taped to the walls, distributed throughout the room. We were then bestowed with two votes – circulated around the room, and marked our two votes on the projects we wanted to see happen. After eliminating a number of projects for low interest, we then were to choose the remaining project we wanted to work on, by standing next to their sign. At this point, a few more projects were eliminated, again for lack of interest. Within our groups, we talked about our respective skillsets, and were then given the opportunity to address the entire group and ask for help with any holes we anticipated (e.g. – a group full of product managers might need some coder help)

Team Selection – How it went down:

I chose my team based almost entirely on the project I felt most passionate about. The app was to track immigration paperwork for folks who have navigate the labyrinthine process applying for visas. It was a relatively small group, with five people total, and when we discussed our skills briefly, it seemed like we had things pretty well covered. We had a database person, a person with Rails experience, me with a little bit of Rails and some front end, a person with some graphic design background, and the person with domain knowledge about the visa process. It turns out we would have benefitted from getting into a bit more detail about this.

Work Process:

In truth, the first day was pretty frustrating. We talked in circles a lot, trying to bridge the gap between technical and non-technical lexicons, not entirely successfully. I felt like I didn’t know either well enough to bridge them, and I couldn’t quite nail down what anyone was trying to say, much less how to bridge those gaps. As a result, I often felt like I had no idea what we were trying to do. We ended up using a prefab frontend template from Wix, since the woman with design background was comfortable working with that, but it ended up to not have the ability to connect to a database. Our main Rails person hadn’t worked in Rails in a while, it had been a while for me as well and I hadn’t know that much to begin with, and our database person wasn’t familiar with web development at all. What’s more, we could barely move around in our tiny tiny room – our tiny hot room. What I’m saying is, the first day was a hot mess.

Day two was better. We got out of the awful small hot room, and worked in a big main room with couches and a/c. We knew we were going for some small goals: 1) get the skeleton of the project GitHub so other folks can keep contributing moving forward, and 2) create an unembarrassing demo presentation. With the nicer work space and the narrowed focus, we had much more of a calm and productive working day. And, at the end of the day, we did accomplish those two goals. Our presentation worked out, folks were supportive, and I was mightily relieved and grateful for the Rails person, who had really taken the brunt of the work. After that, it was great to support other people in their presentations. Even better, I talked with a lot of really cool people after the demos. Many cards were exchanged, many efforts applauded. More than anything else, this made the experience worth it.

Upon reflection, I formed a few hypotheses about how to approach the next hackathon.
My first hypothesis was that a larger group would reduce the pressure on any one member (not to mention myself). My second hypothesis was I should place higher importance on understanding the skills of other in a potential team, and choose based less on the project itself, and more on whether I would be able to get help from teammates.

Hackathon #2: Hack The Commute

The second hackathon was Hack The Commute (HTC), a hackathon put on by the City of Seattle and partner businesses. Seattle is growing fast, which is aggravating preexisting traffic and transit problems, so the goal of HTC was to put the talents of a thriving tech city into the problem. This hackathon was judged, with winners moving on to compete at an event in late April, and was hosted at the Moz offices in downtown Seattle. HTC had a ton of resource people on hand to help, so every group knew what data was available to them, and had help crafting their final presentations. There was quite a bit of effort and attention put into creating smooth and safe infrastructure for the event, and it showed. It was impressively well run.


Team Selection Process:

HTC – We were told a number of different subjects for which experts were on hand to talk about (e.g. parking, accessibility), and these folks camped out at different tables in the giant main room. The rest of us then circulated throughout the room to have conversations with these folks and other interested participants about project ideas and available data. After about 45 minutes, people then did pitches on project ideas that came out of those conversations (though some folks came in with set project ideas, as well). After this, we again broke out to form teams by talking to folks whose ideas we liked. This process happened on Friday night, so that we could leave after forming teams and be ready to start working from the get go the next morning.

Team Selection – How it went down:

HTC – I was determined to test my hypotheses on team selection, so I knew that I wanted to get on a team with enough people so that nobody has to take the brunt of the work, with enough expertise that I could get help, and with enough of a good vibe that I would have fun. My main passion was for accessibility, but I hadn’t gotten a good sense of the skill level of the other folks in that group, and it seemed like available data might be problematic, and the group was small.

Instead, I and a couple of friends joined a team working on an app that would crowd source and make a game of identifying open parking spaces downtown. We had heard a statistic that roughly 30% of the traffic downtown at any given time was people circling, looking for a parking space – this app was to make the process easier and hopefully cut that figure down. What drew me to this team was the charisma and inclusiveness of the guy who pitched the idea, and my group size and skill criteria were met. Downtown parking may not be a great passion, or my life’s work, but it is a problem and this project could be an interesting and engaging solution.


Work Flow:

HTC – Overall, this went much better than my first hackathon, and I would say that my hypotheses were supported. Nevertheless, it was not without it’s own hitches. I had pre-arranged to arrive late the first day, and by the time I got there, the team was cruising. This was really cool to see…and I was intimidated trying to find where to jump in.

As a perfectionist and lifelong Really Smart Person™, one of the reasons I came to this second hackathon was to get practice sucking at things in front of people – and this is exactly what I slammed into right away. I didn’t know where to jump in, we were using a number of things I had never seen before (e.g. Koa and Jade), and I was far and away the least experienced person in the room. I was convinced that I was going to hold the group back and that the people in the group I already knew would realize I was dumb. But, instead of running away crying, I asked for help. It turned out that the group was a bunch of really nice people, very willing to help. They went over the high level view of the app with me, and helped me figure out a niche that worked with my skills. So, even though I still had lots of questions, and even though Git made me its bitch over and over, I came away from the experience feeling like I had contributed. We made a wicked cool app, and it looks darn nice if you ask me.

(The app is called MeterQuest. Check out the repo!)


Lessons learned:

  • Hackathons are worth doing, even if they don’t go exactly how you want.
  • Do what you gotta do. If you need to sleep in or leave early, fine. Do it. Need to walk around the block or cry in the stairwell for a minute, fine. Do it. If you need to have a snack and chat with people from other groups, that’s fine, too. Do it. You’re there to make things, yes, but also to have fun and to meet people in your field. You are definitely not there to be miserable. Do whatever you need to do to keep yourself moving forward and having fun. You can also just leave if you need to.
  • Team selection is stressful. It just is.
  • Consider more than just your subject interests as you select your team. Also choose based on the vibe of the team, the skill level and skill sets of others in the teams, and anything else that is important to you. For me right now, this means choosing a team based on their likelihood of being fun and the likelihood there will be folks who can help me with coding obstacles.
  • Hubris is thinking Git can no longer make you cry.
  • Prepare for a bit of a roller coaster. There will be terror, regardless but there will be adrenaline upswings, too.
  • People are really supportive about your projects and presentations. Nobody’s there to tear you down.
  • You may need to deal with microaggressions, though, so maybe think about how to prepare yourself for that – what your needs are, what you will want to do if they happen, maybe even reach out to the organizers ahead of time.
  • EAT ALL THE SNACKS!


2 comments:

  1. There are lots of information about latest technology, like Hadoop cluster is a special type of computational cluster designed specifically for storing and analyzing huge amounts of unstructured data in a distributed computing environment. This information seems to be more unique and interesting. Thanks for sharing.
    Big Data Course in Chennai | Best Hadoop Training in Chennai | Big Data Training

    ReplyDelete