The Lemma
When you can't figure out what to name something, you haven't finished understanding it. The name isn't decoration on a concept you've already grasped. It's the last test of whether the grasp is there.
This shows up most clearly in refactoring. You have a function that's too long, and you split it. The split looks like a structural decision, but the real work is earlier: deciding what the extracted part is. Once you have that, the extraction is mechanical. You're not moving code; you're transcribing an understanding you reached before you touched the keyboard.
The mathematics word for this is lemma, an intermediate truth proven separately so the main proof can borrow it. A lemma isn't a theorem's scraps. It's the part of the proof where the conceptual work actually happened. Once you've proven the lemma, the theorem often follows in a few lines. The lemma is what needed naming before the larger argument could proceed.
Code has the same structure. There's a moment in every non-trivial design where you realize there's a concept with no word yet. You're not missing a function. You're missing a concept. The code that would implement it is knowable; the concept itself is fuzzy. Until you name it, you're writing around the gap. After, you're filling in what the name implies.
The standard argument for "naming is hard" is about clarity and maintainability. Those are real but downstream of the basic claim: you can't name something you don't understand. A bad name is a flag that the understanding is incomplete. When you see a function called handleStuffAndThings or a variable called temp2, you're not looking at someone who couldn't think of a word. You're looking at someone who couldn't yet say what the thing was.
Which means the moment the name clicks is the moment the problem is solved. Everything after is assembly. The code exists to execute a decision already made.
This is why pseudo-code works when it works. You're not outlining code; you're being forced to name the intermediates. Once you have the names, the translation is nearly rote. The pseudo-code step is where the work happens; actual coding is where you write it down.
It also explains something experienced engineers do: getting stuck not on the implementation but on the name. You know what the thing does. You can describe it in two sentences. But you can't name it, which means you can't write it yet, at least not in a form that won't need to be rewritten once the name comes. So you sit on it, or describe the problem out loud until someone says "oh, so it's a--" and then you have it.
The practical implication is about where scrutiny belongs. Code review tends to focus on implementations: the algorithm, the edge cases. Those matter. But the more load-bearing decisions happened earlier, when the abstraction was named. If the name is wrong, the implementation is correct code for the wrong thing.
The real decision is in the design doc, the comment explaining why the abstraction was drawn here and not there, the PR description that says "I'm calling this X because it does Y and not Z." The code is the receipt.