It is normal, but there are proven counter-measures.
Train yourself to document all your non-throwaway code as if
you were publishing it for other skilled programmers (but not for dummies).
Do it as you write the code, part of the process; review it as you change
the code. You will be pretty much another programmer when you've left it alone
for, say, your summer holiday.
When you form a habit of this, it doesn't feel like a drag.
Documenting your code is a key weapon of design, problem-solving
and bug-detecting. When you can't code it right, stop trying and
document it first. If the code smells, document it and you will probably see
where the smell comes from.
Then progress to documenting it first anyway.
Write code that is sufficiently well designed and modularized that the documentation
of the interfaces is almost all the documentation you need to write:
functions, templates, classes, methods; parameters and return values;
pre-conditions and post-conditions; exceptions.
You want the implementation of an interface to be surveyable in one "eyeful" and "obvious" to
skilled programmers. If you find the need to explain an implemention
by a running commentary of comments, then the design and/or the implementation
is bad. Smart-ass implementations always need explanation and are rarely worthwhile.
If you have some code you have written that you struggle to understand every time you need
to maintain it, consider that a bug that needs fixed, and fix it at least by the
Fixes Before Features principle.