Naming changes thinking

A ticket was handed over to me before a colleague went on holiday.

At first, it looked straightforward.

The ticket title described the change, but it never mentioned the feature it belonged to. During the handover I received one explanation of the problem. Later, after discussing it with our Product Owner, I realised we were talking about something different.

Neither explanation was wrong.

Neither gave me enough context to understand where the problem actually lived.

The turning point came from another colleague who knew that area of the product well.

Instead of explaining the solution, they pointed me towards the right part of the system.

Only then did everything begin to make sense.

Once I understood where to look, reading the code became surprisingly easy. The implementation had never been the difficult part.

Finding the correct context was.

That experience changed the way I think about naming.

We often treat names as identifiers. They help us distinguish one ticket, field or component from another.

Their more important role is providing orientation.

Every name quietly answers a question before we have even started reading.

What is this about?

Where does it belong?

Which part of the system should I be thinking about?

When those answers are unclear, people do not simply misunderstand the words.

They begin solving the wrong problem.

A more descriptive ticket title would probably have prevented the misunderstanding from the beginning. Simply including the feature name would have pointed the investigation towards the right context instead of leaving every reader to reconstruct it themselves.

Good names do not reduce complexity.

They reduce the distance between a question and the context required to answer it.

That is why naming is not a cosmetic activity.

It is part of information architecture.

Before people can solve a problem, they first need to know where the problem belongs.