Assumptions and Expectations
A few weeks ago, RadioLab aired an episode called NULL. It was supremely entertaining and very relevant. It highlights the “edge” cases, the outliers, the deviants from the middle of the bell curve. Like people with the last name NULL.
Most people in this world don’t have a last name that happens to also be a foundational word in the code that runs through literally everything digital in our lives. But when a person named Emily Null tries to enter their last name into a website form, online application, financial services (their banks), or almost anything online, you run a pretty high risk of breaking the expectations of the code. It’s a really cool paradox - the word NULL means “empty” in a database, so if you try to write the word NULL into a field, the database will get super confused - IS there something here, or is it empty? So the code expects to receive a last name that is not also this foundational term of “NULL”.
Expectations play such a big part in our relationships - whether that is between two humans, between humans and computers, or between two computers. When we do not share the same expectations, lots of things can go haywire. When this happens between a human and a computer, it can be super frustrating because there is a special language and approach for having a dialogue with a computer (troubleshooting and investigating) to see if the issue is that something is broken or if it was a case of mis-aligned expectations (or something else altogether). Without some knowledge of this language and approach, it is easy for the human in the relationship to want to break-up with their computer. It can be a major roadblock on the data & tech learning journey.
Later in the episode, RadioLab reported on an excellent resource about expectations and assumptions around names and databases - Patrick McKenzie’s essay “Falsehoods Programmers Believe About Names”. As a person with a hyphenated last name, I make this list. I love the untrue myths such as :
People’s names fit within a certain defined amount of space.
People’s names are assigned at birth.
People’s names are not written in ALL CAPS.
People have names.
It might be cheeky in some places, but what this list is really saying is that programmers write assumptions and expectations into their code at some of these most basic levels. In case anyone was looking for an entryway to understanding just how deeply and with how much complexity bias of all kinds (racism, agism, ableism, etc) make their way into the fabric of the code that runs the technology in our lives, here it is.
What can we do about it?
We can find the malleable places, the places for flexibility, the systems that acknowledge where there is rigidity and what the workarounds may be. For a corporate entity, changing their code to accommodate a few people with the last name “NULL” makes no sense. In fact, they suggest that the person change their name to accommodate the code. But in non-profit organizations, even if we get really big and scale our missions, we have the honor and responsibility to have way more care for the humans in our human-to-computer relationships. We actually can change our computer systems or at least our processes to honor the people who we serve. If it takes a little extra time, it can’t be part of our automations, or it requires some extra work to be flexible, then BRING. IT. ON. We actually have amazing and spectacular human beings to do that work, while the computers do some of the other stuff.
