> just say what it does But it isn't always easy to describe both clearly and succinctly what exactly a function (/ etc.) is doing. And a particular issue I h

> just say what it does But it isn't always easy to describe both clearly and succinctly what exactly a function (/ etc.) is doing. And a particular issue I have is one of audience: to whom is this name addressed? Should it be at least somewhat obvious to a newcomer to the codebase to understand what the function is doing? Or can I assume that the reader / maintainer is already knowledgeable of the context in which this function exists? In my (limited) experience, this becomes exacerbated when I'm trying to name some abstract operation in a context that doesn't already have a well defined lexicon. So then I, unfortunately, must be the person to create this dictionary of terms that I will be referring to repeatedly throughout the problem space. On top of this, I generally don't even know how I'm going to solve the problem when I first start implementing, so my first round of names might be strikingly obtuse to an outside observer. But if the implementation becomes sufficiently complex, and I don't take the time to refactor or receive input early on, these names become intuitive to me via repetition, so then I end up building on top of them and create this pyramid of gibberish that at some point made sense to me but that someone will unfortunately have to take the time to grok at some point in the future. This doesn't happen so often that I would say it's the second hardest problem in our field, but it definitely is something that can contribute significantly to tech debt. ¯\_(ツ)_/¯