Naming changes thinking
Names do more than identify things. They decide where thinking begins.
A colleague handed me a ticket before going on leave. Its title described the requested change, but not the feature it belonged to.
The handover suggested one interpretation. A later conversation with the Product Owner suggested another. Neither was unreasonable; both lacked the context needed to locate the problem.
A third colleague changed the investigation with one sentence. They named the relevant part of the product.
Once I knew where to look, the code was easy to read. The implementation had never been the main difficulty. Orientation was.
Names do more than distinguish tickets, fields and components. They quietly answer three questions: what is this about, where does it belong, and which context matters?
When a name omits those answers, readers must reconstruct them. Worse, they may begin solving a plausible problem in the wrong part of the system.
Adding the feature name to the ticket would not have simplified the work. It would have shortened the distance between the question and the evidence needed to answer it.
That is why naming is part of information architecture. Before a team can reason well, it needs to know where the reasoning belongs.