This summer series will highlight weekly blog posts from this year’s UW Data Science for Social Good Fellows. Scroll down to read posts by Kellie MacPhee and Joe Abbate.

“Being right” by Kellie MacPhee, 2018 Data Science for Social Good Fellow

In mathematics, right and wrong are clearly distinguishable.

Sure, there are questions of style and clarity which make certain approaches arguably “better” than others. Fundamentally, though, the structure of the subject is such that given enough time and energy, a mathematician should always be able to tell true from false and right from wrong.

In data science of the social, on the other hand, there are no such clear-cut answers. Even a well-intentioned project and perfectly computed statistics can be harmful or invalid, depending on the way in which they are carried out. In transitioning from the day-to-day work of my mathematics Ph.D. program to the day-to-day work of the Data Science for Social Good (DSSG) program, these considerations on right vs. wrong have led to a significant disruption in my usual workflow and method of thinking.

Sometimes this can be frustrating. I want to see progress, and I want to be useful. When we take time to have impassioned discussions about the goals of our work, the standards we set to determine success, and how these goals and standards align with the wants and needs of our project’s stakeholders, there are no easy checkboxes to tick off knowing we’ve completed a task correctly. Reflecting and communicating about why our work is valid is hard. (That’s why I majored in mathematics instead of the social sciences, really.)

That being said, I appreciate the heavy emphasis that the DSSG program places on intention and reflection in our work. Theoretical mathematics has little concern with the ethical implications of its products, since for many mathematicians the beauty of the subject lies in its abstraction and generality, which remove it from the realm of people and the planet. Often in the application of mathematics and other sophisticated technical tools, though, ethical concerns do arise.

People tend to place high value on (and assume objectivity of) technical solutions, so we technically-inclined folks have a major responsibility to be transparent, honest, and ethical in our work. The problems tackled by DSSG teams are by virtue thorny problems, and it will take more than my usual mathematical logic to evaluate their effectiveness. I am already learning so much from my collaborators with different academic backgrounds about how to approach “right” and “wrong” in these unusual-to-me contexts, and I look forward to even more impassioned and valuable discussions on the topic as we move forward.

1 The question of what is “useful” or “valuable” to the field

2 Lots of good examples at https://callingbullshit.org/ and in books such as Weapons of Math Destruction and Automating Inequality.

————

“How to learn when things are obvious” by Joe Abbate, 2018 Data Science for Social Good Fellow

Our first tutorial was on “Human Centered Design”. The idea: when a system is being engineered (especially software) for use in the real world, one must consider not only the way the user will use the system, but also the way the system will fit into a broader social and technical context.

When I came into this tutorial, this point seemed obvious. I’d studied the ethics of computer science in a reading group for a year, along with presenting multiple times on the subject at workshops. I’d created software projects that required this type of higher-order thinking. And I’d read countless blogs and articles endlessly repeating that software design isn’t just about the ability to code.

Nonetheless, the tutorial wasn’t just about repeating phrases. The primary activity was breaking up into groups and applying the principles to a specific case study. Although the idea and importance of human-centered design was obvious to me, effectively applying it to a specific situation – in my case ameliorating food distribution in a poverty-stricken country – was not. In the end, I learned quite a bit from struggling with nuances alongside others who had actually visited such countries and worked in food distribution. When I noted that we would have to consider that many farmers wouldn’t have internet access or wouldn’t have the time or motivation to accurately fill out information in an app where there is no direct incentive to do so, my group pushed me to actually come up with solutions. Ultimately, we agreed to change our whole system design: the new users of the app would be the UN workers who would physically visit sites, rather than farmers themselves.

In the end, then, I was able to learn more about Human Centered Design – a subject I thought I had mastered – by applying obvious knowledge in a team setting to a novel problem.

The next day was our Git and GitHub tutorial. I already had worked extensively with Git and GitHub in both my research and in web development side projects. I had down pat my “pull, resolve merge conflicts, add, commit, push” workflow that I had used for all of these. So during the beginning of the tutorial, I worked on something else. Incidentally, I had been charged with writing a tutorial for new-member onboarding to my research group, and my goal was to write a good paragraph on our Git workflow.

Although I found myself easily writing down the necessary commands, it became clear that the person reading it would not understand why we were doing these things and would get lost if they had to deviate slightly from the specific lines I was ranting off. Tuning into the tutorial, I found that rather than listening for the rote commands from the lecturer, I began looking out for the way she was explaining the concepts to us so that I could learn to better describe the process to entering group members.

I began asking questions like “why do we use Git and GitHub”, and realized that beyond tracking changes and giving us a common repository to work in, it also makes possible instant collaboration by future researchers should they decide to join the team. I asked “what are examples of common workflows” and learned about other possible ways I could have done projects in the past, which in turn made me realize the reason we in fact had done the projects the way we did.

By the end of the tutorial, I had a much better set of introductory remarks to Git and GitHub for entering group members. This time, I learned more about an “obvious” topic (Git and GitHub) by trying to effectively explain it to others.

The upshot of all of this is the following: If something is obvious in practice, then explain it in theory. If something is obvious in theory, then implement it in practice (preferably with a group of people who think differently).

And if the point I’ve been making in this article is obvious to you, that’s perfect! The DSSG program – with its teams of diverse students working on novel problems while communicating the solutions to stakeholders and funders – is an ideal place for you to implement it in practice.