I have the exact opposite experience. If you find yourself annotating your variables and methods with extra adjectives and nouns, your code isn't simple enough. Those explanations go in code comments.
Often it means you can refactor it so that there is only one of any "thing" so there is no need to clarify which version or role this "fooBarThing" is serving to disambiguate it from the other "bazBarThing".
Functional composition and well structured data is the key to this. It's basically halfway to point-free style.
The variable name can just be fooBar, and bazBar, and organized/namespaced such that you could have Thing.fooBar and Thing.bazBar (assuming you want those exposed to the rest of the application).
Readable variable names doesn't mean wordy names. I would avoid using more than 2 words in a variable name.
Good, clear code, with nice names and such shows what the code is doing and how it's doing it. It doesn't tell you anything about why it's being done, or the context of the function within the code.
You're lucky if you're dealing with code that's either small enough or simple enough not to need the added context...or if you only need to read your old code.
I look back at a lot of my old code and even without comments, it's easy to follow the logic because I used sensible names and constructs.