You don't remember, thats what comments are for!

This one always spoke to me. But I work on embedded systems so I get to fiddle with physical equipment to really make sure the code works.

Comment your code. Problem solved.

Yep, having a shitty memory makes me write better code lol

I usually ask AI to summarize it and then I get a pretty good idea of what it was meant to do. It's just another tool to me. AI generated code sucks but it's nice when it's a quick summary.

For anything that doesn't seem entirely obvious I try to leave a comment. It could end up being helpful to me some time later, because let's face it: your code is indistinguishable from someone else's code 2 weeks after you commit it.

Oh I remember what it does...I do not remember how it does.

As an undergraduate, I wondered how it was possible to write code professionally, because I could only barely fit the semester-long programming assignment in my head. When I asked my professor about it, I got an independent study credit to learn about UML.

UML (as a representative example of thoughtful documentation) is a partial answer. But actually a much larger part is that with practice I can hold a lot more code in my head. Today, that semester project seems trivial and if I see a stack trace I can tell you how to fix the bug that caused that exception to get thrown.

As a senior dev, I'd answer "how do you remember what your code does?" with

1. As you work, you get better at just remembering
2. As you find patterns and follow them, you'll have less to remember (I bet I know what the downloadUnpackUpdate() method does!)
3. As you do the first two, you'll learn to recognize when comments are helpful

My first tech job out of college, I was told to go talk to "Dave," the guru old-timey programmer and learn the lay of the land. He turned out to be this crotchety old guy, with low tolerance for idiots, but a soft spot for someone who actually paid attention.

A few months in, I was told to go fix a feature in the company's main product which was sold to power utilities. This was a MASSIVE code base, with a mix of C, C++, assembler, and a bit of Fortran thrown in. I spent a week poring through all the code trying to figure things out. Then I hit a mystery workflow that didn't make sense.

I walk over to Dave's office and ask a specific question. Now, mind you, he had worked on this years ago, and had long moved on to new products. He leans back in his chair, stares at the ceiling, then without looking at the screen once tells me to go look at such and such file for such and such variable, and a list of functions that were related. I go back to my desk and damn if it wasn't EXACTLY as he described.

Now, I'm probably as old as he was then. I don't remember what I wrote an hour ago. No matter what I build, I'll always be in awe of Dave and what he could keep in his head.

The entire purpose of writing good readable code which is mostly self-explanatory and were it isn't it's properly commented to explain what's going on, is so that it it's not a necessary for the person who picks it up later to be somebody who does remember what that code does and how it does it.

Whilst this is mainly important to allow other people to work in that code, as a side effect the actual person who wrote the code if they follow those coding principles needs not remember what it does and how it does it.

One of the upsides of being a senior dev is having figured this kind of thing out from experience, which offsets the downside that since you're older and have done a ton of things, it's less likely that you will properly remember the details of a specific code base after some months of not looking at it.

You dont. Thats why you write comments!

Which is why making code readable is so very important. Our juniors and students will think we're ridiculous, when we spend a long time cleaning up some code or choosing the least misunderstandable name for a type. But you fuck that up and then others, as well as your future self, will be wasting many more minutes misunderstanding what your code does.

In a more serious note, that's why you document your software!

This made me chortle. I remember when I first joined a dev team asking someone how many of something their section should be able to store:

I don’t know, I’d have to look at the code.

It was an eye opening moment. Very few people can keep everything in their head. I’ve met a couple. They were rockstars who were truly exceptional.

Partially yes. But if I create something myself I can "revisit" the headspace of that portion very easily, like I walked into a room.

Doesn't work as well on codebases I don't own fully though.

The people who say "the code is the documentation" totally misunderstood what that was supposed to look like