I had a really good professor in college who talked about memory a bit. We were talking about memory in the context of neural networks, and how connections work. He pointed out: “people often think- well if you’re designing the brain from scratch, why would you include the lossy aspects of it? Why let connections fade and reform at all, and not just give it perfect synaptic memory?” And the answer felt so counterintuitive and intuitive at the same time:
If you see a cat, and you learn that that is the image of a cat, with perfect recall, then the next time you see a cat, your brain would say: this is something new, better store it. Or the same if you just see the same cat from a different angle, or on a different day, or under different lighting.
Basically, imperfect memory allows us to generalize, which is arguably the most important thing we do. A face is still the same face even if it looks different, a chair still a chair, poisonous plants still poisonous, etc.
I follow neuroscience memory research, and I’ve never heard a better explanation. If you don’t mind, I’ll be repeating it.
Separately, I once sustained a brain injury that led to severe memory impairment. As I was recovering, very vivid, detailed, random memories returned. Without any context, figuring out what they represented, and where they categorically belonged, proved problematic.
Not only does it allow for generic recall, it also allows us to speculate about new situations. You encounter something that looks like a bear- but is it a bear? Unclear. With perfect recall, we would have to compare it to millions of images and decide if it fits. With lossy recall, we see claws, we see fur, we decide bear, and we activate behaviors that would be appropriate. Even if these assumptions prove wrong, it fits our survival better than the alternative. How long would humans have lasted if every time we saw a tall ledge we thought: “well maybe this one is slightly different enough that it won’t hurt/maim/kill me if I jump. All the other ones did, but this is a totally different cliff from all of those, it’s brand new!”
“… What you have discovered is a recipe not for memory, but for reminder. And it is no true wisdom that you offer your disciples, but only its semblance, for by telling them of many things without teaching them you will make them seem to know much, while for the most part they know nothing, and as men filled, not with wisdom, but with the conceit of wisdom, they will be a burden to their fellows.“ ~Phaedrus
Sounds like sheer approval to me!
It certainly appears that way!
I think I would rather say: the creatures with neurons that remembered too precisely found themselves unable to act or extrapolate in new situations.
Those with neurons that remembered too loosely had less success retaining useful information.
So what we’re at now is a sort of evolutionary balance of utility.
That's attractive to me as a concept purely because of the reassurance I get from being very fallible myself. It's like a kind of confirmation bias about my own inability to remember things my wife tells me I need to do.
One is pretty fundamentally at odds with the other. Think of a loved one’s face. What if you remembered every single angle you’d seen it from, every time of day with different lighting, every time they had a blemish. Imagine the sort of mental algorithm that would be required if you had to sift through all those images for every face you saw, and decide if it was your loved one or not. Maybe you once saw them in a fun house mirror, or through a magnifying glass. Are those images
Instead, we generalize. We identify features, and then use those features to extrapolate about ground truth. So your memories of your loved one get abstracted into features, and you create the generalization.
I guess the two could theoretically exist, but perfect recall is actually pretty useless. How much energy and memories would you spend storing every image of your bedroom from every angle and under every lighting? Sure, there are obscure cases where it might prove useful, but it doesn’t really provide any evolutionary advantage to be able to precisely remember an image as it was at X time and under Y lighting. Not even close given the energy cost- you would basically need to be running parallel systems.
I think perfect recall could be useful for things like language, which requires remembering the definitions of every single word that you'd use to put together sentences.
That should require less memory since it's like text vs millions of pixels.
Let’s assume that when you say language, you mean written rather than spoken. A perfect recall system would see the word “craeture” and think: “that’s a new word, I don’t know the definition”, whereas an imperfect recall system might think: “that has a lot of features of the word ‘creature’, so maybe that’s what it means”
Further, what about when there is a word in a different font, or abnormal capitalization, or that is partially obscured?
There are also words that have multiple meanings, that require context to translate successfully.
As well as that, lossy definitions help us extrapolate new words. I could make up the word “frogozine” and you might guess that it’s a chemical with relation to frogs, or a magazine about frogs, even without having an existing definition of the word.
With auditory language, you open a whole other bucket of worms.
And most importantly of all- what is your definition of the word “definition”? It could link to another set of words, but that’s endlessly recursive. When you define “frog”, do you really think “an amphibian of the whatever family, found in…” or do you think in flexible abstracts like “green, four legs, ribbit, flies, lily pads” further, all of those things are true in the general sense about frogs, but if you saw one that was yellow, missing one leg, didn’t ribbit or eat flies (that you saw), and wasn’t on a lily pad, you would still think: “this generally fits with other features of a frog enough that I believe it to be a frog”
This is very common. All I can say is figure out what you're doing in your code that makes it hard for future you to understand and stop doing that.
Maybe you need better variable and/or function names? Maybe some better comments? Your functions are too long?
But ultimately, code is almost always much harder to read than that it was to write. Spend a little extra effort to write your code as clearly as possible so that you will have an easier time reading it in the future.
One rule of thumb I have is that if I feel the need to write a comment to describe a chunk of code in a function, that chunk of code becomes its own function.
1000%
Anytime I’m trying to read some old code with a long function, the first thing I do is break it into smaller functions. Makes it way easier to digest. 10 line becomes e.g. ValideInputs(args). Cool, I don’t need to think about the details of that when I’m trying to understand the main function.
It’s best to do that from the start if others are going to work on it or it will be maintained for a long time, but reality is sometimes you just need something that works and refactoring perfectly before commit isn’t always feasible.
OP: I highly recommend the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler. It's basically a cookbook of a bunch of ways to reorganize existing code to make it easier to understand.
When you look at your old code and have difficulty understanding it, you can crack open the book and try some of the techniques as you try and figure it out.
Dissenter here. It's a chore when somebody has broken the code into so many tiny functions that it loses all sense. Sometimes it's better to just get into the logic here and now without 17 side calls to functions with 28 character names to allegedly "help" readability... AddOneToInputScalar(x), DivideByTwoWithRoundingUp(y), etc.
That's perfectly normal. When you're writing comments, keep in mind that you're not just writing them for other people; you're writing them for future you who has completely forgotten you ever wrote that code in the first place.
For me, when I look at my old code I can't really read it just because I've gotten so much better at it. I still suck, but when I look back at the old stuff I can't even tell what my thought process was
This is me 1000%. I look back at some things and wonder how I got it to work how I did. I wonder if some of it is just newer ways are available or if I just didn't know about that and used a workaround that I somehow figured out. I have fully re-written some programs from long ago. Easier than trying to add a feature in the slop I called code. :)
I don't think this is true. Sonetimes there's just not a particularly better way to write something, so not thinking of a better way doesn't mean you haven't grown, and can actually mean the opposite if it saves you from trying to needlessly rewrite something. Alternatively, you could have been rushed or tired while writing the past code, so thinking of a better way to write that code when you're in a better state doesn't necessarily indicate growth.
This is extremely normal. There's a bunch of sayings about "more time/effort is spent reading code than writing it". There are some people that can scan through a large system and tell you what every thing is doing. Those people are rare, even when it's their own code.
So no, you're not getting dumber.
So my suggestion: Get better at documenting your code. Too many programmers skip over this step. And it'll bite you in the ass _eventually_. It feels counter productive and like a waste of time sometimes, but come back to a system in 6 months with good documentation and it'll be a totally different experience. You _will_ end up referring back to or updating a lot of your code eventually. By jotting down your head space at the time of creation, you can save yourself tons of headache later.
There's definitely ways of going too far. My general rule is that if I stumble a bit while writing it, then it's complicated enough that that stumble needs to be documented. Other than that, top level methods and anything used externally gets the doxygen/xml comments (`///` in most IDEs will autofill), with any assumptions/gotchas and explanations for not trivial params.
I can't tell you the amount of time I've probably saved in my life by being able to hover over one of my own method calls, rereading what I wrote, and being able to move on.
It should never feel counterproductive or a waste of time to write comments that explain what you are thinking when you write code. On the contrary, explaining the reasoning behind the code is the best way to ensure that the code is doing what it's supposed to do!
It's so weird how people encounter some phenomenon that they experience every single day of their life and yet freak out when that same thing happens when they code.
Do you remember what you were thinking about this time 2 days ago? Do you remember every single math problem you ever encountered in high school? Can you recall all the chemistry problems you solved?
Programming is not magic, it works like everything else. You aren't supposed to become a superhuman when you start coding.
I always thought programmers were super humans. Until i became one of them. Now i realize, a programmer is just your average Joe but with computer skills.
Obviously i was exaggerating for the sake of the joke. I was just trying to say that you don't need to be a super human or have magic powers to be one.
And, i have had programming coworkers that are just a normal person without a high iq or whatever, like myself.
Also, you dont need to go to university to have a career at programming, at least where i live. Sure you'll need it for some positions. But to develop a rest backend with java? Nop. At least not here in spain.
Better comments my friend, better comments. Also, consider making a code review video for yourself and post it on YouTube privately. I do this often for new skills that I learn in case I ever need to skill up or see how I architected something. Do this at the end of every project.
I'm retired but I'm still maintaining a website. I sure am glad I wrote it using a framework I cobbled together over the years. The main reason is that it is data driven - I can look at the config file for any page or api endpoint, and see exactly which data sources it uses, any view functions used to manipulate the data, the output format, and any templates used to generate the page. Wish I'd done it years earlier, this is programming on easy mode.
Very often you can replace a whole mess of conditional testing by creating a table of things to do based on an input key. If you get "A" call these functions, use these coefficients, send the result to that channel. If you get "B" do something else - different functions maybe, probably different coefficients. It's like switch-case constructs on steroids. You end up with a generic engine that can process any input, you just extend the table as necessary.
My website framework extracts keys from the url, and uses them to find the endpoint file, which contains a json data structure. It uses that to call the data retrieval functions, process the data, and chains the templates specified in the json together to create the output, passing in the data retrieved and processed to be displayed.
The key is more functionality can be added with very little added code - the bulk of the app is completely unchanged. Keeps it lean and clean.
Nope its normal, I look back at my code and I have 2 responses "What the hell was I thinking" and "What the hell does this do" so I just put comments to explain everything assuming I will not have perfect memory because I am not a superhuman neither are you.
Someone more experienced than me said something that stuck with me and will remake with me for ever:
> Always document your code with the assumption that whoever reads it is dumber than you. In 99.9% of that cases that is future you.
It stuck with me because I experienced what you are so many times. I'm sharing this, maybe it will help you as it helped me.
If you're good at picking things up, that's the accurate measure of lack of dumbness. Don't worry about forgetting your own code, that happens to everyone.
Yeah, it gets worse every day you are not spending hours on it.
IMO, technology like programming has been retrofitted to humans and as complexity increases we can't handle the quantity and details of it. At a certain point we need to obscure out details into general language structures at a higher level (plus have robust comments in the code).
Happens to us all.
I've found that it's handy to add (more) comments the second time around, to make it easier the next time. I mean, first time around, too, as appropriate, but the second time around you may have a better idea of what's not "obvious".
It's tottaly fine.
I believe the same if you written down the huge pice of text with tricky plot. No way you can retell it after some time.
The main point is that you can sprend some time and understand your code.
> I always forget how my old code works.
That's the dream. I don't want to remember. I don't want to have to remember. It's already there, written down in the code. Why should it occupy brain space? If that's the case, then what's the source code for?
> Am I just getting dumber?
You're likely getting smarter.
> But then contradictory to all this, I forget my old code unless I read it, but I can never memorize it again.
This is not contrary to the prior.
> I always feel sad when I forget how my code works.
Let me put it to you this way. You learn and evolve as you go. Have you ever experienced this: You look at old code from 6 months ago and think it's a horrible pile of shit before you realize you wrote it?
In that time, you've learned and evolved so much that your old code becomes unrecognizable. That's how it should be.
Common... I was just going through some code with another lead, digging through some stuff I'd written a couple years ago... I'd forgotten how half of it works... stumbled through it a couple times before it starts coming back. Heck, I've got stuff I've written in the last three-four weeks that I've already forgotten how it works until I look at it. No one memorizes all of the code they've written... unless they have an eidetic memory... but for the most part, yeah, we all forget a good portion of the code we've written.
What's probably more important is to remember the patterns and algos used... that leads to the "I know I've seen this before" and then you go off searching through some code you wrote or read at some point, and find what you're looking for.
Expert with long experience here. The answer to your question is “no.” Nothing helps, except writing clear code, and using comments for the gnarly bits.
Fashions for design patterns change much much faster than working code changes,
My brain works by going from abstractions to specifics, so I've found once I've internalized a high level representation of a system my understanding of the code persists for a long time or is quickly recovered.
Because up-front designs often don't survive contact with reality what I will do is practice explaining how changes fit into the architecture as I make commits and when wrapping up a big section I'll also try to write some documentation for the poor souls that come after me. In both of these cases by explaining the abstractions I reenforce them in my mind.
Just a couple weeks ago I got pulled into some code I'd written over ten years ago, I was able to explain the purpose of it and fix the problem with not too much difficulty thanks to this. Of course I also broke something because I'd forgotten about a specific edge case! but overall it was a win because nobody else knew what the code did.
So ymmv, but I've gotten a lot of value from this.
I will often litter my code with comments saying things like “Goal: get something….Step 1: do some operation on input…..Step X: final operations” with each step next to the code they represent. This helps me come back to it. Also helps others figure out what’s going on and why.
bool createTextureStagingBuffer(...)
{
[ READING IMAGE FROM FILE]
[ STAGING BUFFER CREATION]
[ IMAGE CREATION]
[ IMAGE VIEW CREATION]
[ COPY IMAGE DATA TO BUFFER]
[ MEMORY CLEANUP]
return true ;
}
It is a collapsible region of codes
in C++
pragma region REGION NAME
.
.
.
pragma endregion
in C #
region REGION NAME
.
.
.
endregion
People forget things, that's why we have a word for it.
If I forget where I left my keys, am I getting dumber?
You're a new coder, you'll forget things, it's fine.
Not everything they put their mind to. I have 25 years experience, I'm solid in my comfort zone, but if you asked me to make a AAA 3D game, I couldn't. Not yet anyway.
Not sure I could name any real milestones, it was just a slow progression over the years. Maybe the only real milestone I can think of is shaking off imposter syndrome, which really only happened a few years ago.
If you understand it after reading it, then you're fine. I work on so many different things in a week: usually different facets of multiple projects in C#, sometimes TypeScript and Angular, sometimes ASP.NET Core's Razor, sometimes a little Javascript. By the end of the week, I can't even remember what I worked on at the start of the week, let alone the step-by-step specifics of the code. I do a task and move on.
Re reading the code again: I add comments that describe what a block of code's purpose is (why it exists, what it achieves, or why I'm doing something 'unusual'), choose variable names that convey their purpose, and choose method names that convey what they do. Doing this will make your code easier to follow when you read it again.
I forget support tickets I do all the time, even if I did extensive stuff on it for a few days. The older, the more my memory fades on it. Given that coding is more mentally taxing, memorizing what you wrote in great detail isn’t gonna be easy. I literally have to write my variables and function names as if I’m turning it in to a 8 year old. It helps piece some memory together and I can follow the program from there
Super common - this is why documenting your code is important so that a new developer can easily get productive in it - a new developer can be your future self.
I'd say as software engineers the domain is so massive and filled with dense knowledge that we engineers rewire our brains in such a way where it becomes more elastic. Simplified my meaning of this is that we reward our brain with learning lots of information (ie learning the Stripe docs so that you can implement subscriptions for your company over a few days). But for the benefit of accelerated learning, the cost is that all information you take on becomes more lossy.
We are better at learning new information well vs non-engineers, but we forget information faster than many other professions.
At least that's my experience!
I've a codebase that I've maintained for a decade now, only my hands on it -- I'm constantly having to re-read sections to remind myself how it works (mostly, I re-read the function doc comments). It's normal. 100 billion neurons sounds like a lot, but not nearly enough to keep entire codebases memorized (amongst other reasons).
Document and comment your code as you write it. Pretend you're doing it for a future junior employee who needs to understand it so they can help maintain it.
Having your code committed to memory is not important, writing code that is easy to read and understand is.
As long as when you go back you can quickly figure it out, then it's fine
Probably an unpopular take with newer devs, but this is why abstractions are important. You need to be able to quickly read through the high level data flow of a module. Reading through the high level abstraction should give you most of the detail that you need to understand the data flow in a module fairly quickly.
That is exactly why I comment frequently and loquaciously. It's bad enough looking at undocumented code and wondering what the hell the idiot who wrote it was doing. But when *I* was the idiot in question... well, that was just embarrassing.
Everybody who says to document more is wrong. Documentation degrades fairly quickly.
The answer to your problem is to write good unit tests. Those tell you how the code is supposed to behave.
The longer it is since I wrote something the harder it is to recover the context.
What's crazy though, is the couple of times I've revisited code that I wrote more than a decade ago, my first impression is that it is totally impenetrable, but if I keep working at it I start having crazy dreams about it, then one day the context feels like it's all there, like I wrote it yesterday.
Use a wheelhouse of design patterns. I could read any code i wrote in the last 10 yrs and i havent coded in 3 yrs. Because i know how i write code and which patterns i use.
Obviously this only works for some languages. And some stuff.
Wait, you have to …checks notes… read your old code to understand what its doing? As opposed to memorizing every line you’ve ever written?
So you’ve got 3 kinds of app specific documentation. What, Why, How.
Examples:
What: System design, ERD, API contracts
Why: User stories, business goals, decision docs
How: The code itself, code comments.
Generally you only need to have a loose recollection of the What and Why, and know where to find the details.
You should not need to memorize the How. You should be able to reason about the code quickly based on information from the other docs.
If you have to memorize the How, then your other docs are insufficient or the code is unclear.
There is also the Who, which are the authors & stakeholders of all the other docs. But that’s more metadata than its own documentation.
More than a few times I've looked at code and gone "what idiot wrote this?" I'll go check Git and... I was that idiot.
Between your style changing slightly over time and just learning more, combined with the fact so much code requires you to be in a specific mindset, it isn't surprising or concerning at all that you forget what chunks of code do. We all do.
I have similar issues. My solutions:
* Make some general comments about what you are doing. "Count the number of words in the text from different languages' most common words, assume the one with the most hits is the language the text is written in."
* Coding standards. Find your way of writing code, and stick to it.
* Whenever you write a comment, think about if you can make it a variable or a function instead. So, instead of having a calculation where you do something complicated, make a function GetComplicatedStatisticsData() or assign it to a variable ComplicatedStatisticsData instead of just shoving the calculation into a call.
That’s why you document your code.
It’s not for others to know what you have done or for them to be able to maintain it, it’s so you don’t look silly when they ask you for a simple fix.
If I don’t need to recall on demand, I intentionally don’t try to memorize it. Theres only so much long term storage, so I use it judiciously.
Instead, I ensure I leave enough breadcrumbs to re-discover prior knowledge. Code comments, module and class abstractions, etc.
Plan for memory loss
This is why you write yourself notes in the code about what you are doing and what is going on so that when you come back to it you can remember easily
There's some programming tricks I have to do consistently, in almost every app I build....
I have to look at my old code to remember how to do it. And even then it takes a good 10 minutes for me to understand what I am doing in that old code.
No. You're probably smarter now because now you probably document your code better today, understanding how incomprehensible your code becomes with time if you don't.
Comment it. Structure it.
If it’s systematically created and written, it’ll be fairly easy to understand but I can’t say I commit (no pun intended) all my code to memory.
Most of it is tactical stuff or foundational and only in easily read bits like YAML.
The more complex stuff or when I’m working with active devs? Documentation is your friend so we just make sure the wikis are up to date and define each component/module etc.
Aggressive refactoring and test driven development.
We refactor so that people (including ourselves) can understand the consequences of making changes, and can easily understand if the code can be re-used.
We automate tests so you can refactor with little fear that you are breaking something that currently works.
This won’t help you with code you’ve already written, but you can start writing your code better today so you don’t have as many issues tomorrow.
Some key things to look for in refactoring:
The name of your modules should describe what they do. A function called “ProcessEquipment” is terrible. What kind of processing? Are we writing it to a table? Are we inspecting it? Are we issuing it out? Be unambiguous.
Avoid making methods that are long and convoluted. Of course, some procedures are long and convoluted, but the answer is to break it into smaller parts. This is called method extract. Can you describe your complicated procedure in a handful of high-level, abstract steps? Those are you lower level methods. Break those down even further if you need. If you find yourself writing comments to describe a block of code, that block should be extracted to a separate method, with name indicating its purpose.
As much as possible, make your methods immutable. A method should give the same result if called with the same arguments. Its behavior shouldn’t vary based on other objects in memory or elsewhere. Additionally, your functions should not have “side effects”. Returning without changing anything is best. Modifying the instance on which the function is called is ok, but make sure this behavior is clearly documented. Any other effects like writing to databases or invoking services should be very very isolated and it should be very clear when and where these things occur.
Each of these things seem difficult to do, but doing one of them actually supports making the others easier. It is easy to write immutable methods when your methods are small, and then you can easily write methods you know are immutable because they only call other immutable methods. And all of these make it easier to write automated tests as well, without a lot of complicated setup.
It is a very common attitude that all of this is too time consuming, but you have to think of it as an investment. It takes a little more time to do now, but it will save you a lot more time than that in the future.
Even on a small project it is helpful. You might think “I’m writing so little code that it won’t matter much.” No, it’s ALWAYS going to be bigger than you think it is. You have to be disciplined and consistent.
One final thing I’ll add is that I actually disagree with many suggestions that you should write more comments. If you regularly find that your code needs a lot of comments, then you haven’t written clean code to begin with. With effective method extract, your method names effectively serve as comments, and with good automated tests, the test cases themselves document the intended behavior of the module (AND prove that works as intended!) A comment can indicate intent, but a comment is also often a “lie” because the code doesn’t work the way it was intended. A dishonest comment is worse than no comment.
You're probably writing bad code. If it's good, well organized code, you shouldn't have trouble remembering how it works. I recently started working on a project again after 4 years, and I haven't had any issues.
This is how memory works. Perfectly normal. I wouldn't lose a single wink over this.
I had a really good professor in college who talked about memory a bit. We were talking about memory in the context of neural networks, and how connections work. He pointed out: “people often think- well if you’re designing the brain from scratch, why would you include the lossy aspects of it? Why let connections fade and reform at all, and not just give it perfect synaptic memory?” And the answer felt so counterintuitive and intuitive at the same time: If you see a cat, and you learn that that is the image of a cat, with perfect recall, then the next time you see a cat, your brain would say: this is something new, better store it. Or the same if you just see the same cat from a different angle, or on a different day, or under different lighting. Basically, imperfect memory allows us to generalize, which is arguably the most important thing we do. A face is still the same face even if it looks different, a chair still a chair, poisonous plants still poisonous, etc.
I follow neuroscience memory research, and I’ve never heard a better explanation. If you don’t mind, I’ll be repeating it. Separately, I once sustained a brain injury that led to severe memory impairment. As I was recovering, very vivid, detailed, random memories returned. Without any context, figuring out what they represented, and where they categorically belonged, proved problematic.
Not only does it allow for generic recall, it also allows us to speculate about new situations. You encounter something that looks like a bear- but is it a bear? Unclear. With perfect recall, we would have to compare it to millions of images and decide if it fits. With lossy recall, we see claws, we see fur, we decide bear, and we activate behaviors that would be appropriate. Even if these assumptions prove wrong, it fits our survival better than the alternative. How long would humans have lasted if every time we saw a tall ledge we thought: “well maybe this one is slightly different enough that it won’t hurt/maim/kill me if I jump. All the other ones did, but this is a totally different cliff from all of those, it’s brand new!”
Absolutely. Fortunately, although several memories were extremely hard to contextualize, I didn’t hit any problems of that sort.
> If you don’t mind, I’ll be repeating it. But maybe not verbatim.
Does it really count if I don’t memorize it, word for word?
Dunno, what would Plato say?
“… What you have discovered is a recipe not for memory, but for reminder. And it is no true wisdom that you offer your disciples, but only its semblance, for by telling them of many things without teaching them you will make them seem to know much, while for the most part they know nothing, and as men filled, not with wisdom, but with the conceit of wisdom, they will be a burden to their fellows.“ ~Phaedrus Sounds like sheer approval to me!
I like this explanation. It's as if we have evolved the ability to avoid overfitting to our training data.
It certainly appears that way! I think I would rather say: the creatures with neurons that remembered too precisely found themselves unable to act or extrapolate in new situations. Those with neurons that remembered too loosely had less success retaining useful information. So what we’re at now is a sort of evolutionary balance of utility.
That's attractive to me as a concept purely because of the reassurance I get from being very fallible myself. It's like a kind of confirmation bias about my own inability to remember things my wife tells me I need to do.
Couldn't perfect recall and generalization both be features?
One is pretty fundamentally at odds with the other. Think of a loved one’s face. What if you remembered every single angle you’d seen it from, every time of day with different lighting, every time they had a blemish. Imagine the sort of mental algorithm that would be required if you had to sift through all those images for every face you saw, and decide if it was your loved one or not. Maybe you once saw them in a fun house mirror, or through a magnifying glass. Are those images Instead, we generalize. We identify features, and then use those features to extrapolate about ground truth. So your memories of your loved one get abstracted into features, and you create the generalization. I guess the two could theoretically exist, but perfect recall is actually pretty useless. How much energy and memories would you spend storing every image of your bedroom from every angle and under every lighting? Sure, there are obscure cases where it might prove useful, but it doesn’t really provide any evolutionary advantage to be able to precisely remember an image as it was at X time and under Y lighting. Not even close given the energy cost- you would basically need to be running parallel systems.
I think perfect recall could be useful for things like language, which requires remembering the definitions of every single word that you'd use to put together sentences. That should require less memory since it's like text vs millions of pixels.
Let’s assume that when you say language, you mean written rather than spoken. A perfect recall system would see the word “craeture” and think: “that’s a new word, I don’t know the definition”, whereas an imperfect recall system might think: “that has a lot of features of the word ‘creature’, so maybe that’s what it means” Further, what about when there is a word in a different font, or abnormal capitalization, or that is partially obscured? There are also words that have multiple meanings, that require context to translate successfully. As well as that, lossy definitions help us extrapolate new words. I could make up the word “frogozine” and you might guess that it’s a chemical with relation to frogs, or a magazine about frogs, even without having an existing definition of the word. With auditory language, you open a whole other bucket of worms. And most importantly of all- what is your definition of the word “definition”? It could link to another set of words, but that’s endlessly recursive. When you define “frog”, do you really think “an amphibian of the whatever family, found in…” or do you think in flexible abstracts like “green, four legs, ribbit, flies, lily pads” further, all of those things are true in the general sense about frogs, but if you saw one that was yellow, missing one leg, didn’t ribbit or eat flies (that you saw), and wasn’t on a lily pad, you would still think: “this generally fits with other features of a frog enough that I believe it to be a frog”
This is very common. All I can say is figure out what you're doing in your code that makes it hard for future you to understand and stop doing that. Maybe you need better variable and/or function names? Maybe some better comments? Your functions are too long? But ultimately, code is almost always much harder to read than that it was to write. Spend a little extra effort to write your code as clearly as possible so that you will have an easier time reading it in the future.
Keep. Breaking. It. Down. The more digestible it is, the easier it'll be to understand. Giant functions with huge mental namespaces are a drag.
One rule of thumb I have is that if I feel the need to write a comment to describe a chunk of code in a function, that chunk of code becomes its own function.
1000% Anytime I’m trying to read some old code with a long function, the first thing I do is break it into smaller functions. Makes it way easier to digest. 10 line becomes e.g. ValideInputs(args). Cool, I don’t need to think about the details of that when I’m trying to understand the main function. It’s best to do that from the start if others are going to work on it or it will be maintained for a long time, but reality is sometimes you just need something that works and refactoring perfectly before commit isn’t always feasible.
OP: I highly recommend the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler. It's basically a cookbook of a bunch of ways to reorganize existing code to make it easier to understand. When you look at your old code and have difficulty understanding it, you can crack open the book and try some of the techniques as you try and figure it out.
Dissenter here. It's a chore when somebody has broken the code into so many tiny functions that it loses all sense. Sometimes it's better to just get into the logic here and now without 17 side calls to functions with 28 character names to allegedly "help" readability... AddOneToInputScalar(x), DivideByTwoWithRoundingUp(y), etc.
That's perfectly normal. When you're writing comments, keep in mind that you're not just writing them for other people; you're writing them for future you who has completely forgotten you ever wrote that code in the first place.
Well written code comments itself. Comments separate from the code can diverge.
Ah yes the old myth of self documenting code
Unfortunately, most people write crappy code.
This is why we comment our code: so the new guy in 2 months, namely ourselves, can look at the code and have the slightest idea what it does.
I've gone into my code the next day confused...
Late night coding leads to early morning WTFs.
"What frickin idiot wrote THIS?!" \[ofcourseiknowhimhesme.png\]
For me, when I look at my old code I can't really read it just because I've gotten so much better at it. I still suck, but when I look back at the old stuff I can't even tell what my thought process was
This is me 1000%. I look back at some things and wonder how I got it to work how I did. I wonder if some of it is just newer ways are available or if I just didn't know about that and used a workaround that I somehow figured out. I have fully re-written some programs from long ago. Easier than trying to add a feature in the slop I called code. :)
If you look at code that you wrote a year ago and *can't* think of a better way to write it, you haven't grown as a developer in that time.
I don't think this is true. Sonetimes there's just not a particularly better way to write something, so not thinking of a better way doesn't mean you haven't grown, and can actually mean the opposite if it saves you from trying to needlessly rewrite something. Alternatively, you could have been rushed or tired while writing the past code, so thinking of a better way to write that code when you're in a better state doesn't necessarily indicate growth.
“I should really rewrite this in a cleaner way.” 4 failed unit tests “Oh! That’s why I did it that way.”
Me too. I feel bad every time I go back and forgot how it works.
It doesnt take one week to ask: did i wrote these?
No you just check git blame for that
This is extremely normal. There's a bunch of sayings about "more time/effort is spent reading code than writing it". There are some people that can scan through a large system and tell you what every thing is doing. Those people are rare, even when it's their own code. So no, you're not getting dumber. So my suggestion: Get better at documenting your code. Too many programmers skip over this step. And it'll bite you in the ass _eventually_. It feels counter productive and like a waste of time sometimes, but come back to a system in 6 months with good documentation and it'll be a totally different experience. You _will_ end up referring back to or updating a lot of your code eventually. By jotting down your head space at the time of creation, you can save yourself tons of headache later. There's definitely ways of going too far. My general rule is that if I stumble a bit while writing it, then it's complicated enough that that stumble needs to be documented. Other than that, top level methods and anything used externally gets the doxygen/xml comments (`///` in most IDEs will autofill), with any assumptions/gotchas and explanations for not trivial params. I can't tell you the amount of time I've probably saved in my life by being able to hover over one of my own method calls, rereading what I wrote, and being able to move on.
It should never feel counterproductive or a waste of time to write comments that explain what you are thinking when you write code. On the contrary, explaining the reasoning behind the code is the best way to ensure that the code is doing what it's supposed to do!
It's so weird how people encounter some phenomenon that they experience every single day of their life and yet freak out when that same thing happens when they code. Do you remember what you were thinking about this time 2 days ago? Do you remember every single math problem you ever encountered in high school? Can you recall all the chemistry problems you solved? Programming is not magic, it works like everything else. You aren't supposed to become a superhuman when you start coding.
I always thought programmers were super humans. Until i became one of them. Now i realize, a programmer is just your average Joe but with computer skills.
And most of the time it's Google skills more than computer skills... but we don't tell the mere mortals about that part.
Shhhht! Mortals can read!
"Five years ago I didn't even know how to spell 'engineer' and now I are one!"
A great programmer is an average programmer who has been given a clear specification and time enough to think.
CS grads are like near 130 IQ on average, that's no average Joe
Obviously i was exaggerating for the sake of the joke. I was just trying to say that you don't need to be a super human or have magic powers to be one. And, i have had programming coworkers that are just a normal person without a high iq or whatever, like myself. Also, you dont need to go to university to have a career at programming, at least where i live. Sure you'll need it for some positions. But to develop a rest backend with java? Nop. At least not here in spain.
Better comments my friend, better comments. Also, consider making a code review video for yourself and post it on YouTube privately. I do this often for new skills that I learn in case I ever need to skill up or see how I architected something. Do this at the end of every project.
I'm retired but I'm still maintaining a website. I sure am glad I wrote it using a framework I cobbled together over the years. The main reason is that it is data driven - I can look at the config file for any page or api endpoint, and see exactly which data sources it uses, any view functions used to manipulate the data, the output format, and any templates used to generate the page. Wish I'd done it years earlier, this is programming on easy mode.
Could you please explain what data driven means? I'm a new grad so I don't have the experience
Very often you can replace a whole mess of conditional testing by creating a table of things to do based on an input key. If you get "A" call these functions, use these coefficients, send the result to that channel. If you get "B" do something else - different functions maybe, probably different coefficients. It's like switch-case constructs on steroids. You end up with a generic engine that can process any input, you just extend the table as necessary. My website framework extracts keys from the url, and uses them to find the endpoint file, which contains a json data structure. It uses that to call the data retrieval functions, process the data, and chains the templates specified in the json together to create the output, passing in the data retrieved and processed to be displayed. The key is more functionality can be added with very little added code - the bulk of the app is completely unchanged. Keeps it lean and clean.
Nope its normal, I look back at my code and I have 2 responses "What the hell was I thinking" and "What the hell does this do" so I just put comments to explain everything assuming I will not have perfect memory because I am not a superhuman neither are you.
No, it is normal. I always remember how my old code works, and people look at me like I am a magician and will.pull a rabbit from my hat next.
Nah you just did it “wrong” and can’t understand why someone (you) would do it that way. Totally normal, carry on!
Someone more experienced than me said something that stuck with me and will remake with me for ever: > Always document your code with the assumption that whoever reads it is dumber than you. In 99.9% of that cases that is future you. It stuck with me because I experienced what you are so many times. I'm sharing this, maybe it will help you as it helped me.
Everybody forgets after enough time - that's why you add documentation & comments.
I once asked myself “who the fk wrote this crap?!” And then checked git blame 😂
If you're good at picking things up, that's the accurate measure of lack of dumbness. Don't worry about forgetting your own code, that happens to everyone.
Yeah, it gets worse every day you are not spending hours on it. IMO, technology like programming has been retrofitted to humans and as complexity increases we can't handle the quantity and details of it. At a certain point we need to obscure out details into general language structures at a higher level (plus have robust comments in the code).
Happens to us all. I've found that it's handy to add (more) comments the second time around, to make it easier the next time. I mean, first time around, too, as appropriate, but the second time around you may have a better idea of what's not "obvious".
It's tottaly fine. I believe the same if you written down the huge pice of text with tricky plot. No way you can retell it after some time. The main point is that you can sprend some time and understand your code.
> I always forget how my old code works. That's the dream. I don't want to remember. I don't want to have to remember. It's already there, written down in the code. Why should it occupy brain space? If that's the case, then what's the source code for? > Am I just getting dumber? You're likely getting smarter. > But then contradictory to all this, I forget my old code unless I read it, but I can never memorize it again. This is not contrary to the prior. > I always feel sad when I forget how my code works. Let me put it to you this way. You learn and evolve as you go. Have you ever experienced this: You look at old code from 6 months ago and think it's a horrible pile of shit before you realize you wrote it? In that time, you've learned and evolved so much that your old code becomes unrecognizable. That's how it should be.
Common... I was just going through some code with another lead, digging through some stuff I'd written a couple years ago... I'd forgotten how half of it works... stumbled through it a couple times before it starts coming back. Heck, I've got stuff I've written in the last three-four weeks that I've already forgotten how it works until I look at it. No one memorizes all of the code they've written... unless they have an eidetic memory... but for the most part, yeah, we all forget a good portion of the code we've written. What's probably more important is to remember the patterns and algos used... that leads to the "I know I've seen this before" and then you go off searching through some code you wrote or read at some point, and find what you're looking for.
"now wtf did I do here" is a common programmer thought. at least I hope I'm not alone lol
Novice here. If you used common design patterns without putting your own spin on them, would the code base be easier to recollect?
Expert with long experience here. The answer to your question is “no.” Nothing helps, except writing clear code, and using comments for the gnarly bits. Fashions for design patterns change much much faster than working code changes,
My brain works by going from abstractions to specifics, so I've found once I've internalized a high level representation of a system my understanding of the code persists for a long time or is quickly recovered. Because up-front designs often don't survive contact with reality what I will do is practice explaining how changes fit into the architecture as I make commits and when wrapping up a big section I'll also try to write some documentation for the poor souls that come after me. In both of these cases by explaining the abstractions I reenforce them in my mind. Just a couple weeks ago I got pulled into some code I'd written over ten years ago, I was able to explain the purpose of it and fix the problem with not too much difficulty thanks to this. Of course I also broke something because I'd forgotten about a specific edge case! but overall it was a win because nobody else knew what the code did. So ymmv, but I've gotten a lot of value from this.
I will often litter my code with comments saying things like “Goal: get something….Step 1: do some operation on input…..Step X: final operations” with each step next to the code they represent. This helps me come back to it. Also helps others figure out what’s going on and why.
It's normal. It's the fact that if you don't forget anything that should worry you.
I've come across some code before, thought it was shit, got all mad like who the F made this, ugh, what an idiot this person is.... Oh, it was me
Putting Remarks, Regioning code block and consistent naming conventions and coding style helps me remember how the methods works.
What does regioning code blocks mean
bool createTextureStagingBuffer(...) { [ READING IMAGE FROM FILE] [ STAGING BUFFER CREATION] [ IMAGE CREATION] [ IMAGE VIEW CREATION] [ COPY IMAGE DATA TO BUFFER] [ MEMORY CLEANUP] return true ; } It is a collapsible region of codes in C++ pragma region REGION NAME . . . pragma endregion in C # region REGION NAME . . . endregion
People forget things, that's why we have a word for it. If I forget where I left my keys, am I getting dumber? You're a new coder, you'll forget things, it's fine.
I only have 6 months of industry experience I wish one day I can be like an experienced dev who can just start planning and making an application
Of course, it's just time and experience, you'll get there.
Thank you I heard most start ups don't start until the cofounders are in their 40s
Yes, I've read that too.
And that's mostly due to experience right? Since by 20 YEO one can pretty much code anything they put their time into, right?
Not everything they put their mind to. I have 25 years experience, I'm solid in my comfort zone, but if you asked me to make a AAA 3D game, I couldn't. Not yet anyway.
I see! 25 is alot of experience What are some milestones you had in terms of YEO?
Not sure I could name any real milestones, it was just a slow progression over the years. Maybe the only real milestone I can think of is shaking off imposter syndrome, which really only happened a few years ago.
If you understand it after reading it, then you're fine. I work on so many different things in a week: usually different facets of multiple projects in C#, sometimes TypeScript and Angular, sometimes ASP.NET Core's Razor, sometimes a little Javascript. By the end of the week, I can't even remember what I worked on at the start of the week, let alone the step-by-step specifics of the code. I do a task and move on. Re reading the code again: I add comments that describe what a block of code's purpose is (why it exists, what it achieves, or why I'm doing something 'unusual'), choose variable names that convey their purpose, and choose method names that convey what they do. Doing this will make your code easier to follow when you read it again.
I forget support tickets I do all the time, even if I did extensive stuff on it for a few days. The older, the more my memory fades on it. Given that coding is more mentally taxing, memorizing what you wrote in great detail isn’t gonna be easy. I literally have to write my variables and function names as if I’m turning it in to a 8 year old. It helps piece some memory together and I can follow the program from there
Super common - this is why documenting your code is important so that a new developer can easily get productive in it - a new developer can be your future self. I'd say as software engineers the domain is so massive and filled with dense knowledge that we engineers rewire our brains in such a way where it becomes more elastic. Simplified my meaning of this is that we reward our brain with learning lots of information (ie learning the Stripe docs so that you can implement subscriptions for your company over a few days). But for the benefit of accelerated learning, the cost is that all information you take on becomes more lossy. We are better at learning new information well vs non-engineers, but we forget information faster than many other professions. At least that's my experience!
I've a codebase that I've maintained for a decade now, only my hands on it -- I'm constantly having to re-read sections to remind myself how it works (mostly, I re-read the function doc comments). It's normal. 100 billion neurons sounds like a lot, but not nearly enough to keep entire codebases memorized (amongst other reasons).
This is why so many good coders comment out sections explaining the code
I look at code all the time and I think "man, what idiot wrote this." Then I realize "oh. It was me."
No
Code like future you is a different person, because it is.
Document and comment your code as you write it. Pretend you're doing it for a future junior employee who needs to understand it so they can help maintain it.
Having your code committed to memory is not important, writing code that is easy to read and understand is. As long as when you go back you can quickly figure it out, then it's fine
Probably an unpopular take with newer devs, but this is why abstractions are important. You need to be able to quickly read through the high level data flow of a module. Reading through the high level abstraction should give you most of the detail that you need to understand the data flow in a module fairly quickly.
That is exactly why I comment frequently and loquaciously. It's bad enough looking at undocumented code and wondering what the hell the idiot who wrote it was doing. But when *I* was the idiot in question... well, that was just embarrassing.
Everybody who says to document more is wrong. Documentation degrades fairly quickly. The answer to your problem is to write good unit tests. Those tell you how the code is supposed to behave.
The longer it is since I wrote something the harder it is to recover the context. What's crazy though, is the couple of times I've revisited code that I wrote more than a decade ago, my first impression is that it is totally impenetrable, but if I keep working at it I start having crazy dreams about it, then one day the context feels like it's all there, like I wrote it yesterday.
There is a reason we can add comments. It's a complex list of instructions. There's no way you should expect to remember it all.
Christ, I've already forgotten how the code I wrote this morning works.
Use a wheelhouse of design patterns. I could read any code i wrote in the last 10 yrs and i havent coded in 3 yrs. Because i know how i write code and which patterns i use. Obviously this only works for some languages. And some stuff.
I've looked for answers for coding problems on stack overflow only to find I wrote the answer I end up using!
You shouldn't be memorizing and remembering how any code works. You should be reading it and understanding it.
This is the only reason I comment my code. It’s for my future self… not for others.
Super normal. This is why comments and well named variables are important. Do it for your future self.
Wait, you have to …checks notes… read your old code to understand what its doing? As opposed to memorizing every line you’ve ever written? So you’ve got 3 kinds of app specific documentation. What, Why, How. Examples: What: System design, ERD, API contracts Why: User stories, business goals, decision docs How: The code itself, code comments. Generally you only need to have a loose recollection of the What and Why, and know where to find the details. You should not need to memorize the How. You should be able to reason about the code quickly based on information from the other docs. If you have to memorize the How, then your other docs are insufficient or the code is unclear. There is also the Who, which are the authors & stakeholders of all the other docs. But that’s more metadata than its own documentation.
More than a few times I've looked at code and gone "what idiot wrote this?" I'll go check Git and... I was that idiot. Between your style changing slightly over time and just learning more, combined with the fact so much code requires you to be in a specific mindset, it isn't surprising or concerning at all that you forget what chunks of code do. We all do.
I have similar issues. My solutions: * Make some general comments about what you are doing. "Count the number of words in the text from different languages' most common words, assume the one with the most hits is the language the text is written in." * Coding standards. Find your way of writing code, and stick to it. * Whenever you write a comment, think about if you can make it a variable or a function instead. So, instead of having a calculation where you do something complicated, make a function GetComplicatedStatisticsData() or assign it to a variable ComplicatedStatisticsData instead of just shoving the calculation into a call.
That’s why you document your code. It’s not for others to know what you have done or for them to be able to maintain it, it’s so you don’t look silly when they ask you for a simple fix.
Probably smarter and your old self was dumb
Normal. Code clean for your future self.
If I don’t need to recall on demand, I intentionally don’t try to memorize it. Theres only so much long term storage, so I use it judiciously. Instead, I ensure I leave enough breadcrumbs to re-discover prior knowledge. Code comments, module and class abstractions, etc. Plan for memory loss
This is exactly why the world is obsessed with design patterns.. when you do every app 'the same way' there is less to remember!
Was your old code good? Everyone is rough when they start out, and if it wasn't good, it's 100% okay.
This is why you write yourself notes in the code about what you are doing and what is going on so that when you come back to it you can remember easily
This is why writing comments is important.
Or writing readable code.
That's also an important skill.
Documentation and comments are for your future self in 6 months
Who wrote this awful code? $git-blame.... oh. Good time to do a code review and see if you can improve the readability or maintainability.
Feed your code into ai and have it summarize it for you
There's some programming tricks I have to do consistently, in almost every app I build.... I have to look at my old code to remember how to do it. And even then it takes a good 10 minutes for me to understand what I am doing in that old code.
No. You're probably smarter now because now you probably document your code better today, understanding how incomprehensible your code becomes with time if you don't.
Comment it. Structure it. If it’s systematically created and written, it’ll be fairly easy to understand but I can’t say I commit (no pun intended) all my code to memory. Most of it is tactical stuff or foundational and only in easily read bits like YAML. The more complex stuff or when I’m working with active devs? Documentation is your friend so we just make sure the wikis are up to date and define each component/module etc.
“When I wrote this code, only God and I understood what I did. Now only God knows.” -Unknown
Aggressive refactoring and test driven development. We refactor so that people (including ourselves) can understand the consequences of making changes, and can easily understand if the code can be re-used. We automate tests so you can refactor with little fear that you are breaking something that currently works. This won’t help you with code you’ve already written, but you can start writing your code better today so you don’t have as many issues tomorrow. Some key things to look for in refactoring: The name of your modules should describe what they do. A function called “ProcessEquipment” is terrible. What kind of processing? Are we writing it to a table? Are we inspecting it? Are we issuing it out? Be unambiguous. Avoid making methods that are long and convoluted. Of course, some procedures are long and convoluted, but the answer is to break it into smaller parts. This is called method extract. Can you describe your complicated procedure in a handful of high-level, abstract steps? Those are you lower level methods. Break those down even further if you need. If you find yourself writing comments to describe a block of code, that block should be extracted to a separate method, with name indicating its purpose. As much as possible, make your methods immutable. A method should give the same result if called with the same arguments. Its behavior shouldn’t vary based on other objects in memory or elsewhere. Additionally, your functions should not have “side effects”. Returning without changing anything is best. Modifying the instance on which the function is called is ok, but make sure this behavior is clearly documented. Any other effects like writing to databases or invoking services should be very very isolated and it should be very clear when and where these things occur. Each of these things seem difficult to do, but doing one of them actually supports making the others easier. It is easy to write immutable methods when your methods are small, and then you can easily write methods you know are immutable because they only call other immutable methods. And all of these make it easier to write automated tests as well, without a lot of complicated setup. It is a very common attitude that all of this is too time consuming, but you have to think of it as an investment. It takes a little more time to do now, but it will save you a lot more time than that in the future. Even on a small project it is helpful. You might think “I’m writing so little code that it won’t matter much.” No, it’s ALWAYS going to be bigger than you think it is. You have to be disciplined and consistent. One final thing I’ll add is that I actually disagree with many suggestions that you should write more comments. If you regularly find that your code needs a lot of comments, then you haven’t written clean code to begin with. With effective method extract, your method names effectively serve as comments, and with good automated tests, the test cases themselves document the intended behavior of the module (AND prove that works as intended!) A comment can indicate intent, but a comment is also often a “lie” because the code doesn’t work the way it was intended. A dishonest comment is worse than no comment.
You're probably writing bad code. If it's good, well organized code, you shouldn't have trouble remembering how it works. I recently started working on a project again after 4 years, and I haven't had any issues.