Yesterday I attended the National Day of Civic Hacking at Code for San Francisco. The National Day of Civic Hacking is an annual event that all of the Code for America brigades participate in.

The ratio of participants compared to available projects to work on was high, so I chose to attend the various workshops that were presented throughout the day rather than try and muscle my way into a project.

The first workshop I attended was the Open Data workshop where we created accounts to access datasf.org/opendata. The most interesting thing to me about the workshop is a fair amount of time was spent learning about some of the quirks of working with the data on the site. The open data movement has thought a lot about what open data should consist of in terms of what machine-readable formats it is available in, and what sort of licensing is permissible for data to be considered “open”. However there is no agreement on what the mechanisms should look like for how people access that data. For example, what sort of language should be used to distinguish between an original data set and a derivative set? As someone simply learning about open data, I’m certainly in no position to judge if that’s an appropriate thing that ought to be standardized, but it did jump out at me while learning to work with an open data resource.

The other workshop I attended covered user centered design. This workshop involved breaking up into groups of about 5 to 7 people, and working together on a hypothetical civic problem to solve while trying to sketch out an idea of what the user is like that would use this solution. This kind of problem solving exercise is interesting when working with a group of strangers. My approach to any creative discussion is to try and find a distinct role I can serve. For example, several of the participants were often going off on tangents, so I decided my role in this discussion was to try and steer people back on topic anytime it seemed like the conversation was heading towards “infinite speculation”. I should clarify that tangents are often valuable when brainstorming since you don’t always know what you want the destination to be, or how you want to get there, but you need to balance that with the real time constraints you are under. This meant that my actual input in terms of how the problem was solved was sparse, but I nonetheless provided an important purpose for the group (making sure we had a solution we could articulate within that limited time frame).

Even though I did not actively work on any of the projects, I did have an opportunity to speak with some of the project leads who I recognized as regulars from the weekly Code for SF nights, and I was able to learn a more about their organizational challenges, which is valuable information for the Project Match app. So despite not having actually written a single line of code for the event, I felt like it was a very productive day, and a good reminder that writing code isn’t the only useful thing someone can do when working in civic tech.