On Naming Things - Insights
Similar to good writing, good names improve understanding of the context.
I named many things while using programming languages and also had opportunities to name new initiatives and processes at work. In this article I present my insights (technical knowledge is not required). I believe that these rules apply to most naming cases - it doesn't matter if you are naming layers in a graphic tool or files on your computer.
Naming something forces us to consider different perspectives. If somebody scratches their head encountering a name we have created, it is an opportunity to reflect on how we could have named it better.
Similar to good writing, good names improve understanding of the context.
Names in Programming
There are only two hard things in computer science: cache invalidation and naming things - Phil Karlton1
Thanks to the above quote, popular among engineers, naming has gained importance in computer science.
The foundation for programming is mathematics, where using variables like x, y, z or a, b, c is nothing surprising. Then, programming languages expanded upon maths but with a need to change the code later and assure that others will understand what we have created. In the beginning when both storage space and screen size were limited, short names were the only option. Thankfully, this is no longer the case with the current state of the programming toolbox. Developers can now use long names that communicate meaning and context that help with understanding of the code. It’s not just variable “x”, but can be “distance_to_finish_in_meters”.
What other domains can learn from engineers naming things in programming languages is a need to take different perspectives. To make sure that code is understood by others, in most technical organisations, a review from fellow engineers (sometimes even more than one) is required. At this stage the difficult-to-understand names are being noticed and changed thanks to code reviews.
Names in Organisations
In organisations it is important to make sure that names are understood by everyone involved.
Ask people from different groups if they understand what is represented by the name. Company-wide names should not be understood by just one group. Each time I felt that a name was misaligned it was because its creator had not checked it with different groups.
As with the first step for Preparation, in a framework presented in On Writing at Work: “The more we know about our audience the better, because it helps us avoid things that they will not understand.”
Just as with managing expectations, names should not promise anything. For example, if the process is called “Yearly Salary Increase” it implies that everyone who is involved may receive a salary bump, and if you do not plan on giving bumps to everyone then it is a misleading name.
Summary
If you need a few minutes to explain a name to someone, it is not a good name.
I think of writing as the “transfer of thoughts” between two brains, and while writing we use a lot of names which need to be well thought out to help prevent confusion.
For me, naming things is the fun but challenging part of work.
Thanks for reading!
PS Just a thought: In our human-centred world, we rely heavily on names to operate. It is so human to name things that do not have names, that is one of the very first things we do when discovering or creating.
Martin Fowler curated some fascinating responses to this quote: https://martinfowler.com/bliki/TwoHardThings.html