When a bridge is more than just a bridge
A few years ago, I came across an article about how the use of grammatical gender shapes a speaker’s perception of things. It used the word bridge to illustrate its point; in German, the grammatical gender of the word “bridge” is feminine, and in Spanish, it’s masculine. Participants in a study were asked to describe bridges with adjectives. The German participants used words like “elegant”, “fragile”, and “slender”, while the Spanish participants used words like “big”, “sturdy”, and “dangerous”. In each case, participants were looking at the same object, but the cognitive constraints placed on them by their own languages meant that they described the same object in very different ways.
Naming things is hard because languages are hard. Languages and words only point to objects—they are not the objects or concepts in and of themselves—but words shape how we perceive and interact with an object. Consider the words we use to describe words themselves depending on the context: “charged”, “offensive”, “neutral”, “confusing”, “idiomatic”, “informal”. Language evolves, and with it, so does our perception of both a word and its usage. Words, then, are more than just labels for objects and concepts; they also imbue assumptions and judgments onto the object and concept in question.
But this isn’t a blog post about linguistics, exactly; it’s about naming things. Technologists have to label things all the time, and often on the fly. We’ve created placeholder names for everything from the ubiquitous “foo bar”, the placeholder name for variables, to “lorem ipsum”, the default dummy text designers encounter all the time. We’ve named advanced concepts like “serverless” which...people have opinions about. (“The first thing to know about serverless is it runs on servers…”) And we’ve also used charged, sensitive words like “master/slave” to describe primary and secondary nodes, or “death march” to describe those projects that continue with no end in sight. We name variables, classes, models, and schema in code, we name the categories in our site navigation, we name the buttons in our applications, and we name the techniques, frameworks, and we even name the relationships between these things.
We tend toward "name now, change...never"
What often happens is we'll give something a name and call it a placeholder (usually when we’re just at the point of having wrapped our head around the thing and understood it enough to move onto the next step). But instead of updating the placeholder as the scope changes, or with time, the placeholder name becomes the name, leading us to a point where it cannot be easily changed without affecting other objects around it. (This is how the reggaeton artist J. Balvin ended up with a song tragically named “Ginza” after he posted a snippet of it to Instagram with his then-favored filter, called ginza.)
I deal with this problem a lot at work. My team manages a huge database with a large number of relational tables. When the database was much smaller and we had way fewer tables than we do now, the labels we used for specific categories within a table and even across tables seemed straightforward; their definitions made sense to us, labels within categories more or less had the same parent-child relationship to the parent category, and any problematic labels or categories could be worked around. But as the database grew, the names of things, hierarchical structures, and ontologies (in other words, the relationships between these objects) became a problem for everyone. Words that once seemed self-evident were not defined in the same way by everyone who encountered them, meaning that data was often not classified properly and wasn’t always accurate. Upon chatting with colleagues about problems with data classification, it became very clear that everyone’s understanding of what a particular label or category meant was different. And we (the builders of this database) hadn’t taken the time to define these terms and make those definitions available; even among ourselves, the tagging we used wasn't consistent.
Having to re-do the information architecture of a database is...daunting. It involves creating new labels, removing old ones, merging others, moving certain labels into new categories, defining these categories and their relationships and more, with each action needing to apply equally to both historical data and new data. Changes affecting the new structure must also change for all data retroactively in order for our data to remain accurate. "Names", it turns out, have to be updated and actively maintained much like any piece of software. Scopes change, new objects are introduced, more data comes in, and these changes likely break the existing structures we had in place; they challenge our naming conventions because our naming conventions no longer apply to most of what we have. I’m not a developer, but I imagine this to be true with code. I wonder: is it ever the case that a developer has assigned a name to a local variable only to find, later down the line, that that name needs to be assigned to a global class instead? That’s how I imagine it.
"Names", it turns out, have to be updated and actively maintained much like any piece of software.
The business of naming things
One of the classes I took during my master's program was called “Knowledge Organization Structures”, which is a course students in the library sciences are most familiar with. It’s the type of class I believe every technologist should take, because it concerns itself with how we label objects, how we classify them, and how they relate to each other (among other things); it turns out that building out structures that connect bits of information in ways that are coherent, findable, and discoverable is really, really difficult. It was the course that first challenged me to think about labels.
Think of huge websites, like university websites or library websites—behemoths with thousands of pages of information—all of which contain content that must be cataloged, categorized, classified, and searchable. Users need to be able to find these pages and know where they are within the labyrinthine site; they need to be able to easily navigate from one section to another. If they land on a page that’s seven levels deep, they need to see exactly where they are and how many degrees they are away from the level above. All of these huge sites started off as much smaller sites; with time, they grew, and they likely outgrew their original site navigation. New categories probably got added onto the existing navigation, and the site’s usability may have suffered as a result; it became harder and harder to find things, and it became harder to keep track of the content that was already there. To adapt to this changing reality, new labels, categories, and hierarchical structures had to be created to accommodate all of the content on these sites, including the ones that were added well after it was created.
The art of naming variables and other things
So how do we get better at naming things? The first step is to develop an appreciation and gratitude for language because language is the way we communicate with—and about—the world around us. Words are not arbitrary, and I mean this in a holistic sense. We want to make ourselves understood, and taking care to choose the words we use is how we show respect for what we’re trying to convey (or information) and also for our listener (or the user). Read a lot, and observe the words others use for similar things.
Then, there’s understanding both the object or concept in question and identifying multiple words that could potentially be a fit as a label. Ask people which of these would they choose and why. You’ll learn a lot about people’s perceptions and thought processes, and how they classify information. (I'm a part of a Slack group with other content strategists and even we ask for feedback on potential labels.)
Languages change, new objects are introduced into our data sets that don’t easily fit into our existing schema, and new concepts emerge that we don’t have a preexisting mental model for (but we need to create one on the fly). Names and labels are a lot more dynamic than they appear. And we don’t always agree on their exact meaning.
To give something a label is to acknowledge an object’s existence, but also to acknowledge that the label will affect our perception of said object. It’s also an admission of the fact that, inevitably, a better label for it may come along down the line.
Like this post? Purchase The Developer's Guide to Content Creation for more content-related tips and exercises.