The Power of Names
Using names to empower design and write clean code
It is often joked that naming is the hardest problem in programming. And there’s definitely some truth to that, naming is hard. But that’s not what this post is about. I want to turn this mindset upside down and look at some of the things that naming can do for us.
When we give something a name it changes the way we think. This can not only make code more readable, it can make programming much easier.
If an API is named well enough no one ever has to look it up.
Array.sort
Chunking
Let’s start with an example.
const today = new Date();
if(person.dob > subYears(today, 18)) {
...
}Thanks to dateFns this is pretty readable. We want to check if the person is over 18. But still your brain has to take a tick or two to interpret subYears(today, 18). And annoyingly your brain needs to do this calculation every time you look at this code. Let’s try to help our brains out.
const today = new Date();
const minDob = subYears(today, 18);if(person.dob > minDob) {
...
}
By adding a variable we have given subYears(today, 18) a name, minDob. This makes it much easier to think and reason about. Our check is now very easy to understand. The details of date manipulation and our minimum age are abstracted away.
In the world of psychology this is called chunking. We have taken a bunch of concepts and turned them into one concept by giving it a name.
Framing a problem
As discussed in the previous example, giving something a name can change how we think about things. This affects the way we solve problems. The stories we tell affect how we approach a problem.
Chess would likely feel like a different game if it were about Klingons vs Vulcans.
How we frame a problem affects how we solve it as well as how we communicate about it.
Let’s take a hard problem like building a self driving a car (a topic I have no expertise in).
At first it seems like an almost impossible problem, but let’s try to break it apart.
Maybe we have, I don’t know, a roboticDriver, a decisionMakerand a sensoryProcessor.
All we have done is introduced three names but it instantly changes the way we think about the problem.
What is responsible for turning the car: the roboticDriver
What is responsible for stoping at a stop sign: the decisionMaker
What is responsible for seeing the light change: the sensoryProcessor
Although still hard, this problem seems a bit more manageable. By creating named sub-problems we have reduced the complexity our brains have to sort through. Now, instead of thinking about the whole problem, we can think about the roboticDriver.
But there are other ways we could frame building a self driving car. What if instead we went with, automatedCar, centralController, visionSystem , lidarSystem
This completely changes the way we think about the problem. Now we have a more centralized design where everything flows into the centralController.
Design
It is likely at this point that you feel like, hey wait. You are just designing and calling it naming.
And to a degree, yes. Naming is a critical part of design but they are not entirely the same. We could of course end up with the same design with very different names.
Often when we go to design a system we divide a problem into concepts and then struggle to communicate those concepts, waiting until the end to give it a name.
But what if we embraced the power of names and used them to drive the design process. Start with the name, giving you the power to communicate right away.
“Our self driving car system will have a roboticDriver”
“What does the roboticDriver do?”
“Great question…”
Conclusion
We often think about naming as a burden and it can be. But names also give us super powers. It lets us change the way people think. It empowers our brains to do more!
When designing try starting with names and building out the concepts afterwards. Use names to make your code more readable. Maybe the difference between Superman and Clark Kent is less about the glasses and more about the name.
Own your names before they own you!
