The Function of Bias

Sara Simon
14 min readJul 13, 2016

--

Adapted from a talk at the July 2016 Brighton Ruby Conference.

My name is Sara, and I work at Vermont Public Radio. My job on the digital team is to write code, but nothing in technology is ever exclusively about code.

This is a piece about the process and product of code. It’s a piece about the open source community, about maintenance and tests. About starting projects from existing repositories, using existing APIs, and copy/pasting existing lines of code as that big, scary word we call plagiarism looms over a 21st century newsroom.

It’s a piece about building something the right way under deadline. About humans who write algorithms that determine the news. It’s about bias and about the function it serves. About the privileges and perspectives that programmers bring to their code and about the privileges and perspectives that journalists bring to their stories.

Alittle background: I’ve always liked stories. I spent six years at an art school studying creative writing. I’m not shy about the fact that I judge people who do not read fiction.

At 16, I became a member of a Shakespeare company. I joke that my favorite programming language is iambic pentameter.

At 17, I debated between conservatory and college. I chose the latter, and graduated four years later with a degree in English. Then I did what nearly every English major does: I wept, I applied to MFA programs, and I was rejected from every one.

I knew I needed a job, but the communications positions I applied for came back with rejections, too. I did something a little different. I reached out to a software development firm and I said, “I like your work and I noticed that you don’t have anybody from a non-development background on staff. Would you like one?”

Job — check.

I began to realize that what my team was doing with code required some of the same skills I’d spent my life working to develop. From my perspective, I saw the need for an ability to write clear and concise descriptions. An immaculate attention to detail. An appreciation of what it means to see a project from start to finish.

I wanted to do that, and I wanted to do it in the context of code. I found the Turing School in Denver and seven months later, I found myself navigating through a sea of eager bootcamp graduates, all applying for that elusive first junior dev position.

The Turing School of Software and Design

I wanted to find a team that valued me — a developer, a person hired to write code — not despite my background in communications but because of it.

And I also want to be clear: What I didn’t want was a kind of blended marketing/tech job. I went to Turing to become a full-time developer, yet too many technical interviews I walked into began, “Wait, but you don’t actually want to write code, do you?”

“No, you’re right. I’m just stretching my legs here at the whiteboard and not waiting for you to throw some irrelevant data structures my way, you asinine fool.”

I never said that, but I wanted to.

No, what I wanted was to walk into an interview and have at least one person on the other side of the table look at me and joke, “An English major who writes code? That’s it. We’re done. You’re hired.”

Eventually, that did happen. It just happened at a place where I’d be the only developer on staff. A place where just about all of the repositories I’d be responsible for maintaining were written in Python, a language I knew nothing about. A place in a very small state, very far from my hometown. Those three characteristics about the job terrified me but I heard what I had tried so hard to hear, and I heard it at a public radio station, which is English major gold. I took the job enthusiastically.

“A news organization in Vermont?” my friends asked. “Don’t move to Vermont. If you’re going to work in news, you have to be in a place where news actually happens.”

I ignored the suggestions, packed up my car, drove across the country, and about a month later, Senator Bernie Sanders announced his candidacy for president. It has been the single biggest news story in Vermont’s history, and for more than my entire first year on the job, I’ve had a front-row seat working in one the state’s biggest and most respected newsrooms.

I don’t say “most respected” to sound like an ass. I say it without bias, because that’s what public media does. We have no agenda. Instead, we have a firewall that separates our news department from our underwriters. A large portion of our operating budget comes from members of the community — listeners who give throughout the year and who give especially during a little event every few months called the public radio pledge drive, where non-radio hosts like me interrupt a station’s regular programming.

The newsroom is an exhilarating place to be. Stories break. News moves fast. I go to a mid-morning meeting every day where the reporters on my team throw out ideas about what they might be interested in covering, then I go write a few lines of code, add a few features, grab a lunch break, and the next thing I know, those hypothetical, work-in-progress stories have hit our website — their sources interviewed and fact checked, their audio parts tracked and mixed, their images gathered and cropped.

It can be difficult to work in a newsroom because speed is important. Of course we don’t want to be scooped. I could say the same thing, though, about working in so many other areas of tech, too. About working for a consultancy, where every hour is on a client’s dime.

So here’s a question: In news, where the stories around us determine the pace at which we work, how do we justify taking the time to write good, clean code on deadline?

On deadline, how do we remember to be impartial and fair? Especially in public media, the job is to be unbiased, and it’s an increasingly important media role to fill. Every move has to be intentional and deliberate — the stories we cover, the words we write, the tools we use. Again, there’s a valid reason for this.

In public media, the second a newsroom staffer tweets in support of or against any topic deemed too controversial, we’ve failed to do our job. The second that happens, we’ve lost credibility. Political bumper stickers are completely prohibited. A large number of journalists do not vote in primary elections, where alignment with a party becomes required public record.

Again, it’s not always easy. We are, for the most part, thoughtful human beings, and our jobs require us to think critically about the world. To ask tough questions of our lawmakers and of our community members.

Speaking strictly for myself, it’s tough. As somebody who does have a lot of opinions about the political, economic and social issues facing our world, it often feels backwards and wrong to suppress them. It often feels like a disservice. I feel disoriented and dismissive.

So here’s what I do: I try not to suppress. Instead, I try to recognize, quietly and in private. I recognize because when I’m aware of my bias, I can be aware of how it influences my perspective. I can prepare and counterbalance.

When I’m aware of my bias, I can be quick to consider all sides of a story, not just the side that seems the most persuasive to me the most quickly. I can consider which sides actually do merit attention, because I know in some cases it can be innocent and uncritical to give equal attention to all.

When I’m aware of my bias, I remember that stories might not just have two sides. Maybe there’s a right and a left, sure.

An up and a down.

But maybe there’s an upside down.

An inside out.

A filtered side.

A side that you cannot see with your eyes.

And here’s the tricky thing, right? It’s not just my bias that creeps into my features, my UX decisions, my documentation, and my code. It’s the bias of my sources, as well.

When making technical decisions, we try to trust our guts but tend instead to trust our senior developers, our tech leads, tutorials, and textbooks. It makes sense. We have to start somewhere, so we learn from the best. We learn from what’s available and accessible. As our skills develop, so too do our patterns. Our patterns turn to best practices, and our best practices turn to creed.

But there’s a question we cannot forget to ask: What are the long-term effects of a world sustained by technology that’s built largely by white, straight, cisgender men?

There’s been a lot of writing about this recently. Key among the stories is ProPublica’s Machine Bias, an investigation into the software that police departments around the United States are using to predict future criminals.

Perhaps unsurprisingly, the investigation found that:

“…the algorithm made mistakes with black and white defendants at roughly the same rate but in very different ways.”

“The formula was particularly likely to falsely flag black defendants as future criminals, wrongly labeling them this way at almost twice the rate as white defendants.”

“White defendants were mislabeled as low risk more often than black defendants.”

When we ship software like this, we fail our industry. We fail our communities. We’re failing in systemic and irrevocable ways, and we’re way past overdue to fix it.

While I was thinking about all of this and preparing to present it to an auditorium filled with software developers, I was thinking about originality. About whether my bias is truly my own or instead if it’s a collection of perspectives I’ve picked up over the years. What does it matter anyway? My biases live within me, purely mine or not.

But I found an old episode of TED Radio Hour. It’s an episode from 2014 called “What Is Original?” and Mark Ronson’s How Sampling Transformed Music is one of the first segments featured. Mark Ronson is an English musician. He’s a DJ, singer, songwriter, and record producer.

And he says, “Whether we steal or we borrow, it’s impossible. Even if you’re telling yourself you’re not stealing, subconsciously you are influenced whether you like it or not.”

Now, that doesn’t have to be a bad thing. It’s good to learn from others, and it’s good to let their good work influence our own. Good things happen with a little creative inspiration.

Ronson continues: “We live in the post-sampling era. We take the things that we love and we build on them.”

If this sounds familiar, we’re on the same page. To me, it sounds a lot like what developers do. We find projects that we love and we build on them. Our work strengthens the work of others. We stand for critique. We welcome discovery. We search for parallels.

Because we know that our work is shared and because we know that this shared work has the power to influence, we have a heightened responsibility.

In the world of news, we know it in four principles written in a Code of Ethics from the Society of Professional Journalists:

Seek Truth and Report It

Minimize Harm

Act Independently

Be Accountable and Transparent

Narrow in on that last one. What does it mean to be accountable and transparent?

Journalists should:

Explain ethical choices and processes to audiences. Encourage a civil dialogue with the public about journalistic practices, coverage and news content.

Respond quickly to questions about accuracy, clarity and fairness.

Acknowledge mistakes and correct them promptly and prominently. Explain corrections and clarifications carefully and clearly.

Expose unethical conduct in journalism, including within their organizations.

Abide by the same high standards they expect of others.

I know it’s hard enough to find Codes of Conduct at tech events, and so it feels foolish to ask for a Code of Ethics for our entire professional industry. I don’t even know if that would be a constructive path to pursue, but I also can’t help but wonder how many more complexities we’d be able to solve — how many more bright minds we’d draw to software — if only a few standards like these existed.

I was reading through SRCCON submissions earlier this summer. If you don’t know SRCCON, you should. It’s a conference that brings together developers, designers, and data analysts who work in newsrooms.

One of the sessions that’s going to be discussed in a matter of weeks here at SRCCON this year is a session called Can We Pair Program The News?

One, that’s tremendous, because sometimes I think we should pair in everything we do. Two, it made me think about all of the other snippets of a developer’s process that I so desperately wish we could bring to the news.

Can We Pair Program The News?

Different teams from different newsrooms pairing up. Different minds from different regions and different cities bringing their own perspectives to a codebase in various newsroom collaboratives.

The NPR member station system is designed perfectly for this, and in fact NPR Visuals makes a lot of their work public, easy to fork and reformat. I’m the only developer in the building at Vermont Public Radio, but I spend a large amount of my time talking with developers in other newsrooms. My job would be exceptionally more difficult without this collaboration.

Can We Stack Overflow The News?

Or maybe that’s just Wikipedia? To what extent will crowdsourcing — to what extent should crowdsourcing — become a part of a journalist’s process? At Vermont Public Radio, we’re working with Hearken in a podcast that launches this summer. It’s very exciting. It’s called Brave Little State, and the premise is that we’re inviting people from all corners of the state to ask their questions about its history, its community, its quirks, and its future.

The public will use Hearken’s platform embedded in our site to submit questions and then vote on which they’d like answered. For each winning question, we will send a team of reporters to work with the original question asker to find an answer and to record an episode. Be Brave. Ask Questions. It’s going to be good. It’s going to be truly public public media.

Credit: Aaron Shrewsbury

Can We Request The News? (Get It?)

At a Knight-Mozilla OpenNews code convening a few months ago, more than a dozen developers who all work in newsrooms got together in a shared a workspace for two days. Projects were all centered around bots and automation.

I worked with Ariana Giorgi, a developer at the Dallas Morning News. In two days, we built a command line tool that uses the Twitter API to find geolocated and keyword-specific on-the-ground tweets during a breaking news event, and then it saves those top results from Twitter to a reporter’s Google Drive for source information later on down the road. Who was where when? What happened where when? Who saw what, and when?

In a breaking news event, a reporter’s job is to find the most reliable information as quickly as possible. Technology is never going to find all the right answers, but it can help us to find a good spot in the ground to start digging.

Can We TDD The News?

Think about this for a second. I think this one excites me more than anything else. Why doesn’t journalism have more test suite tools?

What if reporters could run their stories through a program that confirms consistency of spelling, of punctuation, of journalistic style. Unit test for easy finds. There’s a Hemingway Editor app that does something similar, which is so silly to me. (Total aside in case anyone is ever interested in a discussion: I have a few thoughts about Hemingway’s writing style.)

Test, too, for diversity of sources. Keep track over the days and weeks and months to see what kinds of people are more likely than others to be turned to as experts in a field.

Of course, it would be a lot more difficult to actually TDD the news, right? To let the tests drive the development. To let the tests drive the reporting. TDR?

But say, a reporter arrives at a general story idea with a set of assumptions.

Original Story Idea
Assumption # 1
Assumption # 2

She takes this collection of information and — use your suspended disbelief with me here — she throws it into a database and spins up a virtual environment.

A Journalist’s Sandbox — Creation # 1

The tool helps her to consider the connections she might not have thought to make. It supports her as she drafts her story.

A Journalist’s Sandbox — Creation # 2

I have no idea what this tool would look like, but I want to build it.

I want to build it because what it might mean is that when a story gets to an editor’s desk, it’s already been challenged. I know there’s a big need for more editors in news and I’m not suggesting a tool that would enable us to cope with an elimination of them completely. That’s absurd. I’m also not suggesting robot editors. That’s cool but even more absurd.

A test-driven approach would not replace the role, nor should it. Instead, it would make an editor’s role more significant. More thoughtful. The tougher the challenge a story must face, the more depth a story might be able to provide.

I find myself nestled between two joint industries that are each changing so rapidly, and I find comfort in the intersections. I look to big open source releases with an eye for how the journalism community might come together to find and tell stories.

In each industry, I see a need for people who are unafraid to challenge bias, privilege, and assumptions — those both of others and of themselves. People who can be comfortable working with sensitive data and tight time constraints. People who find fulfillment building and providing products of service. In each industry, I see a need for exceptional communication.

And I also see this: A need for people who understand that the work that they do has the potential to influence the lives of so many others, in good ways or not.

The more we understand how our privileges burrow into our applications, the better we’ll be able to prepare. The better we’ll be able to respond.

The better our products will be.

--

--

Sara Simon

phd student • former newsroom technologist • former @covid19tracking • she/her