Welcome to Still Computing #6!

When we assembled this issue a few weeks ago, it had a different letter from the editors. This week, we’re grieving the loss of George Floyd, Tony McDade, Breonna Taylor, and all the Black people murdered by police as people across the United States mobilize to resist racist state violence. This violence runs deep in American society — in our laws, schools, hospitals, and beyond — and has for centuries. We are heartened by the efforts of everyone who is doing the difficult, long term work to make this country a fairer, better place.

We see hope in our community, too. Many Recursers have long worked against police violence and the carceral state. They have exposed racial bias in artificial intelligence, written software to help organizers communicate securely, and are currently organizing trainings and Twitter accounts for people to keep up with police radio scanners. We believe that programmers have a responsibility to build tools that — at minimum — do not reproduce bias or cause harm. We all need to think critically, together, about how our work as technologists impacts the world.

We discussed delaying this newsletter. As you can see, we decided to send it. That’s because we think Sarah, Christine, and Julia all have important things to say about dealing with uncertainty, about recognizing what the bugs that exist in systems have to teach you, and about finding an entry point into learning something new, even when it’s difficult. Those pieces are relevant now, in this time of incredible uncertainty, when there is a lot of difficult work to do.

We hope that you all are safe and well, and we hope that you enjoy reading this issue, whether it’s a welcome break from your work advocating for better systems for all of us, or whether you wait to read this until you have the energy to do so.

—Rachel, Mai, Nick, and James

P.S. If you want to follow programmers, researchers, and data scientists working to expose and combat racism in computing, we’ve learned a lot (and continue to learn a lot!) from: @timnitGebru, @Combsthepoet, @jovialjoy, @red_adebe, @black_in_ai, and @osuzuwa.

Usually, when we computer people turn our minds to errors it is with an undercurrent — sometimes an overcurrent — of horror. We recall the terrible mistakes we’ve made: the servers that went down and never came back up, the deployments that resulted in a blank homepage and an accusing error in the console, the time we deleted our boss’s account or reset everyone’s password to our own.

But I love errors.

Errors can be hilarious. Consider the case of Nuclear Gandhi! In the first Civilization game, for some reason, towards the end of the game, Gandhi would suddenly become incredibly aggressive and threaten to nuke everyone — which is very unlike him. It turned out that aggressiveness was represented with an unsigned byte. When Gandhi’s was set to 1 and the player took an action, like adopting democracy, that would reduce aggressiveness even further, the value wrapped around to 255: MAXIMUM AGGRESSION. Players liked this bug so much that new versions of the game still have Nuclear Gandhi.

Errors can also make us inventive. In Wing Commander, the game threw an error on completion and no one could figure out why. But they had to ship. So they just changed the error message to a message of congratulations! Wontfix; close ticket.

Even more, embracing errors is about embracing all of the great parts of our humanity. In her book, Being Wrong, Kathryn Schulz contrasts ancient understandings of erring with more modern ones. In the former, beloved by philosophical hard hitters like Plato and Thomas Aquinas, errors are the product of a gap between the true world and the flawed human mind as the latter attempts to interpret the former.

This is a view of wrongness that underlies a lot of traditional programming error handling: using types and other types of introspection during specification and compilation to find gaps in understanding so they can be rectified before being sent out into the world. It is a perspective that gives us a yearning for correctness, for perfection.

There is another, maybe more optimistic, view of erring. This more modern view, originating in the Enlightenment, suggests that though this gap is the result of imperfect perception, it can be faced and overcome, as we asymptotically move towards truth. In this way, errors can be an important epistemological tool. By seeing where my understanding fails, I can see where I can be improved. I can embrace the humility of learning to say I don’t know and through this learn to better interpret the universe.

In this view, we still need the same guardrails for errors, but interactive programming tools from REPLs to log-based programming (the poor woman’s REPL) grow in strength. As we err, we are able to encounter where the map and the territory diverge and engage in iterative discovery. We work side-by-side with the machine.

Yet it’s possible that seeing the world perfectly as it is might not even be the right goal. As Schulz notes,

“seeing the world as it is not” is pretty much the definition of erring — but it is also the essence of imagination, invention, and hope.

That is, the gap between what we expect and what is can be a fruitful space. Maybe we should not worry about closing it down but about working with it. This could mean accepting imperfection as opposed to trying to stop it; making our programs more resilient rather than seeking to make them error free.

In the original map-reduce paper, Google engineers mention that if a certain processing iteration failed a number of times, it was set aside and the process proceeded. In your code, it might look like a function returning a data structure that does not conform to the expected data shape instead of throwing a ERRWRONGSHAPE.

Is it important that all data flowing through a program perfectly meet a pre-ordained shape? This question is vital not just conceptually but socially, as algorithmic decision-making systems unfurl their tendrils across the world, like the dark ending of Little Shop of Horrors.

The data that makes these programs possible is more and more often sourced from surveillance systems, both camera surveillance and data mining. As we strive to perfect these systems, we strive to “perfect” surveillance. The yearning for perfection is revealed as a yearning for controllability. Another way to say this is: You can’t have a surveillance state if you admit that errors are inevitable.

Once we accept the errorability of computing endeavors, the case for these inherently unjust systems unravels. The key idea animating the adoption of machine learning systems is the belief that they are able to see things humans cannot and that because of this, they can be fairer, more insightful, and more objective than flawed humans. If they cannot — and they can’t — their use becomes indefensible. When we embrace them, then, errors become our allies in our determination not to live completely machine-readable lives.

Beyond better understanding our spheres, beyond backing off dark uses for technology, studying error rectification is a potent site for sociological understanding. When computer historian Mar Hicks talks about COBOL and the robustness that means it is still powering unemployment systems years after the maintainers were laid off, my ears prick up at the suggestion that COBOL designers used human language instead of formulas as a model because they wanted to reduce errors. Why do we, as humans, expect sentence-like structures to reduce error overall? Do all humans think this? Does it work? How does this error reduction compare across COBOL and, say, Ruby?

But to start answering these questions, we need to embrace errors — to acknowledge them, to engage them, to love them. In computing, that means accepting them and observing them, rather than trying to stamp them out. Even when that can be scary.

Schulz writes,

We want to turn away from error because it reminds us of our existential despair — that we are separate, from truth, from one another — but also the only true way to engage and to create and imagine is to risk error.

So before you react to a mistake or error by trying to come up with a plan to be sure it never happens again, consider asking instead: How could I have written this so that we could identify and understand the gap without the system itself failing? You’ll make the world a little bit better each time.

Concepts in this essay are elaborated on in Kablooie, a talk I did in 2018. If this article was interesting to you, I recommend checking it out.