> Genuinely curious, is this true for most people?

In my experience, understanding the code 6 months later isn't the challenge, but rather understanding why I made the set of decisions I did with regards to any tradeoffs I made when writing the code.

The best way I can think of to try and keep that from happening is to comment, comment, and comment some more. Specifically, I try to explain not just the HOW but the WHY of a certain approach that I took. The way I see it, if using a little more disk space for comments saves me a little time from having to try and remember why I did something 6 months later, I'm cool with that. :-)

This is my experience as well. I have come to keep a sort-of contextual information hierarchy, where the most important information is evident at the top-level and the most detailed information is easily searchable:

The most-important context is used as the body of commit messages; the more-detailed but still very important context goes into comments directly in the source code. Other context (with regard to why certain decisions were made, things that are tradeoffs, why an operating point was chosen, things to be revisited, how data to support this decision was collected, etc goes into the bug report and a dated text file with the commit hashes and bug number, which makes digging it up later significantly easier: just grep your notes for the relevant bug numbers and commit hashes.

Keeping those very detailed text files has saved me more than once, and when I slip up and don't include information it often comes to haunt me later.

Why not describe your decisions in the code?

The behavior of your code changes, so comments need to be regularly updated to reflect the current reality.

You do want context there (in the comments), but often greater context (detailed information, that may go out of scope, or not reflect the current implementation of something) should be preserved elsewhere so you know a year from now why you made a decision.

You could keep all the information in the comments and be disciplined about updating them. But when you want to understand something that has changed, you end up needing to remember to go looking in the correct commits for the comments you made at that time. I personally just prefer dated, static notes that won't change and are easy to grep.

I mean keeping the history of decisions in code.

I've often worried about this but when I do go back to my old projects it's usually not that bad. Sometimes I'll find something dumb I did and rewrite it, but for the most part the code is easy enough to read and modify.

More than once I've thought I've run into a bug and figure out what the problem likely is, only to go into the code and discover that I already covered that case and the bug is something else entirely.

Most of the rewrites are because I had to do something awkwardly because some feature didn't exist in a library, or it was broken and I had to work around it. Then a couple of years down the road that bug or missing feature has been fixed and I can pull out the hacks and do it the elegant way.

It happens to me as well. I sometimes think : 'oh I already did this. That was very well thought'. Unfortunately I can't share this feeling with me 6 months ago.

The times when the code is painful to read is when I write scripts that are supposed to be used once and turn out to be reused several times (but not very often) and when the specs were not really well defined at the beginning of the project.

Admittedly I am data scientist not SWE and it is hard to compare the complexity of SQL code to the one of a programming language.

I could remember everything about every codebase I had ever written up until about the age of ~30. Now at the age of ~40, I can't remember what I wrote two weeks ago. It'll happen to you ;)

Wanted to basically write the same thing. It is also the reason, why I (and many others) write less sophisticated one-liners and more really dumb code, than I did 5-10 years ago.

I noticed BTW the same for written text (code comments, wiki docs, blogs etc.) - when I re-read code comments I wrote a month later, I almost always find ambiguities, sometimes missing the larger point in the details etc.

Written stuff is hard as you have a lot of context in your head, your voice intonation etc.; sometimes a lacking comma, or reversed order of words, or a typo like missing an "s" or "ed" for plural/past can derail me for a good while while re-reading old text.

Well my favourite joke goes:

Starting code changes, notice some bad code, wonder who the hell wrote that crap, have to find that nasty person.

Fire up 'git blame', check code lines in question, "oh that was me, seems it is not that bad after all".

There's that, but I usually think "Man I must've been really unfocused or otherwise distracted to write it like this" but then analyzing it, it starts make total sense. But there's also the opposite. Code where I can't believe I was so smart to write. And then I remember that I can solve any problem if I keep attacking it time and again and tune my brain to it.

My performance is like a wave, sometimes I'm riding it, sometimes I'm being overwhelmed by it.

I definitely don't feel that way.

I don't go into the code I wrote 6months ago knowing exactly what every line does, but I remember the broad strokes about what it is generally doing, where different logic will live, and it makes it much easier to jump back into code I wrote 6months ago vs code I've never seen before.

After about three 2 week sprints, my memory starts to rapidly decay about what I worked on or how I implemented something. It is a struggle for me, as my team is often called out by PMs about how certain functionality works under the hood and I have to retrace my steps.

>It goes on to say that even six months is optimistically high.

I'm in the habit of focusing my in-code documentation on why I made a choice, and my out-of-code documentation on code structure. This is probably counter intuitive to most people (who do the reverse from what I've seen).

The reason I do this is twofold. 1) Code structure changes don't occur that often for me (I'm a feature-terse programmer, only add what I need at the moment), and when it does change I really should be documenting that at the API level, not in the code.

2) The reason I made decisions are usually only relevant when I'm actually changing previous code (do to encapsulation and abstraction).

This method means that when I revisit an old project, I have my out-of-code API Documentation open in live-edit mode, using it for structure reference and adjusting it for any changes I make, and I have my reasoning sitting directly above the code I'm about to change. It works out really well!

Unfortunately, in school we were pushed towards documenting the structure in code, and using something like doxygen to extract that. I find that an ugly practice... The structure is always visible if you're adjusting code, but you're reasoning usually isn't.

The more code you write, the more true it is.

Sometimes I go back to old code and go “What was I thinking”. Other days: “Wow, I was on it that day.” In any case, write like a stranger will be fixing your code later. Six months later, the stranger is you.

I believe that this observation is 100% true. And I agree that six months is optimistic. I'd say that if you wrote code three months ago and haven't looked at it since, then it might as well have been written by somebody else.

You remember the ideas that made your system different (because you'll need those to sell) but you forget the ugly workarounds... my solution is to try and leave as few ugly patches and when I do put a comment!

I find good commit messages (and if you're using something like github, good pull request summaries) really helpful here for reminding me of the context around why I wrote the code.

For me, it's like 3 days later.

Depends on the language for me. In Perl it takes about 6h.

I find this is especially if the code was written in haste, but if it's code I write professionally, it's usually easy enough to reacquaint myself. Probably the worst cases are the spaghetti code abominations that are generated by hackathons.

For me I usually forget the generic stuff. If I wrote something that was a bit different or if I put some extra effort or thought into it I find I can recall those implementation notes may be ever after a year.

It's true but it can be mitigated with good comments and documentation and of course the most important thing, not writing over-complicated code. Sometimes the code you don't write matters most.

Code I came back to 8 years later felt genuinely alien. Otherwise I can come back to something 3 years old and remember the general architecture, but gritty details start fading after a few months.

I just opened some of my PHP code from July 2020 and started fine-tuning it.

It is understandable, not completely foreign, but a lot of the context around my previous decisions evaporated in the meantime.

Surely it depends on many factors, like the size of the project, how many various parts of the codebase one is responsible for in their work, etc.

As far as rule of thumbs go, I think it's a good one.

Maybe early in my career?

In general, as I've adopted good conventions and know-how, I find code that I've written a few years ago quite readable.

For me it's about 4 hours

> is this true for most people?

No, only poor engineers.

It's somewhat true for me. I may be poor, but I dispute being an engineer.

In fact, sometimes I'm surprised by what I did 7-14 days ago. But yes, I can get back into that code much more quickly than if I hadn't written it myself.

If this isn't true for you, you may not be solving hard problems.

Wouldn't hard problems make it easier to remember? If you spent a couple of months a few hundred lines of code, then you probably know it much better than something you finished in an afternoon.

Personally, I can remember pretty much every line of some algorithms I wrote years ago, but I was doing some cleaning the other day and there was a month old abandoned branch I had no idea why it was written.

Hard problems are more unique but often more complex. I can normally remember the gist of how complex things work but the details fade from memory pretty quickly.