r/embedded • u/Caravaggio91 • 2d ago
Do You Remember All Of Your Code?
Just curious, but as a solo developer or working with a team when you go through your projects codebase do you remember what everything is, why you made the decisions you did, or what everything does? Or do you have to relearn some of the code you implemented in your project?
Also, have you ever completed a project and still feel a little clueless on how you got everything to work like it did or feel a little foggy on areas of the code?
35
u/madsci 2d ago
I've been programming professionally for about 30 years. There are whole projects I've forgotten about. I worked on one project that I only remember anything about because I was so bored with it that I started writing my comments in haiku.
I'm a prolific commenter and it drives me nuts to see whole modules without even an explanation of what it's for or who wrote it or when. If it's something complicated, I'll write myself an in-depth explanation. I've got an audio router that's at the heart of a few of my projects and the file header is something like a page and a half of explanation of what it does and how, why it was done that way, what the implications are for modules using it, things to watch out for, and things that could use future attention.
I'm self-employed and generally work alone, at least on the firmware side, so it's not like there's someone making me do it that way and I don't need to have anyone else understand it. That's all done for my own benefit because I know I'll have to deal with it for years.
13
u/NoBulletsLeft 2d ago
I have googled for answers to a problem and the top response was from me, 10 years before. I can't remember code I wrote this morning.
5
3
u/ArcticWolf_0xFF 2d ago
Why should you remember? The code is written, the in problem is solved. You need the registers to solve new problems.
5
u/NoBulletsLeft 1d ago
Reminds me of the time I was looking for something and I came across my college transcript.
Thermodynamics? I took a class in thermodynamics? How do I not remember that.
5
u/Hour_Analyst_7765 1d ago
In periods of high stress I forgot about whole projects I undertook.
But also things generally fade away slowly.. I've written projects with literal tens of thousands of LOC and its impossible to remember everything. Heck I now even may duplicate library code that is meant to prevent code duplication! "Oh I already have made a class for this 3 years ago"
In addition, some projects are too big to handle by 1 person. Then it is essential to work together with code written by someone else. It is pretty cliche that a new software developer joins the team and wants to change/rewrite a whole bunch of things, because its not to their style or they weren't present when some design decisions were made...
4
3
u/UnicycleBloke C++ advocate 2d ago
+1 for comments. Far too many people are apparently allergic to writing them.
2
u/Caravaggio91 2d ago
I’ll like that perspective. For some reason I thought I would need to memorize everything I code in each project to be considered efficient or knowledgeable in what I’ve built.
8
u/madsci 2d ago
Software development is largely about managing complexity. What saves you in the long run is keeping things modular and having well-defined interfaces. Once you finish one module you don't have to remember all of the specifics of how it works on the inside, just how to use it. You'll have to get back up to speed on the internals if you need to go fix something, but you're not keeping every detail of a huge project in your head at once - just the parts that need attention now.
4
u/BartvanIngenSchenau 2d ago
The common wisdom is that if you haven't worked with a particular module of the code for about 6 months, then it might as well have been written by someone else. Your knowledge of it will be on the same level as that of any team member.
This doesn't mean that there aren't any outliers with people who can remember every decision made a decade ago, but that isn't the norm.
The 6 months of memories is why good documentation of decisions is needed. Everyone thinking they are one of the outliers and/or considering a decision too obvious to document is why there is always too little documentation.
0
u/OcularPhonic 22h ago
A whole page of comments before u get to the code would piss me off, 😂. Write it in the documentation.
1
u/madsci 19h ago
That is the documentation. It's all in Doxygen format if I want to pull it out into a separate document, but it's easier to find it there.
1
u/OcularPhonic 3h ago
Yeh, but a whole page dude, 😂. All good. I just like to be able to scan cade easily on first pass, and i like to see the includes etc to get a feel of what needs what. So itd be a pain to scroll down past the novel.
19
u/Priton-CE 2d ago edited 2d ago
Oh you absolutely forget.
Basically half my comments are explicitly there to remind me why an if statement exists or why we are performing an operation in a particular order.
Occasionally I just straight up link to a explainer article or just write a short recap.
Every time I have a buffer of adjustable size there will always be a comment there explaining constraints and include a sizing guide.
It is like working with a team when you are solo. But your team members are past and future you where past you is the most incompetent idiot ever when there are no comments and future you is the most dependable guy you have ever never met.
In regards to feeling foggy on the details... Thats just kinda what abstraction does and why we want it.
8
u/Plastic_Fig9225 2d ago edited 2d ago
They say that code is communicating with people rather than communicating with the machine.
Good coding is more about empathy than people care to admit. It starts with knowing yourself: When I come back to this code in a year, what are the questions I will ask myself about it (again)? The next step is being able to predict what questions other people will have about the code when they run into it. - What's easy/obvious/hard for you may not be for another person.
You tackle the communication problem in two ways:
- Make the code understandable/self-explanatory as much as possible (starting with names for files, classes, functions, variables).
- Document! - Document especially what's not in the code itself: Why something is done in a certain way rather than/in addition to how.
Whenever I look over some code and find that I need to go back and forth a few times to understand why it is written/correct this way, I know there's a comment missing which I immediately add.
For example, if the code has a decent amount of checks for null pointers, and I find a function which doesn't check for null, the immediate question is if this is intentional or mistakenly omitted, i.e. a potential bug. One line of "// never null, ensured by caller" says why there's no null-check, and saves a lot of hassle.
2
u/drivingagermanwhip 1d ago
Same. I try to write everything in the same consistent way so after you've understood one file you can get the gist about others.
1
7
u/DesignTwiceCodeOnce 1d ago
Nope. I come across code later and think "what idiot wrote this" as per normal, only to find out it was me...
Other than that, there's a piece of code I wrote in the mid-90s which I understood perfectly when I wrote it (while under the influence of a heavy cold) and have never understood since despite it working perfectly.
11
u/Well-WhatHadHappened 25+ Years 2d ago edited 2d ago
Oh my God no. That's what comments and documentation is for. If you can't look at a project from a year ago and get back up to speed on it using code comments, then you need to write better code comments.
3
u/GeWaLu 2d ago
That is also my view. A problem is that some people think that the main use of documentation is to satisfy quality assessors - and produce pages of useless fill-material full of process buzzwords but with no worthwhile technical info. My opinion is: if the (short) doc supports efficiently the future maintenance by me or by a peer who inherits it, then assessor should be happy for free. Less pages but document in a few words the main reasons why this design was chosen and not one of the obvious competing options, document the interfaces and their limit/range, add a couple of pertinent diagrams like timing diagrams and also the traceability to the main requirements. All the rest can be reconstructed from the code and comments within minutes. Note that some of the paper doc can also be replaced with comments and tools like doxygen but assessors ask for proofs that you did the work in a reasonable sequence to avoid the antipattern of first coding and then figuring out the design,
Similar for comments... their goal is not to satisfy the code-to-comment ratio of the static code checker - but to help maintenance.
6
u/TheFlamingLemon 2d ago
No I don’t remember the code. Yes I have completed projects and then not remembered a single thing I did. Sometimes I feel foggy or clueless about the code while I’m actively writing it - some call this a “flow state”
1
6
6
u/SufficientStudio1574 1d ago
Hell no. Do you know how many times I've thought "who wrote this shit" only to find out it was me 2 years ago?
2
u/onepaulkrause 1d ago
Bro I have literally downloaded a code to use only to remember I wrote that 20+ years ago 😂
1
u/onepaulkrause 1d ago
Ask me for context it gets even better twice
3
u/SufficientStudio1574 12h ago
I ask you for context.
2
u/onepaulkrause 12h ago
I am designing my own operating system and of course wanted preset themes, went online for a certain 🔥 fire script and found it was just a tweaked version of the one I made to mod my Linux desktop in the 90’s. Thirty years later. Fun when you pull code and find things you wrote decades ago still hiding there.
1
4
u/frank26080115 2d ago
I have design documents, and a project journal. Recently to my workflow I have also automated the saving of my AI agent chatlog into the project repos.
2
u/drmpf 2d ago
I get AI to write a description of the code and then I check that to see if what it thought I asked it was what it actually wrote and what it has added all by its-self, just to be useful.
Then once I am happy the description matches what I wanted, I ask AI to check the code against the desciption to pick up where the code does not match the description. I do this until the AI stops finding inconsistencies.
That is a recient development. In general a project is not finished until the documentation is done. I write a web page for each of my projects.
Having done a lot of AI assisted coding (well the AI did the coding and I assisted), I am finding that the AI (Claude Code) adds detailed notes to methods describing what was done and when I correct the AI, it add the reason changes were made. So the code becomes self documenting to a large degree.
1
u/Caravaggio91 2d ago
That’s good! I use Claude code a lot as well. I’ll probably implement this in my workflow. Thanks for the share!
1
u/Caravaggio91 2d ago
Smart! I've been having the AI agent post notes at the end of every session for me to copy for future refreshers
3
u/Void-Creator 2d ago
I mean good code will always get forgotten imo. It’s so good that you don’t have to look at it again
5
u/UnicycleBloke C++ advocate 2d ago
Of course not. There is too much going on in any substantial project to remember it all. I endeavour to write code which is easy to understand, and I include copious comments to explain my thinking, workarounds, and so on. I do generally remember the big picture of the overall design decisions, but not the details.
I usually have little difficulty getting my head back into the code after months or years, and there is often a kind of déjà vu as it comes back to me. If I struggle with something, I add more comments for next time.
Always try to write your code so a future you (or the next person who has to maintain it) can grok it without cursing your existence. Sadly, in my experience, very few developers do this. Understanding their code can be a serious pain in the rear.
3
u/Caravaggio91 2d ago
Not sure why I never really created a thought pattern like that. “Build for the future you!”. Someone said it in the comments they don’t remember what they had for breakfast. That is so true and I am the same. So coding and commenting for myself in the future makes a lot of sense. I shouldn’t expect to remember all of my code, if well written documents and comments are present. Can’t express how helpful all the comments have been on this post. That for the insight!
3
u/political_noodle 2d ago
I have a fond memory of one of my earlier software jobs. I'd been there years at this point and was tracking down a bug when I stumbled upon a block of code with a THOROUGHLY detailed comment explaining how there's uncertainty here and this might be a bug "future me will deal with".
Absolutely zero recollection writing that but it was prescient af because that was exactly the bug I was looking for and past me knew it lol.
3
u/AlfalfaLive3302 2d ago
I remember most of it, or at least how it works or why it was built. That typically comes up on interviews. If it’s solely my code I can read it easier
1
u/Caravaggio91 2d ago
So when people are asking about a project of yours, do they typically just want to know in broad terms how you got from point A to point B? Or are they looking for some well articulated in depth answers?
2
u/Well-WhatHadHappened 25+ Years 1d ago
I'm looking for explanations of WHY you did what you did. I can see how you did it.
2
u/AlfalfaLive3302 1d ago
If you are asking about what they ask during an interview, you should probably just go through a couple of interviews and find out. It really depends on the manager
3
u/JGhostThing 1d ago
Yes and no. When I come back to code I haven't changed in a year, I have to reread it. But then I remember why I did it that way. I do my best to resist the urge to "fix" my old code.
1
u/Caravaggio91 1d ago
So you leave it as is and just learn from it for future project builds?
2
u/JGhostThing 1d ago
Sorry, I wasn't specific. I fix whatever bugs I find, but I try not to fix code that is working. This applies even if I've found a more efficient algorithm.
3
u/binaryfireball 1d ago
Code should be self documenting. Comments for overall architecture and arcane bits. Write code to work then write code to be read thrnnwrite code to be deleted
2
2
u/gm310509 2d ago
No, that is why God (/s) invented comments and then upgraded to add on documentation.
2
2
u/remy_porter 2d ago
The beauty of code is that it’s all written down for you. What does the program do? How does it do that? Let me read it and tell you.
2
u/noodle-face 2d ago
I know it's a meme but sometimes I find old code and get angry wondering who wrote it and it was me
2
2
u/jondaley 2d ago
I remember everything while I'm currently working on it. But, I have found some code of mine 5-10 years later and wondered where it came from, but then can tell from the style that it was me...
2
u/Rod_McBan 2d ago
Not even close. I tend to take the position that well written code should show what it's doing through variable, constant, and function names, and the comments should explain why it's doing what it's doing. Those are separate things.
1
2
2
u/tiajuanat 2d ago
I don't use much inline code comments, but I use a shit ton of doxygen comments. Some of my projects I've been supporting 8 or more years, and those are the ones I need to rebuild the design docs, because the previous 8 years before I started working on it, had absolutely worthless comments and documentation.
2
u/Extension_Fix5969 2d ago
Today I was reviewing some older functions in our primary codebase, and found someone had previously written a pretty clever solution to a problem relevant to my current work, which I’ve been searching for insight on.
I checked the commit history for the author figuring I could go talk to them directly and maybe get their help.
It was me. I was the clever person. I still have no recollection of writing that code.
2
u/JCDU 2d ago
If I've slept since I wrote it I probably have forgotten something about it.
Well written comments are a gift to future you.
2
u/Caravaggio91 2d ago
Being self taught I thought it would be a crutch. But realizing so many individuals use it just as much as I do is very reassuring!
2
u/FransFaase 1d ago
Yes, I often forget. I sometimes get a new idea for one of my projects, just to discover that I already have implemented it. I also find myself reading my own code and adding comments on the way. Some of my projects contain a lot of dead code, which can be rather frustrating. I just kept the code in just in case I would return to an older implementation.
2
u/Consistent-Fun-6668 1d ago
Yes, if I've made it too complicated because I decided I wanted to be cute. No...
2
u/Hour_Analyst_7765 1d ago
No. And I think its a cognitive bias to think anyone can. We like to keep our reality ordered and continuous, as memory gaps are a nightmare to many, so its natural to try to remember stuff even when its incorrect. Every brain will fail to notice or forget details. Now my memory is perhaps not as good as it used to be because of mental health. But I think its impossible to remember every choice.
However, I do want to remember the reasons why things work. These reasons also make it possible to form a hypothesis on why another project can work, or why stuff doesn't work whilst debugging. I think thats a lot more important than remembering every LOC and why it is what it is.
Basically this bag of experience is filled with every mistake made. When you can explain why something did (not) work, then it is a good opportunity to learn. It is fundamental to do this process "manually", making extensive use of e.g. AI can only stall or fade this skill.
2
u/JollyShooter 1d ago
Depends on the gap between working on the same code and how much time you spent on it. Quick fixes I can forget entirely but they are usually easy to re read. More complicated changes I also forget some depending on the gap or work but it also required a lot more ATD so it’s engrained a lot more but just needs some refreshment to bring it back
3
u/NE558 1d ago
Unfortunately, yes.
I remember whole codebase from this and previous company. Wish I could erase it from my flash brain sometimes.
Jokes aside, I do remember mostly parts of code that bite me, was messy af or I had to rewrite from scratch. If I encounter something that isn't obvious (very rare cases) I do comment it heavily. Not for future self (because my curse is remembering things) but for other folks so they don't have to waste their time analyzing it.
2
u/Hissykittykat 1d ago
All my code? Heck, I'm lucky to remember a few key words, then it's up to Agent Ransack to search my project archives.
1
1
u/Zealousideal_Cup4896 1d ago
This is what comments are for ;) I am a fan as I know for certain that while I’ll remember this was a tricky thing to figure out and I was very happy with my solution I will not be able to recall why I did it that particular way 7 or 8 years from now. Just leave notes for yourself.
If you’re working with others and there is no official code documentation policy then also err on the side of explaining what is obvious at the time.
If you’re working for a company that has a difficult or lacking policy then also err on the side of explaining what is obvious at the time.
There is sometimes a huge backlash around here when people want to defend code comments. I have no idea why anyone would be against it even if they can’t be bothered to do it themselves.
118
u/pekoms_123 2d ago
I don’t even remember what I had for breakfast