The article has a fair point. Sure, “naming things” is usually not about naming but abstracting, and once you have good abstractions, good names follow.
But there are a few more cases where naming is genuinely hard. Sometimes there is a gap between the formal language (programming languages) and informal language (English). In well-established subfields like web programming, you have a term for almost anything you will need frequently - “validation”, “middleware”, “render”, “routing” - these all have well-defined meanings. Now imagine that you are doing web programming before someone has invented those terms. What do you do? You have to invent the terminology first and it’s not straightforward.
Sometimes naming is hard because your program involves multiple domains, and terms have different meanings in those domains. For instance, “task manager” can either mean a GUI application to manage tasks on an OS, or a process-internal scheduler to manage the lifecycle of some repeating tasks. Now imagine you are writing a program that deals with both types of task managers. How do you disambiguate? It’s hard.
Still, the point of the article is quite valid, and I would say covers more than half of the case where “naming is hard”. But still, there are times when naming is genuinely hard, because language is hard.
Naming things is something that made me so unproductive that I decided it would be far better to just give something a name I know is mediocre or bad and come back and fix it later. Or just don’t. Sometimes it turns out naming isn’t really that important. You build up a vocabulary within a project. Looking at the project I have open on my screen right now, is are MatchResult, SymbolMap and Ref the perfect, most descriptive names for those types? No, not really. But they took me a few seconds to come up with, and they now actually mean something within the project. They’re good enough. Is Expression' the best name for a subexpression of an Expression? Probably not. But I didn’t waste time choosing it, and it’s a find-and-replace away from a fix if I decide on a better name later.
Especially for things that aren’t public APIs, just choose something and get your real work done. Spending ages farting about over names is as unproductive as all that time you spent fiddling around getting exactly the right font for the essay you’d written half of and had an hour to complete.