The Name Game

Finding the words to describe abstract processes

A surprising amount of a software engineer’s time and energy is spent on the simple act of naming things. In the most general terms, an engineer’s job is to create systems to store and manipulate information. Each piece of information, which we call a variable, needs a name.

So like Adam in a garden of ones and zeros we bestow names upon files and database tables and validation functions and id numbers and fragments of text and server instances and software packages and all manner of things the users of iOS or Candy Crush or pets.com have the luxury not to care about.  

Some names float to the surface fully formed, requiring no consideration whatsoever. Let’s imagine a variable that stores the id numbers for a list of products. “ProductIds” should do the trick. What if our variable only stores ids for products that are in stock? “InStockProductIds”. It’s easy enough to name the variable after the thing it represents.

Where naming becomes difficult is when dealing with processes or structures that have no concrete real world counterpart. There’s a dearth of verbs in popular vocabulary that describe the manipulation of data. Copy, update and merge become tired quickly as you try to make subtle distinctions between processes that are similar but not identical. For example, in an e-commerce app you might have product update processes that run before, during, and after a transaction. You might have a separate update process that runs when new data is provided by the vendor, and yet another for when employees go in and tweak product data manually.

Names start getting longer and longer, or you find a way to get creative. One of my co-workers came up with the term “bake” to describe a particular process. The function had nothing to do with cookies or pies or full puff, but “bake” wasn’t a bad metaphor for what the program did; data was being “baked into” a larger structure. 

Metaphors abound in function names: zip, fold, clean, promise, to name a few that appear in popular libraries. Clever, precise metaphors can make your code intuitive  for another programmer to understand and contribute to. Poor metaphors have the opposite effect, making the code harder to build on and debug. In the worst case, a poor metaphor not only fails to capture the phenomenon it attempts to describe, but also exposes the biases and blind spots of the programmer (see how long it took for engineers to reject “master/slave” terminology, which was only removed from the Python programming language in 2018).

Of course it’s true that software engineers typically aren’t able to exercise the creative freedom of, say Bon Iver naming tracks on 22, A Million. Organizations and engineering teams establish norms and patterns to take some of the cognitive load out of naming things. Teams establish a common language of sorts to describe abstract concepts and processes.  This doesn’t mean naming becomes an automatic process; engineers are continually adapting and extending the system as the application grows in complexity.

There’s a common perception that math skills are the most important prerequisite for a career as a programmer. Sure, quantitative skills are useful -- but wherever did we get the idea that computer programmers didn’t need to be good with words?