Weird naming vibes. Are there any good ones?

A parallel team at work names all their services after types of sausage. One called "bratwurst", the following "curry sausage", and so on. In an incident, people from different teams sit together, and one shouts: "The bratwurst is down". Sadly, nobody–apart from the team members–can deduce the affected area from the given context.

I get similar vibes when I try to book a room in the office. I want to book the big meeting room. What was the name again? Let's take a little office walk.

Our meeting room naming pattern has a noble gesture: The base for each room name is a woman's name. These women achieved significant milestones in software development. It is a tribute to them and their contributions to the field.

Don't get me wrong, embedding these gestures into everyday life is admirable. But after years of working in the office (yes, I'm still working on-site), I can't remember a single room's name.

I can't deduce the name from my inner image #

My problem in a nutshell: I know the office layout and see an image of the room in my head. But I need to determine which room to select in the booking tool. The listed names are not associated with the office layout or rooms themselves.

Mentioning this issue led to an interesting discussion. It had some great insights I'll share in this post.

How can we do better? #

Use context-based names #

Good names combine your knowledge and the function:

your knowledge + functionality = name

Converting it to our room naming issue:
building layout + picture of the meeting room = room's name

We can apply the same structure to technical services: Assume an entertainment app with a personalised music integration from a third party. A service translates a local access token into a third-party access token. Both information lead to the service name: <third-party>-token-service

This should even work another way:

your knowledge + name = functionality

Again applied:
building layout + room's name = idea for the kind of room

And to our entertainment app with personalised music integration case: The name <third-party>-token-service suggests that the service provides third-party tokens. With personalisation in mind, we need some user identification. Therefore, it might receive a local access token.

This example shows that you can jump through the entire system landscape with only a baseline of knowledge. It vastly improves productivity.

To nail it, you have to figure out what the baseline knowledge for your system is. Reality shows it is complex, and you might need to adapt it regularly. I often come across names I need help deciphering. Sometimes, I realise that there's some knowledge missing on my side.

Coming back to our room naming case: What if the name pattern has nothing to do with the current layout or kind of room? You can extend the context. Make the room's name the central design focus. You could hang a big painting in the room so noticeable that people will remember it. Unfortunately, our rooms have already been designed and built. So, we need another option. And there is one.

Establish a common name pattern. #

You can still fall back to a familiar name pattern when context-based names don't work.
Every day, you come by some obvious ones. These are basic things like left and right.
Others are the location or floor level. Most buildings have a number for each floor instead of a name. It starts with the ground floor zero, followed by floors one, two, etc.

These patterns are so embedded into our everyday lives that you can safely rely on them. Like enterprises that (ab)use traffic lights for a quick project health check.

In our case: Location-based numbers helped #

Coming back to my initial room booking issue: How did we resolve our problem?
We extended the name pattern using the location on the same floor. Each room receives a number based on the distance of the entrance. When you enter the office, you start at zero and can walk to room seven.
Every time I want to book a room, I walk through the office in my head and count the rooms. Now we have a sorted meeting room list, and I can quickly spot the room I'm interested in.

In the end, we have two name patterns for different use cases:

• People from other locations book a room. They choose it based on its description and remember the name to find it later. They can learn about the room's name and history at the location.
• Everyone at the office who wants to get the job done quickly can use the location-based numbers. It only interrupts their current task as little as necessary.

Conclusion #

As an engineer, you know, naming things is hard. There are no perfect names. But some patterns work. You could deduce names based on the context and function or a familiar pattern.

Naming is and remains a fine line. You nail the name and boost productivity. Otherwise, it leads to more complexity.

Embedding noble gestures–like honouring past achievements–deeper into everyday life is admirable. To achieve the remembering part, create deeper associations between the past and present. For example, when naming meeting rooms, you can use related visuals inside the room. These visuals help to associate the room with the past and its name.