tldr; Ask less questions at a hackathon. Just build it

On Saturday, September 22, 2018 I attended a hack Civic Tech Volunteer Hackathon in Seattle. I just moved here about 3 weeks ago so this seemed like a good place to meet people and really just something to take up a Saturday. After this long day, I learned a lot about teamwork and how I can contribute to ad-hoc teams compared to a standard working environment. Primarily, don't contradict the project leader too much. Don't waste time validating the project. Just build it to the best of my ability.

First off, the event said it starts at 8am. I don't know about you, but as a software engineer, 8am is way too early. I haven't had to show up at 8am for anything besides MTG GP's (For those unfamiliar: Grand Prix). I stumbled out of bed at around 7:30 feeling extremely thankful this event is basically down the street from me. A shower and some more mindless stumbling about later its 8am. I rush out the door at this point.

I walk in as the project pitches are just starting. These pitches came from people who clearly don't do startup pitches. Add on the fact that I couldn't hear most of them. I ended up just looking through the project list on my phone.

Eventually, I join a group called Feedback Friends that was run by Jessica Dang from Results Washington. This group consisted of 5 volunteers and 3 members of Results Washington (a fourth joined later but also left early).

This is our original problem statement:

Surveys don’t equal empathy. Or understanding.

The concept is to provide a way to capture real-time feedback and experiences from both customers and employees around the state.

We’d like to explore the viability and feasibility of the idea.  The initial idea was to use voice and video recordings from mobile devices readily available to customers and employees. We’d like to understand how we could quickly design a pilot with a few locations around the state. We could also market the tool to all Washingtonians, not to just those with a recent in-office interaction.

This is the hypothesis we ended up with:

Real-time feedback from visitors of field offices will provide better insights in visitor expectations and reality.

That statement took us over 2 hours to come up with. We all debate whether the study will solve anything and how to best implement it. I definitely hinder the progress here. If you look at my notes, you'll see my early notes are trying to figure out basic concepts. The team lead knows the answers, but at a hackathon we don't have time to explain every detail. A lot of our discussion focused on how the government works and how if this research will actually be useful.

We eventually settle on a two-pronged approach by splitting the team. Two guys will work on a MVP of this database tool that would be needed.. The rest will continue the discussions. I, honestly, agree just to reduce the team size. We still have far too much discussion going on.

The discussions go on until an hour and a half before presentation time. At this point, I force the issue and have us draft a project plan for executing this research study. Its not the best, but at least its a deliverable.

In reflecting on my day at dinner, I concluded that we wasted a lot of time just re-verifying facts and could have spent that time working on something. Anything.

The takeaway here is that we were clearly not the domain experts. We weren't going to become domain experts in this short time we have. No one expects for us to complete the entire project or even being remotely close, so we have the luxury of building something that turns out to be wrong.

The normal strategy of work smart and not hard doesn't seem to work as well in a hackathon. At least, not in the traditional sense. Instead of being afraid to even start a project, just start it and work smart by using all those micro-services available now. Don't manage my own payments, don't code the entire base html by hand, don't even script the forms by hand. All those small customizations can be done by a full-time developer later. Just get the product working for now.

This mentality brings up the question, "Is building something that doesn't do what the client needs good enough?" After spending a day not completing anything besides brainstorming, I think "Yes". Building something, anything will be good.

As a final note, I want to point out that I forced us to create a project plan because I didn't see anything else coming out of our discussion. However, I believe that some other team members were driving the discussions towards something. I don't know what that was though. Its entirely possible that I could have said nothing and we would have eventually arrived at some conclusion.

This was the first hackathon I really feel like I participated and lead a significant amount. This was also the first hackathon where I feel I definitely lead the team astray. I wrote this so I would remember at least some details and hopefully deliver a better final product next time.

I'm also working on my writing skills. Any feedback is greatly appreciated. I know I get lost in different trains of thought