I think one thing people subconsciously or consciously struggle with is how explicit to be. I tend to side towards explicit because I’ve found the biggest trade off to be character count, which is not a big deal. I’ve received several compliments from other programmers when following this approach. A crucial step is to go though everything at the end and simplify / cut-out words that don’t provide meaningful value. Keep it iterative and constantly refine. Once you get used to this natural process of it, it becomes less stressful and more fun - almost like an exploration of ideas and concepts.
As long as you can tell roughly what an object does and there's documentation and comments to cover the rest, no one will mind if the name is a bit skewwhiff.
If it doesn't, it may model a well-known software pattern. Check out the list at https://en.wikipedia.org/wiki/Software_design_pattern.
You might call a factory that produces Foo objects a FooFactory. Or a proxy to Foo objects a FooProxy.
If it doesn't fit either of the above cases, don't sweat too much. Give the thing an accurate name that describes what it is or what it does. Sometimes consulting a dictionary or thesaurus can help. You can always rename it later.