I'm in much the same position-- I've been writing software for about 30 years, but never as my main job, sometimes for fun/entertainment and sometimes for work.

I often set code aside for months or years as I don't have time to work on it or get distracted by something else. I fortunately wrote some stuff in Turbo Pascal about 25 years ago (a Corewar implementation, fwiw) that I liked, and then went back to about a year later and tried to read. My reaction was "Wow, did I write this?". Even though it was broken into decent sized functions and they were labeled and lightly commented, I hadn't really explained anything at all of what was happening and why, and it took a long time to figure out.

I now tend to write for my future self, knowing that I'm not going to remember any of it: Start with comments to describe what the program is going to do at each step, write the program, describe what it's doing and why as a I go. If it operates on external data that might change, I'll put in notes of what it's expecting.

My idea of comments is, comments should be 1/3rd the size of the code they accompany. The comments should explain your design choice, potential future design choices you didn't do due to a lack of time, skills, research, profiling, benchmarking, performance, client demands, etc, all your rejected design choices and your rational for rejecting all of them. Someone, including you might come back and say "hey that works, you should've done it in the first place" at some later point. The whiteboard from the meeting you had with other devels, or the napkin or scratch paper you planed your design on is long gone if you come back to the code months or years later. The comments stay forever. The comments should, in some cases also summarize the behavior of the functions you didn't write but are using, if the docs of the function are extremely long (Microsoft), or are written with much "undefined" behavior and you are using that undefined behavior (Microsoft), or ridiculously short or none existent (auto generated garbage, examples are Azureus or Mozilla).

Sadly in some places, programmers are encouraged, and its nearly a requirement to keep ones job, to write obfuscated comment-less unintelligible code to guarantee they have a job. Dead and unreachable code is also good. Exception handling code for impossible exceptions is good. If you to generate alot of work for youself, make a design policy, that 1 object/class's definition/interface can't take more than 1 screen, and the functions of that class in the code file can't take more than 2 screen fulls max and you wind up with inheritance charts that would take the surface area of a car to print on paper. It guarantees you will be employed since even if your client takes the code and gets "consultants" or contractors to look it over, they will return a quote of 100s or 1000s of hours or just cost plus to your boss. You salary looks alot cheaper to your boss suddenly.

I can’t magine why you’d feel the need to don that flame-retardant bunny suit for making a pragmatic comment like that.   I rely much more on comments than on code for understanding even what I myself have done.   That is nothing more or less than a pragmatic survival skill.

I also categorically reject the viewpoint of people who say, perhaps in the name of “don’t repeat yourself,” that you have to write code as succinctly as possible.   For example, I recently got lambasted by someone who didn’t like me writing this:

if (something_1_fails()) {
 ... do something ...
}
if (something_2_fails()) {
  ... do the same thing ...
}
[download]

This person’s murderously-held opinion being that the only proper way to write it was:

if (something_1_fails() || something_2_fails()) {
  ... do something ...
}
[download]

such that it was absolutely “my way or the highway.”   My contrasting point-of-view simply being that:

• It makes absolutely no pragmatic difference to the Perl compiler and/or to a modern-day machine, but...
• The day will come when you want to change that code, perhaps in some slight way, and now you find that you have coupled these two pieces of code and/or behavior tightly together.   The two responses might be identical now, but the reasons for those responses are not the same and in fact they never will be.
• (Key Idea...) Whether the response today is identical or not is not the point; whether the code is “more efficient” today is also not the point:   the concerns are different, therefore in months and years to come there is no reason to suppose that the responses will be different.   In order to correctly maintain the “only proper way” code anytime in the future, you are going to have to figure out both routines and (correctly...) judge how to prize them apart.   What ought to be a “no-thought modification,” say to tweak an error-message, suddenly requires thought.   All to gain you ... what, exactly?   (A: nothing.)

Your thoughts always become the thoughts of a stranger, and you always re-discover those thoughts every time you go back to any piece of code .. in any language.   How well you documented those thoughts, and how cleanly you made those thoughts, truly makes all the difference in the world over the sometimes decades-long life span of a commercial application.