It’s a common saying among developers that they spend more time naming variables than they do developing. Naming variables isn’t that hard, but it’s actually quite difficult and important.
It happened the other day at a company meeting. We had an internal service called Alert Manager, and the idea of adding feature to that service came up. The idea was accepted, and as the discussion continued, the scope of the features we wanted to add broadened. At some point, it was decided to separate this feature from Alert Manager and create a separate service, as it was a broader concept that did not belong in Alert Manager, and the discussion continued. However, since we hadn’t named the service, we started referring to the new service as Alert Manager for convenience, which caused confusion for me and others. People started to get confused about whether the features we were discussing should be in the original Alert Manager or in the new service, especially people who hadn’t been part of the discussion from the beginning. To prevent further confusion, I suggested that we stop the discussion and start with a working title, and the name Admin Portal was chosen. Only after the new name was chosen did the confusion diminish. We even started to talk more specifically about the new features in Admin Portal. It seemed to be easier for everyone to flesh out a service called Admin Portal than to flesh out an unidentified service in their heads. Suddenly, I was reminded of the importance of naming.
Everything that needs to be distinguished from other things has a name. Cars, buildings, streetlights, streets, paintings, mouse, keyboards, and so on. And it’s easy to communicate with others because the name is part of an agreement that we’ve all agreed to call the object. Without a name, it’s easy to create miscommunication when we call something “a vehicle with wheels that can travel on a road”. Someone might think of a motorcycle, someone might think of roller skates, someone might think of a handcart, and so on. The moment you start calling it a “car”, you minimize that misunderstanding. Everyone has the same object in their head and can talk about it.
Moreover, the right name becomes even more important for the people who have to build that “something”. Without a name like “car,” it’s hard for an organization that needs to build a car to flesh it out. But once we name the thing we need to build a “car”, it becomes clearer what we need to build. We all have the same idea in our heads: it has to have rear-view and side mirrors, tires made of rubber, a door for people to get in and out of, and a glass window to see out the front.
But at the same time, naming an object narrows it down. A team that decides to build a “car” will probably naturally care more about the engine and fuel efficiency. We won’t talk about what’s inside the car. But the idea of breaking through the limitations of the name “car” and putting a kitchen, toilet, and bed in it might be just what they need. (And the object will get a new name: “camper”.) But breaking through the limitations of the name “car” is not easy.
I realized that the moment you name an object, it closes the space for imagination. So the issue of naming became more important to me. If you name someone “college senior” who is in their 20s and in their fourth year of college, it seems like he should be preparing to enter the workforce. But if you call him “youth,” he could be a rapper, a businessman, or something else. Of course, he could also be an jobless person.
While naming something makes it more specific, it also has the effect of defining its limits. In the same way, developers who write code for a paycheck seem to be a bit different from those who define themselves as “salaried workers” than those who define themselves as “developers” or “software engineers”. So I think it takes a lot of thought to come up with a name, and even after the name is chosen, we should try to keep creating space for possibilities and not be limited by the limitations of the name.