Nail struck squarely on the head. This is why naming things is is hard. The temptation and sometimes need to barrel through without real understanding in very strong.

My practice is to notice when I'm starting to struggle with naming things and take that as a signal that I don't quite have what I'm doing clear in my mind. I need to step back and take a few moments to reflect. It's saved me from future trouble more often than I can count.

   calculateTotalPrice(100, [5, 10, 15]);

I mean, either this is a bad example not well thought out, or the original function is doing something completely different and the supposedly good naming is actually a very bad one since it appears to make sense but doesn't. In either case not good.

I was once at a conference where Bjarne Stroustrup was speaking, and after the talk he was answering questions for a handful of us from the crowd. I asked about something that had been bugging me for a while — that I was finding myself spending what seems like a lot of time developing naming schemes for projects, and was this a good use of time? His answer was an immediate "yes, this is something that is actually quite important". Since then, I stopped worrying myself about it, and enjoyed the times I had to look into existing code and could figure out something quickly, because I'd put in the effort up front.

In that context, the main insight of the article definitely makes sense. Not only does the coder being evaluated use good naming in one instance, but have they invested the time and effort to wrestle with the problems and developing useful ways of thinking about it?