14 May 2016
A couple of weeks ago, I had the honour of giving my very first keynote, at CSVConf in Berlin. It was a lovely, community-run conference “for data makers everywhere”, and I appreciated a lot about the way it was set up.
For starters: the very idea of asking me to talk at the conference. In his introduction while presenting me on stage, one of the co-organisers, Max Ogden, said that one of this favourite things about organising CSVConf was to bring the community together - and then bring new ideas and people to talk to them. I found that attitude to be incredibly refreshing (and also a little intimidating, if I’m honest!). It’s definitely true that I’m not an expert in many of the areas that were being talked about at the conference during the main sessions, but I do work on related areas that lie slightly outside the usual purview of the majority of attendees.
From my perspective, it gave me the opportunity to think carefully about how to present my work, in an accessible way to a new audience. Preparing the talk led me to one major conclusion: that much of the ‘data ethics’, or responsible data work that we do, is much more about asking the right questions than it is about having the answers.
This attitude of embracing uncertainty and realising that some questions will be answered in very different ways depending on the context, strikes me as fairly contrary to the approach that many developers take when it comes to technical questions. In issues of data ethics, the answer doesn’t lie in technical documentation, and something you’ve learned on the last project might be totally wrong on this one - which on one side keeps me on my toes, but on the other, can make it hard to understand.
I tried to explain this through a series of examples from the Responsible Data Reflection Stories, and from Sean McDonald’s paper on the (mis)use of data in the Ebola crisis..
I also tried to convey this attitude in the structure of conclusion: instead of a set ‘conclusion’, I ended with a series of questions for the audience to ask themselves. I know that some of them might not be relevant in all cases, but I hope that some of them gave food for thought - and perhaps even highlighted the importance of more people working on tech projects thinking about the ‘why’, not just the ‘how’ or the ‘what’.
The slides for the talk are here: