I can’t tell you how many times, even just recently, I’ve seen communication seriously hampered by confusion over the names people use for things.
For example, I might say “I like the design of this application”. That could mean, depending on your perspective (or even just your mood), a) the graphic design, b) the user interface design, c) the software design, and probably x other things I’m not thinking of. I suggested to a project manager once that we needed to spend more time on design, meaning our application’s software design. He walked away thinking I meant the UI design and, long story short, a bunch of people put a bunch of effort into a UI design review nobody was asking for.
Another example: I was on a project recently where something called a “view” was a part of the domain. Our application got things called views from another system and did some stuff with them. But our application already had something called a view, because it was built with a Model-View-Controller structure. So half the time when someone mentioned a view on that project, I had to do a little mental double take to make sure I was sure which kind of view was being discussed. (That domain also included “values”. Similar problem. Oy.)
On another application, the legacy code used one term to refer to a domain concept, but all the people involved when I worked on the team used a totally different term. Needless to say, the first time I went in to make a change to that code, I was very confused.
And, of course, there’s a ton of material out there on the importance of names within your code. The more clearly and consistently you name your classes, modules, functions, variables, and whatnot, the better the next nerd who comes along (or even future you!) will understand what they’re for. Code is a tool for communicating with humans as much as it is a tool for communicating with compilers and interpreters. That’s a big part of why we build abstractions.
Anyway, all these situations can be avoided with a little care. Pay attention to the names you use for things, in conversation and in code. Always think about whom you’re communicating with and whether you’re being clear.
