I do the same, any kind of minimally unexpected code gets its explanation as a comment if the code can't be clear about the why. I like to leave a comment with what is happening, the background for it and any kind of gotchas I'm aware at the time.
This has saved countless man-hours for my teams, including myself when refactoring part of the codebase a year or so later, having a nicely written rationale behind some weird-looking code gives me not only peace of mind but a lot of trust in the rest of the team.
I try to document (in code) a lot of that "why", so that the answer doesn't need to be passed around as tribal knowledge.
If you need a person around to be able to explain the project architecture, it's probably a sign that you need more/better documentation.
Just my 2 cents.