Being Bad With Names

I’m bad with names. Sometimes, when somebody tells me his name, I catch myself having forgotten about it literally in the next sentence. I’ve tried some techniques to prevent this from happening—such as immediately repeating the name several times in my head or using phrases like “Nice to meet you, NAME” to repeat them out loud. These help, but I still find it difficult.

I’ve come to realize that asking again for a name is usually not a problem. On the contrary, since apparently at least 90% of humanity are worse than average when it comes to remembering names, asking again is often a welcome chance to be asked again as well. It may be a charming way to break the ice.

There are, however, situations where names are crucial. Like in a job interview. I wouldn’t want to forget the interviewers’ names. Luckily, in such situations, I can usually just write the name down on my notebook. Something that would be a little weird to do at a party.

Another context where I consider names crucial is in code. While people’s names are mostly arbitrary identifiers useful to refer to or address someone, names in code also convey meaning. They tell me what I’m looking at. They are important for me to understand the code and should be relatively easy for me to remember, because, ideally, they are just the words I would use to describe what the code does.

I recently did a code review with a student and found myself quite unable to follow his code. The problem wasn’t that I couldn’t understand the names he’d given to variables. On the contrary, this was fairly easy, since he’d named them all like “obj” and “obj_array.” When I asked him about it, he shrugged, said: “I’m bad with names,” and continued like the matter had been settled.

An Excerpt of Some Code the Like of Which I Never Want to See Again.

While I can simply ask a person again for her name, it’s considerably harder to find out what a variable represents, when it’s called “obj.” I can’t just ask it. So if I don’t happen to have the respective code’s author around (who also happens to remember what that particular variable is), I’m left to do manual program analysis. A cumbersome task, which becomes even harder in dynamically typed language, where the variable could hold just about anything.

Naming a variable “obj” is like not only forgetting your interviewers’ names, but also what the interview is about and what you’ve just been asked. Certainly not a charming display of human imperfection, but rather impolite. To me it’s saying that you don’t care.

Naming a variable “obj” is like calling out “human” to get the attention of someone you just saw dropped something on a crowded plaza. Though probably correct, it isn’t particularly helpful. You could be addressing literally ever person on the plaza. In fact, “human” is so generic that I would guess the only people turning to you are those eager to see the screaming weirdo…

In lack of the person’s name, to get her attention, I might pronounce any descriptive (and preferably distinctive) attribute, such as the color of her jacket. Similarly, in code, naming elements after what they are and what distinguishes them from others is a good start. This may not result in perfect names, but at least in something one can work with. Any clue as to what a variable represents may save a lot of time.

It’s one thing to be bad with names. It’s another thing to not even try. Giving better names can be learned. Giving names at all just needs to be done. Period.