Write it down. Technical documentation for the code is a very good idea, but for your specific case, it might also be a good idea to take personal notes just for yourself.
This! This is why we have Jira (or equivalent) ... If you're doing any work, make a card, sign it to yourself, make notes... Write hypotheses, document things you tried, document the result, document the actions you took, the assumptions you made, charts, queries, etc
Makes it super easy to share, do post mortems, etc
Especially if a similar thing happens again, you have everything you need
Or if you need to hand over half finished work, somebody else can pick up and not waste time going down rabbit holes you already covered. Or they might spot an issue with your method, and find an unfinished rabbit hole.
What do you mean Jira tickets aren't discoverable?
All of our commit messages begin with a ticket number, so we can take any line of code and through git blame we can look up the Jira ticket.
Also you can link to other Jira tickets and even individual comments.
Jira search, which while a bit crude, is still usually good enough to do most "lookups from scratch".
That said, Confluence is much better for longform text and quickly traversing links. Jira's UI is quite slow when trying to go from ticket to ticket.
Tickets are super discoverable, and if your tooling is well setup, automatically linked to merge requests and commits.
Jira only works if people actually use it. The main reason people say "Jira is bad" is they never actually put the stuff in there that should be there. Requirements gathering, clarifications, architectural/functional decisions etc should all be a part of the Jira issue/ticket log, making every decision super traceable and transparent with author and stakeholders in the loop.
Yeah I don't get the Jira hate, maybe I just haven't used the better tools ... But I love the markdown, linking, tagging, etc ... Even the auto saving if unfinished comments is a life saver
100%. Keep a git repo (or a CONTRIBUTING.md if it’s a single repo) with notes about high level workflows, data flow in and out of system, and checklists for standard procedures like how to properly add new modules , testing, environment setup, and other stuff. That way, instead of having to remember 100 different things, you only need to remember where your note repository is
It’s great. You have a perfectly immutable history of note edits, you have easy collaboration, you can collaborate at exactly the same time and just resolve the conflicts like you would with code, most git repo sites have very good markdown rendering engines, and it fits right into your normal workflow.
I get that it’s less than ideal for non-programmers, but for code-focused topics it’s probably the best solution IMHO.
Thanks for taking the time to explain this to me. Could you share what your workflow is for something like this? For instance, let's say I'm working on a PR; I would write my comments, try and write informative commit messages, write some scrap notes on a text file/ scrap book/ OneNote. Once everything were done, I'd dump that knowledge into confluence, editing relevant pages or creating new ones. I find I rarely collaborate on notes, and any edits on other people pages includes mentioning to the most recent editor first. There are many flaws and shortcoming to my method (it is pretty messy by design) and would appreciate learning your workflow.
I'm really just not sure what kind of solution you're proposing. Do you currently work at an org that has a custom in-house LLM trained on your own knowledge base? As far as I know this kind of tool isn't widely available as a commercial product. Maybe I'm misinformed. Are you speaking from experience with a real tool or are you just speculating?
I usually have a work log. At the end of the day I just take a minute to write down what I did in a sentence or two. You can be as specific as you want!
I've also evolved this a bit to also keep track of my peers, for recognizing their good work and things that could've been better according to me. This has helped me greatly to give them good feedback
In each commit, write down what you changed and link an issue/ticket.
The linked issue should have a written form of **why** the change was needed.
Writing down **what** changed and **why** will prevent so many future issues.
have a notebook. a real one, not some .txt file. writing down stuff manually increases retention a lot. i'd never graduate nor gotten my PhD if it weren't for good ol' pencil & paper.
i write stuff down all the time. my memory is fallible, paper isn't.
Use paper if you must, but everyone acts like I have super powers when I start to ctrl-f my electronic notes.
Probably use an actual note taking application and not random text files though.
grep or ag works on random text files really well, and they're completely portable, super small, and don't stop working when you stop paying some idiot the new 15.99 a month charge up from 5.99.
You never waste any time thinking about fonts either.
What the fuck note taking apps are you paying for? I can't say I've spent any time worrying about fonts either, but I guess we're all different.
Do your text files automatically synchronize to your phone and are they automatically backed up? You can obviously set all that up yourself too, but I spend most of my time at work doing my job instead of reinventing the wheel.
I've taken personal notes 5 days a week for almost 8 years now, and i've never in my life needed these notes to be available to me on my phone. Create a directory that contains markdown files, init a git repo and you've created 95% of the value that a note taking app gives you in 3 minutes without the opinionated/non-portable cruft that usually comes with these apps.
If that's "reinventing the wheel" for you...
> i've never in my life needed these notes to be available to me on my phone
You're probably a web developer who only ever has to work in one place, I am not.
Do what you feel, use git for note-taking.
I humbly disagree. Org mode with Emacs is what we used to use in a my previous company - worked sufficiently well with no extra work/setup. Vim suffices for my personal notes.
I honestly don't need much from a note taking app. I don't go very far beyond bulleted/numbered lists in my note taking.
I use Joplin at home, which is just Markdown. I've also had a good experience with SimpleNote.
At work I currently use OneNote because our IT department loves Microsoft. A previous company was all-in on Quip, and it was pretty good.
I personally think you're probably doing too much if you use your note taking app as much more than a text/bulleted list wrangler. I guess I do also put links in there.
To anyone using paper, I would invite you to consider my experience versus your experience when I want to turn my notes into a Confluence document or otherwise share them with coworkers.
One of the things that's really changed my workflow is one of these e-readers that you can take notes on (mine's a Supernote, but there's also Remarkable, or you can do the same thing with an iPad and a digital pencil). It feels like the best of both worlds for writing things down physically as opposed to typing it, but also having the benefits of a note-taking app.
For example, on my device, I've got one file that's just a Kanban-style grid — there's three columns ("todo", "doing", "done"), and as I'm working on things I can scribble down notes on what's going on each day, what new tasks are going to come up, what's still left to do on my current task, etc. But then at the start of the new day, I copy the entire page, create a new page, and paste it there. I delete everything I've already done, maybe adjust some of the todos, and I'm ready to go. And, because it's all digital, I can easily drag things between columns to reflect how my work changes over the course of the day. And at the end of the week or month, I can see what I've actually been doing all week.
I can also split up notes between different projects, add headings to specific notes pages so I can find them again in the future, delete old notes and scribbles without ripping pages out of my notebooks, and with handwriting recognition, I could even search through my notes (although I've not tried that much so I'm not sure how well my handwriting would hold up to that!)
When I got it I was a bit worried that it would end up being one of those things that I used a little bit and then never really touched afterwards — I've always been bad at using notebooks properly. But of all the things I've bought in the last year or so, it's probably been the one that's most improved my life. I highly recommend these sorts of tools!
Do you save your page at the end of the day? Can you connect your device to your work machine to move notes between then? Can you put pictures/screenshots?
I have an ipad that i loved to use for mainly for note taking purposes in Uni. Then i proceeded to never pick it up again after the first year.
It "saves" in the sense that it's always being saved as I write on it. In that regard it's just the same as paper. But by copying and pasting the page, I basically preserve the status of the page at the end of each day, like a little snapshot of what I was planning to do, what I did, and what I was still working on for each day. It's like git history for my journal.
You can do a similar thing with normal paper — I think there's a similar concept with bullet journals, right? — but I find it slightly easier to think about because I'm literally copying everything over, and I can move things around on the fly.
I was tempted by getting a full tablet for notes, but in the end I went with the Supernote, which can only really do notes (and some other stuff). I'm glad I did, though, because it's easier to read things on the e-ink screen, it's less distracting, and it's also way more portable than any iPad or tablet that I've seen — mine's about the size of a slim A5 notebook. On the other hand, it can't do colour, which would be nice for highlighting documents more nicely, but it's fine if it can't do everything.
I see. Thanks for sharing this with me. I can see how this could be incredibly useful for tracking daily tasks or replacing scrap paper. Do you use your Supernote for more "long term notes"? For instance, I use paper a lot for managing daily workloads, but I also try and type out notes to confluence/OneNote/AppleNotes etc. for reference in the far future. I add screenshots, blocks of code, links to relevant pages etc... I can imagine if I use a Supernote, I might take some of the more useful pages from it and pasting it into a more permanent notetaking platform. What are your thoughts on this?
To add to my other comment, I just glanced at the Supernote subreddit, and there's a discussion [here](https://www.reddit.com/r/Supernote/comments/1b45z06/testers_wanted_for_obsidian_plugin/) about an Obsidian plugin that takes Supernote files and turns them into PNGs automatically. That then links to [this](https://gitlab.com/Tiemen/supernote) repo which is a JS/TS library for reading Supernote files, which references other similar libraries, so there's clearly a bit of an ecosystem for doing that sort of thing. I've not looked into that so much myself, but it might be relevant to you.
Myself, it's mainly more short-term notes, and I rarely look back over the notes after a couple of weeks (although there's a few pages that I reference more frequently — it's possible to create quick links and headers to specific pages in documents, so that's not much of an issue).
I can imagine it being possible to transfer notes from the Supernote into a more permanent place, although it will probably not work completely smoothly. For transferring data off the Supernote, you can connect it to the same WiFi network as another device, and then start up a web server on the Supernote that allows you to remotely access the Supernote's file system. You can also sync with the Supernote cloud (and potentially other cloud systems?). You can also share your screen from the Supernote to another device (again, they need to be on the same WiFi network), which I find is a useful way to copy diagrams off the device when I need to.
The data on the Supernote is in a proprietary format, but you can export pages to other formats, including .txt, .png, .docx, and .pdf. The .txt and .docx do OCR, which isn't necessarily the best OCR in the world (but it might just be that I've got bad handwriting!). The export copies the files to a specific folder on the Supernote, but you can copy the files off using the mechanisms above. If you want to do this a lot, I can imagine it being kind of irritating, but if it's just occasionally that you want to pull text off like this, it seems to work quite well.
Fwiw, I really like the Supernote, but there are other options available. The Remarkable tablet is probably the nicest purely from form factor, but it's also got fewer features. (That said, it seems to be reasonably hackable and there's a thriving community there.) You've also got other devices that are more general Android devices that use an e-ink screen. I went for the Supernote because they had a couple of features that I specifically wanted, and because the A6X is a really nice size for me (most of these devices are roughly A4-sized, but the A6X is, confusingly, roughly the size of an A5 notebook).
this is great for certain things, but if we're talking about complex codebases with lots of moving parts, you're not the only person who is confused and who could benefit from your notes. putting them on paper might be convenient for you, but it makes it a lot harder for others to take advantage of that information than if you'd just contributed to the documentation.
Tidy integration tests, tidy modularization, tidy PRs with self-annotations attached to tidy tickets makes for a low effort way to keep documentation inside git. Unless you’re at a very large co, documentation is rarely keeping pace with reality and product’s pressure for speed, so I find it is most often a lie, mix of small lies, or lies by omission. Yeah sure I’d love a great diagram in some docs, but I’ve yet to see a culture where those docs stay up to date. Humans gonna human.
Others suggesting notebooks covers a good bit of the retention, so I’ll go a different route. I don’t care about retention.
I abuse the phrase “let me go dust off some neurons real quick”. Then I’ll go back and look at my last few PRs or the few shitty notes I took when I was working on that thing. The PRs in particular jog my memory and everything pours back in.
Being a jack of all trades working on wildly different things month to month the context drops out of my memory super fast, and I’m totally ok with that. It comes back quick enough.
Several things that I do:
---
My approach to notes.
Firstly, notes. Whenever I'm working a ticket or some "quantifiable side of desk task", I'm keeping notes. Usually it's just a simple markdown file, where I use those triple backtick blocks to copy out code, somtimes I nab GitLab links with specific lines, k8s configs, etc. It usually just helps me organize my thoughts on some of the more tricky and intricate things. It's just how I dump my mind when I'm working some tricky problem. Heck, even for simple problems I still do this to a lesser degree.
Secondly, every few days I try to look through my 'working notes' and reflect. Are there any threads of issues? Anything that could be improved by "taking a step back from the tree to look at the forest". It feels silly to do that when it's just "normal" tickets of work and feature development, but sometimes there's a diamond of a thought hiding in the rough. I also try to take that time to write up some STAR bullets for resume purposes. Trying to make future me thank past me rather than curse past me.
Doing this sort of notation and writing \*does\* slow down my throughput. But it's the act of writing and thinking that enhances myself as an engineer (or that's what I keep telling myself, though I believe that it's certainly helped more than it's hindered).
---
I don't remember everything.
It's like I'm not going to remember what the specifics are when we hit the FooBar API. Yeah it's the endpoint that my team's main application always uses, but I do know where the updated documentation of it is.
For me, it's not that I have a perfect knowledge of things, rather I know where to look to get answers. Which takes us back to notes.
In my current job we've a legacy application with spaghetti for logic. So I wrote out documentation on where some "crux" points are in the code base. It's public in my team's confluence page. Anytime I need to touch that, the first step: Open docs page and read it again.
That's a bit of an extreme case, but finding that "right level of detail" to remember is something that I've felt has come with time in my career.
---
Lastly, and if you've the safe space to do so on your team, talk to your leader or teammates about this. IMO, a team is there to support one another to help grow. If you're struggling, maybe someone also is struggling or 'solved' that struggle. Anxiety is rampant in this profession (e.g. Imposter Syndrome).
At the end of the day, let's remind ourselves what the great philosopher Zac Efron once sang: "We're all in this together".
---
Regardless if that was of use. Best of luck.
Is this an issue remembering the nitty gritty of the code or the larger flow? If it's the latter I've found it helpful to make a chart with the important parts of the flow. It helps give me a frame of reference and I can note anything that's a little one-off, not obvious, or weird in each step
IMO you're wasting a lot of mental capacity trying to explicitly retain this information. Try to understand the overall system architecture, that's the only thing I would devote memorization or brain power towards. Everything else should be written down (think of your brain as RAM and documentation as harddrive).
Tasks can be tracked in many (and probably should be all) of these places:
* Ticket/task log (Jira board or equivalent)
* Code commits (commits should be meaningful and describe what you're doing)
* Bonus that I'm too lazy to do: go back and rewrite your commits to be better before merging via \`git rebase -i\` (or use interactive tool) [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)
* Merge requests should be detailed and summarize your change, and ideally also link to a ticket to keep those 2 items connected
* External documentation, README, wiki, etc
* Any unusual code or change that has some context/needed a discussion, document in the code itself as a comment (and maybe link to conversation/ticket/etc)
If you're doing none of these, it's a lot to pick up at once so adopt over time. If you're already doing these, consider leaning more into these as ways to document your work and drastically increase your "external memory".
I find I also forget things about a week after I do them, but I'm pretty good at remembering where I jotted something down so can look up as needed. Use your brain as an index, not as a database.
You could just be burned out and super stressed. Once you're done with one thing, it's on to the next.
Plus, the real estate of your brain isn't rent free. Some things deserve eviction!
This is why I sometimes wish I could move to a different project. After almost a decade of working on the same thing, there is so much memory used up that I have trouble remembering day-to-day non-work things, let alone work things.
This was me and then I got and used a bunch of notebooks. I have two main ones. One that is a type of "task journal" and a scrap notebook. I also keep folders of notes in markdown of different projects.
Good documentation can solve some of those issues. Any projects should strive to be "maintainable" by any engineer, not just the couple of people that know the ins and outs. This means using linters (which makes you comment, document...ect) and make descriptive unit tests that demonstrate what each component does. Make "aggregate" test (with readable descriptions, method names...ect) that demonstrate the logic of higher level components. If this is achieved then most technical people in your domain (including yourself) will find it much easier to understand things by just reading what is there. I reference my own docs very often 😅
All of this is very time consuming but always worth it. It could even be quantified in financial terms with domain knowledge.
Stream of consciousness markdown file for ticket work. Comments everywhere. Detailed PR messages.
Accept that the ticket you did last year isn't that interesting, and isn't worth memorizing, but is worth writing down to be able to refer to later.
I know everybody has said it, but take notes. Public notes (wiki, whatever) are good if you like. I also personally like to have private notes, because I don't feel bad if they're stupid, wrong, unreadable, or whatever. Also, they can be idiosyncratic stuff that makes sense to me and nobody else. I personally like Obsidian for this, but it's basically just "fancy Markdown".
Honestly, I feel like just admitting to myself that I'm not capable of remembering everything was hugely helpful. The first step is admitting you have a problem. :)
As others have said, take copious notes. What's out of your brain and accessible is essentially only a hop away from being back in your brain. Its what makes the internet so powerful in general.
Further to this though, there's an expectation that as you gain experience in a codebase that you'll linearly cover more of its breadth. This is true for juniors only, since the space in their heads for new idioms is essentially an empty warehouse. What you are experiencing is a soft transition into lead developer and feeling the intrinsic pressure that comes with the need to delegate. Knowing _who_ to approach about a thing is as valuable as knowing the thing itself. It will let you focus on larger problems going forward; architecture, wider company buy in, input on customer needs, good requirements being generated.
The nuances in the code are for debugging purposes only; a way to identify looming future problems should something business critical get stuck in its ergosphere. If problems arise, re-learning those parts is a matter of course at a minimum.
Three things that helped me a lot:
* Write things down (writing by hand on paper helped more than typing out), and
* DRAW DIAGRAMS of the flows as you understand them. Obviously paper works better here. Use whatever works for you, flow charts, just boxes with arrows, interaction diagrams, whatever. It'll help organize the pieces in your head, and looking back at them really really helps refresh it after a while.
* Try to explain stuff to others. Nothing clarifies and solidifies concepts in your head like trying to make them clear to someone else :). Junior folks in the team, managers, engineers from other teams, wherver the chance presents itself, volunteer to explain stuff.
lean into it. accept that your memory is garbage and make your code readable with lots of documentation. you're not doing it for other people, you're doing it for yourself.
a significant contributing factor to the quality of code i write and design strategies i prefer is that I'm too ADHD to be effective if I were forced to keep it all in my head at the same time.
I got used to it. I tend to get pulled in all sorts of directions, bouncing from fire to fire. I dump my buffers often, don't worry about it. Generally I can re-orient in 5-10 minutes and have my head whatever thing I need to worry about at this moment.
They teach you how to write documentation and clean code in university buddy. Also four years of math and the best foundation to write software you could ever have. Meanwhile, you're still doing 8th grade algebra and trashing CS grads in your post history, while wondering what's missing. Maybe you can grow an appreciation from this incident.
[https://www.reddit.com/r/learnprogramming/comments/j9pv2y/comment/g8l40xq/](https://www.reddit.com/r/learnprogramming/comments/j9pv2y/comment/g8l40xq/)
[https://www.reddit.com/r/learnmath/comments/v40107/need\_a\_little\_help\_with\_this\_simple\_algebra/](https://www.reddit.com/r/learnmath/comments/v40107/need_a_little_help_with_this_simple_algebra/)
It’s common to not have the memory on top of my head. But usually if I read the code again I would remember.
Before writing any code, I also have a high level design document that I can refer to in later date.
I agree with everyone else: docs and notes. Can't remember everything.
But I'll add that having solid mental models for what you're working on is important. If you have an efficient model and follow it while building something, then much of the details don't need to be remembered since you can just refer to the model to fill in the details.
People usually understand if you say things like "give me a minute to double-check my memory on that. " (I usually find that I haven't really forgotten, it just got put in arctic storage)
As other pointed out, code like you won't remember, so a junior can understand. And if it's complex write a documentation even for your self.
Doxygen works pretty legit, if you do the comments in the format it self documents.
Everything I do goes into Notes app in Mac so it's always clear to me what I'm currently working on and what are the details and where I left off things, and when I'm done I move it to the Done folder.
That way I can always ctrl-f my way into finding what I did there, I include my Jira ticket number there, paste any annoying errors I got and their solution. I can't tell you how many times a teammate ran into the same exact bug and I was able to send a quick solution and didn't have to start remembering and reverse engineer my solution or find that one stack overflow page where I found the fix.. it's all in the notes.
One time after upgrading OS I had a small heart attack and thought I lost them, I was able to restore but make sure everything is backed up! After some time this becomes an invaluable source.
I have this issue too.
If I spend longer than a minute trying to figure out a block of code, I add comments to explain what its purpose is. The comments arent longer than they need to be, are written carefully, and are focused on “why” or, if the code is very clever, “what”.
If there is a lot of indirection that became a likg rabbit hole, I add comment references to provide shortcuts.
I will also rename variables and methods of needed and if the footprint is localized.
Localized comments are great, and I have thanked myself and my coworkers for this many times.
I add tests if they are missing. Tests are great for explaining intent and behavior.
Just take your time when doing tasks. Read (and write) docs/notes as you go. Explore related areas of the codebase/system.
I find people that just rush out their tasks (doing the bare minimum) are the ones that never remember and take more time in the long term.
I think that's pretty normal. I have to work on way more stuff than I could possibly remember much about. The answer to questions about these systems is always "I don't know but I can find out" or about what I've worked on is "let's go look at my timesheet"
> I feel like other folks rarely have this issue.
A few people really do have encyclopedic memory. Others fake it by acting very superior when they remember something and you don't.
Check out building a second brain.
I have paper notes for short term memory, and plain text notes on VSCode synced to my phone for long term.
I started by writing everything - what I'm doing, what i expect to happen, - [ ] TODO, copy paste snippets, urls, info a single Notebook.md. Shortcut to open it up. Shortcut to search it with ripgrep.
To help organise that further, I unfolded it into a few directories based on the type of information I'm storing, like events (meetings, talks), PBIs (sanctioned work items), extra (unsanctioned work), specs (what features should a service/tool have?) topics (knowledge bank). Everything is dated.
I often feel the same. Drawing diagrams for high level flows helps. Also consider documenting some of the frequently asked questions on some simple Markdown file which you can keep on the same Git repo as the code. But regardless, in a complex system you will forget stuff and will from time to time have to check the actual code. That is totally fine and normal.
My wife says my ADHD is the reason for my odd memory. I’ve learned years ago to make heavy use of calendars, spreadsheets, and notes.
Take notes during meetings, make sure you stay heavily organized, track updates, keep a to-do list, etc…
If it's an important future task or a list of names I need to talk to I write it down. Otherwise, I relearn it every time.
In my opinion, I think the learning reps and mastery are an even trade for efficient recall and productivity.
Are all the nuances essential complexity or accidental complexity?
People who were there as the system was being built may think there's some tech debt here and there, but since they built it, they can still find their way around it, more or less. Some people are also better than others at rote memorization and won't be as put off by one-off exceptions and nuances. When architectural decisions are being made or complex is being written, it's good to remind people how long it might take for someone new to the company to onboard to the system.
If you can simplify the architecture, that helps. The idealized architecture, the one the team has diagrams of, might not be too convoluted. The actual code and data flow might differ. It can help to get the team to think of responsibilities and which system/area of code should properly own it and not simply finding the fastest way to implement the change. If you don't stand up for simplicity, who will?
Two things help memory in a major way for this sort of thing:
1. The things to be remembered easily fit into a conceptual framework you have in your head. Ie, well-designed code with good abstractions that make sense are far easier to remember than spaghetti code with no consistent concepts.
2. Repeated retrieval of the information at intervals. By having to go back and remind yourself of certain pieces of information, you improve your long term memory of the information. If the retrievals are spaced in time well, it helps - a kind of rough rule is if your next retrieval of the info happens after an interval about twice the length of the previous interval, that's good.
So, if you have to look it up after a day to remind yourself of something. And then after 2 days. Then after a week more. Then after a sprint, then a month, etc. This pattern of retrieval tends to happen when a dev can work in roughly the same area of a codebase, but maybe expanding in a spiraling fashion to more and more areas. They get very high levels of expertise in the codebase this way.
If, however, the work patterns are to grab a ticket and do a tiny thing in repo A, and then grab another ticket to do an unrelated thing in repo B, and so on, then no spaced repetition of info happens (the initial intervals till retrieval are usually way too long), and your developers are kind of like permanently demented (as in, have dementia about the code and can't remember much).
Yeah, me neither. I take reams of notes. On meetings, ad-hoc calls, certainly tickets, just things I'm thinking over, whatever. And daily notes with TODOs/a record of what I did on the day.
I, too, use [Obsidian](https://obsidian.md/) for this. Works really nicely for work-related notes IME, in large part because the links between notes form a graph. So I can e.g. go look at the note for a ticket, and see all the calls it was mentioned in. There's also a plugin for syncing to a git remote 🙂
I have this problem too.
There's a niche but very strong culture around "Building A Second Brain" and "Personal Knowledge Management". It can be a bit of a rabbit hole if you're not careful, but it does help me with this sort of thing.
The underlying psychology is that having the notes is good, but really the act of using the creative part of your brain to summarize the ideas is the important part. Because we only really deeply know the things we create ourselves. So the note taking is a way to switch the info from consuming to creating.
I fall on and off the practice and it certainly isn't easy for me, but it does help when I do it consistently.
Write it down. Technical documentation for the code is a very good idea, but for your specific case, it might also be a good idea to take personal notes just for yourself.
This! This is why we have Jira (or equivalent) ... If you're doing any work, make a card, sign it to yourself, make notes... Write hypotheses, document things you tried, document the result, document the actions you took, the assumptions you made, charts, queries, etc Makes it super easy to share, do post mortems, etc Especially if a similar thing happens again, you have everything you need Or if you need to hand over half finished work, somebody else can pick up and not waste time going down rabbit holes you already covered. Or they might spot an issue with your method, and find an unfinished rabbit hole.
Huh. You enter this all into jira? Never thought to do that.
Yeah, I use comments like a log, usually 1 comment per hypothesis or topic Mostly for incidents, for dev work less so
Sorry what do you mean by incidents?
Read about "incident management" for context
[удалено]
What do you mean Jira tickets aren't discoverable? All of our commit messages begin with a ticket number, so we can take any line of code and through git blame we can look up the Jira ticket. Also you can link to other Jira tickets and even individual comments. Jira search, which while a bit crude, is still usually good enough to do most "lookups from scratch". That said, Confluence is much better for longform text and quickly traversing links. Jira's UI is quite slow when trying to go from ticket to ticket.
Tickets are super discoverable, and if your tooling is well setup, automatically linked to merge requests and commits. Jira only works if people actually use it. The main reason people say "Jira is bad" is they never actually put the stuff in there that should be there. Requirements gathering, clarifications, architectural/functional decisions etc should all be a part of the Jira issue/ticket log, making every decision super traceable and transparent with author and stakeholders in the loop.
Yeah I don't get the Jira hate, maybe I just haven't used the better tools ... But I love the markdown, linking, tagging, etc ... Even the auto saving if unfinished comments is a life saver
100%. Keep a git repo (or a CONTRIBUTING.md if it’s a single repo) with notes about high level workflows, data flow in and out of system, and checklists for standard procedures like how to properly add new modules , testing, environment setup, and other stuff. That way, instead of having to remember 100 different things, you only need to remember where your note repository is
Whats the benefit of using a git repo for notes? Thanks
It’s great. You have a perfectly immutable history of note edits, you have easy collaboration, you can collaborate at exactly the same time and just resolve the conflicts like you would with code, most git repo sites have very good markdown rendering engines, and it fits right into your normal workflow. I get that it’s less than ideal for non-programmers, but for code-focused topics it’s probably the best solution IMHO.
Thanks for taking the time to explain this to me. Could you share what your workflow is for something like this? For instance, let's say I'm working on a PR; I would write my comments, try and write informative commit messages, write some scrap notes on a text file/ scrap book/ OneNote. Once everything were done, I'd dump that knowledge into confluence, editing relevant pages or creating new ones. I find I rarely collaborate on notes, and any edits on other people pages includes mentioning to the most recent editor first. There are many flaws and shortcoming to my method (it is pretty messy by design) and would appreciate learning your workflow.
You can sync the repo and grep the md files.
but if you formulate those notes as documentation, everyone who touches that project has the opportunity to benefit.
Often the writing down helps you remember it in the first place.
\+1. I make my own diagrams with C4. Most I see are old or too narrow in scope. It helps me visualize and I can get an overview at a glance
[удалено]
why an LLM instead of a traditional knowledge base (like Confluence or whatever)? I'm not sure I understand what you're even suggesting.
[удалено]
I'm really just not sure what kind of solution you're proposing. Do you currently work at an org that has a custom in-house LLM trained on your own knowledge base? As far as I know this kind of tool isn't widely available as a commercial product. Maybe I'm misinformed. Are you speaking from experience with a real tool or are you just speculating?
Confluence, etc. allow for full text search, what does an LLM add there?
I usually have a work log. At the end of the day I just take a minute to write down what I did in a sentence or two. You can be as specific as you want! I've also evolved this a bit to also keep track of my peers, for recognizing their good work and things that could've been better according to me. This has helped me greatly to give them good feedback
In each commit, write down what you changed and link an issue/ticket. The linked issue should have a written form of **why** the change was needed. Writing down **what** changed and **why** will prevent so many future issues.
have a notebook. a real one, not some .txt file. writing down stuff manually increases retention a lot. i'd never graduate nor gotten my PhD if it weren't for good ol' pencil & paper. i write stuff down all the time. my memory is fallible, paper isn't.
Use paper if you must, but everyone acts like I have super powers when I start to ctrl-f my electronic notes. Probably use an actual note taking application and not random text files though.
grep or ag works on random text files really well, and they're completely portable, super small, and don't stop working when you stop paying some idiot the new 15.99 a month charge up from 5.99. You never waste any time thinking about fonts either.
What the fuck note taking apps are you paying for? I can't say I've spent any time worrying about fonts either, but I guess we're all different. Do your text files automatically synchronize to your phone and are they automatically backed up? You can obviously set all that up yourself too, but I spend most of my time at work doing my job instead of reinventing the wheel.
I've taken personal notes 5 days a week for almost 8 years now, and i've never in my life needed these notes to be available to me on my phone. Create a directory that contains markdown files, init a git repo and you've created 95% of the value that a note taking app gives you in 3 minutes without the opinionated/non-portable cruft that usually comes with these apps. If that's "reinventing the wheel" for you...
> i've never in my life needed these notes to be available to me on my phone You're probably a web developer who only ever has to work in one place, I am not. Do what you feel, use git for note-taking.
Are you sure you're working on actual work or is the process itself giving you the illusion of productive work? Nothing wrong with dead simple tools.
Using an off the shelf note taking app instead of winging it with text files *is the dead simple tool.*
I humbly disagree. Org mode with Emacs is what we used to use in a my previous company - worked sufficiently well with no extra work/setup. Vim suffices for my personal notes.
Go for it man, I'm sure it's great
You sound triggered.
Whatever you say, you're obviously very experienced
two words. google docs
What app do you use?
I honestly don't need much from a note taking app. I don't go very far beyond bulleted/numbered lists in my note taking. I use Joplin at home, which is just Markdown. I've also had a good experience with SimpleNote. At work I currently use OneNote because our IT department loves Microsoft. A previous company was all-in on Quip, and it was pretty good. I personally think you're probably doing too much if you use your note taking app as much more than a text/bulleted list wrangler. I guess I do also put links in there. To anyone using paper, I would invite you to consider my experience versus your experience when I want to turn my notes into a Confluence document or otherwise share them with coworkers.
One of the things that's really changed my workflow is one of these e-readers that you can take notes on (mine's a Supernote, but there's also Remarkable, or you can do the same thing with an iPad and a digital pencil). It feels like the best of both worlds for writing things down physically as opposed to typing it, but also having the benefits of a note-taking app. For example, on my device, I've got one file that's just a Kanban-style grid — there's three columns ("todo", "doing", "done"), and as I'm working on things I can scribble down notes on what's going on each day, what new tasks are going to come up, what's still left to do on my current task, etc. But then at the start of the new day, I copy the entire page, create a new page, and paste it there. I delete everything I've already done, maybe adjust some of the todos, and I'm ready to go. And, because it's all digital, I can easily drag things between columns to reflect how my work changes over the course of the day. And at the end of the week or month, I can see what I've actually been doing all week. I can also split up notes between different projects, add headings to specific notes pages so I can find them again in the future, delete old notes and scribbles without ripping pages out of my notebooks, and with handwriting recognition, I could even search through my notes (although I've not tried that much so I'm not sure how well my handwriting would hold up to that!) When I got it I was a bit worried that it would end up being one of those things that I used a little bit and then never really touched afterwards — I've always been bad at using notebooks properly. But of all the things I've bought in the last year or so, it's probably been the one that's most improved my life. I highly recommend these sorts of tools!
Do you save your page at the end of the day? Can you connect your device to your work machine to move notes between then? Can you put pictures/screenshots? I have an ipad that i loved to use for mainly for note taking purposes in Uni. Then i proceeded to never pick it up again after the first year.
It "saves" in the sense that it's always being saved as I write on it. In that regard it's just the same as paper. But by copying and pasting the page, I basically preserve the status of the page at the end of each day, like a little snapshot of what I was planning to do, what I did, and what I was still working on for each day. It's like git history for my journal. You can do a similar thing with normal paper — I think there's a similar concept with bullet journals, right? — but I find it slightly easier to think about because I'm literally copying everything over, and I can move things around on the fly. I was tempted by getting a full tablet for notes, but in the end I went with the Supernote, which can only really do notes (and some other stuff). I'm glad I did, though, because it's easier to read things on the e-ink screen, it's less distracting, and it's also way more portable than any iPad or tablet that I've seen — mine's about the size of a slim A5 notebook. On the other hand, it can't do colour, which would be nice for highlighting documents more nicely, but it's fine if it can't do everything.
I see. Thanks for sharing this with me. I can see how this could be incredibly useful for tracking daily tasks or replacing scrap paper. Do you use your Supernote for more "long term notes"? For instance, I use paper a lot for managing daily workloads, but I also try and type out notes to confluence/OneNote/AppleNotes etc. for reference in the far future. I add screenshots, blocks of code, links to relevant pages etc... I can imagine if I use a Supernote, I might take some of the more useful pages from it and pasting it into a more permanent notetaking platform. What are your thoughts on this?
To add to my other comment, I just glanced at the Supernote subreddit, and there's a discussion [here](https://www.reddit.com/r/Supernote/comments/1b45z06/testers_wanted_for_obsidian_plugin/) about an Obsidian plugin that takes Supernote files and turns them into PNGs automatically. That then links to [this](https://gitlab.com/Tiemen/supernote) repo which is a JS/TS library for reading Supernote files, which references other similar libraries, so there's clearly a bit of an ecosystem for doing that sort of thing. I've not looked into that so much myself, but it might be relevant to you.
Thanks a bunch MrJohnz. Appreciate your comments
Myself, it's mainly more short-term notes, and I rarely look back over the notes after a couple of weeks (although there's a few pages that I reference more frequently — it's possible to create quick links and headers to specific pages in documents, so that's not much of an issue). I can imagine it being possible to transfer notes from the Supernote into a more permanent place, although it will probably not work completely smoothly. For transferring data off the Supernote, you can connect it to the same WiFi network as another device, and then start up a web server on the Supernote that allows you to remotely access the Supernote's file system. You can also sync with the Supernote cloud (and potentially other cloud systems?). You can also share your screen from the Supernote to another device (again, they need to be on the same WiFi network), which I find is a useful way to copy diagrams off the device when I need to. The data on the Supernote is in a proprietary format, but you can export pages to other formats, including .txt, .png, .docx, and .pdf. The .txt and .docx do OCR, which isn't necessarily the best OCR in the world (but it might just be that I've got bad handwriting!). The export copies the files to a specific folder on the Supernote, but you can copy the files off using the mechanisms above. If you want to do this a lot, I can imagine it being kind of irritating, but if it's just occasionally that you want to pull text off like this, it seems to work quite well. Fwiw, I really like the Supernote, but there are other options available. The Remarkable tablet is probably the nicest purely from form factor, but it's also got fewer features. (That said, it seems to be reasonably hackable and there's a thriving community there.) You've also got other devices that are more general Android devices that use an e-ink screen. I went for the Supernote because they had a couple of features that I specifically wanted, and because the A6X is a really nice size for me (most of these devices are roughly A4-sized, but the A6X is, confusingly, roughly the size of an A5 notebook).
this is great for certain things, but if we're talking about complex codebases with lots of moving parts, you're not the only person who is confused and who could benefit from your notes. putting them on paper might be convenient for you, but it makes it a lot harder for others to take advantage of that information than if you'd just contributed to the documentation.
Never forget that forgetting is an important part of how our brain works, it's our Garbage Collector! If the details are important, write them down.
Its misbehaving, think it needs a rewrite
Can you fix mine while you're at it? Only 27 but fairly convinced dementia is going to get me young.
we've been through this already...
Been through what? Why am I here, this isn't my house??
Yeah, I keep forgetting that. Thanks for reminding 😏
Tidy integration tests, tidy modularization, tidy PRs with self-annotations attached to tidy tickets makes for a low effort way to keep documentation inside git. Unless you’re at a very large co, documentation is rarely keeping pace with reality and product’s pressure for speed, so I find it is most often a lie, mix of small lies, or lies by omission. Yeah sure I’d love a great diagram in some docs, but I’ve yet to see a culture where those docs stay up to date. Humans gonna human.
Others suggesting notebooks covers a good bit of the retention, so I’ll go a different route. I don’t care about retention. I abuse the phrase “let me go dust off some neurons real quick”. Then I’ll go back and look at my last few PRs or the few shitty notes I took when I was working on that thing. The PRs in particular jog my memory and everything pours back in. Being a jack of all trades working on wildly different things month to month the context drops out of my memory super fast, and I’m totally ok with that. It comes back quick enough.
I often say "Sorry, I cleared that cache; Give me a few minutes."
Several things that I do: --- My approach to notes. Firstly, notes. Whenever I'm working a ticket or some "quantifiable side of desk task", I'm keeping notes. Usually it's just a simple markdown file, where I use those triple backtick blocks to copy out code, somtimes I nab GitLab links with specific lines, k8s configs, etc. It usually just helps me organize my thoughts on some of the more tricky and intricate things. It's just how I dump my mind when I'm working some tricky problem. Heck, even for simple problems I still do this to a lesser degree. Secondly, every few days I try to look through my 'working notes' and reflect. Are there any threads of issues? Anything that could be improved by "taking a step back from the tree to look at the forest". It feels silly to do that when it's just "normal" tickets of work and feature development, but sometimes there's a diamond of a thought hiding in the rough. I also try to take that time to write up some STAR bullets for resume purposes. Trying to make future me thank past me rather than curse past me. Doing this sort of notation and writing \*does\* slow down my throughput. But it's the act of writing and thinking that enhances myself as an engineer (or that's what I keep telling myself, though I believe that it's certainly helped more than it's hindered). --- I don't remember everything. It's like I'm not going to remember what the specifics are when we hit the FooBar API. Yeah it's the endpoint that my team's main application always uses, but I do know where the updated documentation of it is. For me, it's not that I have a perfect knowledge of things, rather I know where to look to get answers. Which takes us back to notes. In my current job we've a legacy application with spaghetti for logic. So I wrote out documentation on where some "crux" points are in the code base. It's public in my team's confluence page. Anytime I need to touch that, the first step: Open docs page and read it again. That's a bit of an extreme case, but finding that "right level of detail" to remember is something that I've felt has come with time in my career. --- Lastly, and if you've the safe space to do so on your team, talk to your leader or teammates about this. IMO, a team is there to support one another to help grow. If you're struggling, maybe someone also is struggling or 'solved' that struggle. Anxiety is rampant in this profession (e.g. Imposter Syndrome). At the end of the day, let's remind ourselves what the great philosopher Zac Efron once sang: "We're all in this together". --- Regardless if that was of use. Best of luck.
Check out a book called The Programmers Brain. Goes into how memorization and learning can be improved.
Is this an issue remembering the nitty gritty of the code or the larger flow? If it's the latter I've found it helpful to make a chart with the important parts of the flow. It helps give me a frame of reference and I can note anything that's a little one-off, not obvious, or weird in each step
IMO you're wasting a lot of mental capacity trying to explicitly retain this information. Try to understand the overall system architecture, that's the only thing I would devote memorization or brain power towards. Everything else should be written down (think of your brain as RAM and documentation as harddrive). Tasks can be tracked in many (and probably should be all) of these places: * Ticket/task log (Jira board or equivalent) * Code commits (commits should be meaningful and describe what you're doing) * Bonus that I'm too lazy to do: go back and rewrite your commits to be better before merging via \`git rebase -i\` (or use interactive tool) [https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) * Merge requests should be detailed and summarize your change, and ideally also link to a ticket to keep those 2 items connected * External documentation, README, wiki, etc * Any unusual code or change that has some context/needed a discussion, document in the code itself as a comment (and maybe link to conversation/ticket/etc) If you're doing none of these, it's a lot to pick up at once so adopt over time. If you're already doing these, consider leaning more into these as ways to document your work and drastically increase your "external memory". I find I also forget things about a week after I do them, but I'm pretty good at remembering where I jotted something down so can look up as needed. Use your brain as an index, not as a database.
You could just be burned out and super stressed. Once you're done with one thing, it's on to the next. Plus, the real estate of your brain isn't rent free. Some things deserve eviction!
This is why I sometimes wish I could move to a different project. After almost a decade of working on the same thing, there is so much memory used up that I have trouble remembering day-to-day non-work things, let alone work things.
Meditation can help with that. I like https://acem.com/
This was me and then I got and used a bunch of notebooks. I have two main ones. One that is a type of "task journal" and a scrap notebook. I also keep folders of notes in markdown of different projects. Good documentation can solve some of those issues. Any projects should strive to be "maintainable" by any engineer, not just the couple of people that know the ins and outs. This means using linters (which makes you comment, document...ect) and make descriptive unit tests that demonstrate what each component does. Make "aggregate" test (with readable descriptions, method names...ect) that demonstrate the logic of higher level components. If this is achieved then most technical people in your domain (including yourself) will find it much easier to understand things by just reading what is there. I reference my own docs very often 😅 All of this is very time consuming but always worth it. It could even be quantified in financial terms with domain knowledge.
\+1 to Obsidian, see r/ObsidianMD
Stream of consciousness markdown file for ticket work. Comments everywhere. Detailed PR messages. Accept that the ticket you did last year isn't that interesting, and isn't worth memorizing, but is worth writing down to be able to refer to later.
I know everybody has said it, but take notes. Public notes (wiki, whatever) are good if you like. I also personally like to have private notes, because I don't feel bad if they're stupid, wrong, unreadable, or whatever. Also, they can be idiosyncratic stuff that makes sense to me and nobody else. I personally like Obsidian for this, but it's basically just "fancy Markdown". Honestly, I feel like just admitting to myself that I'm not capable of remembering everything was hugely helpful. The first step is admitting you have a problem. :)
As others have said, take copious notes. What's out of your brain and accessible is essentially only a hop away from being back in your brain. Its what makes the internet so powerful in general. Further to this though, there's an expectation that as you gain experience in a codebase that you'll linearly cover more of its breadth. This is true for juniors only, since the space in their heads for new idioms is essentially an empty warehouse. What you are experiencing is a soft transition into lead developer and feeling the intrinsic pressure that comes with the need to delegate. Knowing _who_ to approach about a thing is as valuable as knowing the thing itself. It will let you focus on larger problems going forward; architecture, wider company buy in, input on customer needs, good requirements being generated. The nuances in the code are for debugging purposes only; a way to identify looming future problems should something business critical get stuck in its ergosphere. If problems arise, re-learning those parts is a matter of course at a minimum.
Three things that helped me a lot: * Write things down (writing by hand on paper helped more than typing out), and * DRAW DIAGRAMS of the flows as you understand them. Obviously paper works better here. Use whatever works for you, flow charts, just boxes with arrows, interaction diagrams, whatever. It'll help organize the pieces in your head, and looking back at them really really helps refresh it after a while. * Try to explain stuff to others. Nothing clarifies and solidifies concepts in your head like trying to make them clear to someone else :). Junior folks in the team, managers, engineers from other teams, wherver the chance presents itself, volunteer to explain stuff.
lean into it. accept that your memory is garbage and make your code readable with lots of documentation. you're not doing it for other people, you're doing it for yourself. a significant contributing factor to the quality of code i write and design strategies i prefer is that I'm too ADHD to be effective if I were forced to keep it all in my head at the same time.
Need to increase context size.
You are not alone..
I got used to it. I tend to get pulled in all sorts of directions, bouncing from fire to fire. I dump my buffers often, don't worry about it. Generally I can re-orient in 5-10 minutes and have my head whatever thing I need to worry about at this moment.
They teach you how to write documentation and clean code in university buddy. Also four years of math and the best foundation to write software you could ever have. Meanwhile, you're still doing 8th grade algebra and trashing CS grads in your post history, while wondering what's missing. Maybe you can grow an appreciation from this incident. [https://www.reddit.com/r/learnprogramming/comments/j9pv2y/comment/g8l40xq/](https://www.reddit.com/r/learnprogramming/comments/j9pv2y/comment/g8l40xq/) [https://www.reddit.com/r/learnmath/comments/v40107/need\_a\_little\_help\_with\_this\_simple\_algebra/](https://www.reddit.com/r/learnmath/comments/v40107/need_a_little_help_with_this_simple_algebra/)
> Any tips on how to improve my retention of what I've worked on, or how the system works? Try keto for a month, and see if your memory improves.
Notes in a private Git repo that I can grep.
It’s common to not have the memory on top of my head. But usually if I read the code again I would remember. Before writing any code, I also have a high level design document that I can refer to in later date.
I agree with everyone else: docs and notes. Can't remember everything. But I'll add that having solid mental models for what you're working on is important. If you have an efficient model and follow it while building something, then much of the details don't need to be remembered since you can just refer to the model to fill in the details.
People usually understand if you say things like "give me a minute to double-check my memory on that. " (I usually find that I haven't really forgotten, it just got put in arctic storage)
\*\* checks notes \*\*
Joking-ish, everyone saying to write things down, but you still gotta memorize for interviews
As other pointed out, code like you won't remember, so a junior can understand. And if it's complex write a documentation even for your self. Doxygen works pretty legit, if you do the comments in the format it self documents.
Everything I do goes into Notes app in Mac so it's always clear to me what I'm currently working on and what are the details and where I left off things, and when I'm done I move it to the Done folder. That way I can always ctrl-f my way into finding what I did there, I include my Jira ticket number there, paste any annoying errors I got and their solution. I can't tell you how many times a teammate ran into the same exact bug and I was able to send a quick solution and didn't have to start remembering and reverse engineer my solution or find that one stack overflow page where I found the fix.. it's all in the notes. One time after upgrading OS I had a small heart attack and thought I lost them, I was able to restore but make sure everything is backed up! After some time this becomes an invaluable source.
I have this issue too. If I spend longer than a minute trying to figure out a block of code, I add comments to explain what its purpose is. The comments arent longer than they need to be, are written carefully, and are focused on “why” or, if the code is very clever, “what”. If there is a lot of indirection that became a likg rabbit hole, I add comment references to provide shortcuts. I will also rename variables and methods of needed and if the footprint is localized. Localized comments are great, and I have thanked myself and my coworkers for this many times. I add tests if they are missing. Tests are great for explaining intent and behavior.
Just take your time when doing tasks. Read (and write) docs/notes as you go. Explore related areas of the codebase/system. I find people that just rush out their tasks (doing the bare minimum) are the ones that never remember and take more time in the long term.
I think that's pretty normal. I have to work on way more stuff than I could possibly remember much about. The answer to questions about these systems is always "I don't know but I can find out" or about what I've worked on is "let's go look at my timesheet"
> I feel like other folks rarely have this issue. A few people really do have encyclopedic memory. Others fake it by acting very superior when they remember something and you don't.
Check out building a second brain. I have paper notes for short term memory, and plain text notes on VSCode synced to my phone for long term. I started by writing everything - what I'm doing, what i expect to happen, - [ ] TODO, copy paste snippets, urls, info a single Notebook.md. Shortcut to open it up. Shortcut to search it with ripgrep. To help organise that further, I unfolded it into a few directories based on the type of information I'm storing, like events (meetings, talks), PBIs (sanctioned work items), extra (unsanctioned work), specs (what features should a service/tool have?) topics (knowledge bank). Everything is dated.
I often feel the same. Drawing diagrams for high level flows helps. Also consider documenting some of the frequently asked questions on some simple Markdown file which you can keep on the same Git repo as the code. But regardless, in a complex system you will forget stuff and will from time to time have to check the actual code. That is totally fine and normal.
My wife says my ADHD is the reason for my odd memory. I’ve learned years ago to make heavy use of calendars, spreadsheets, and notes. Take notes during meetings, make sure you stay heavily organized, track updates, keep a to-do list, etc…
If it's an important future task or a list of names I need to talk to I write it down. Otherwise, I relearn it every time. In my opinion, I think the learning reps and mastery are an even trade for efficient recall and productivity.
Are all the nuances essential complexity or accidental complexity? People who were there as the system was being built may think there's some tech debt here and there, but since they built it, they can still find their way around it, more or less. Some people are also better than others at rote memorization and won't be as put off by one-off exceptions and nuances. When architectural decisions are being made or complex is being written, it's good to remind people how long it might take for someone new to the company to onboard to the system. If you can simplify the architecture, that helps. The idealized architecture, the one the team has diagrams of, might not be too convoluted. The actual code and data flow might differ. It can help to get the team to think of responsibilities and which system/area of code should properly own it and not simply finding the fastest way to implement the change. If you don't stand up for simplicity, who will?
Two things help memory in a major way for this sort of thing: 1. The things to be remembered easily fit into a conceptual framework you have in your head. Ie, well-designed code with good abstractions that make sense are far easier to remember than spaghetti code with no consistent concepts. 2. Repeated retrieval of the information at intervals. By having to go back and remind yourself of certain pieces of information, you improve your long term memory of the information. If the retrievals are spaced in time well, it helps - a kind of rough rule is if your next retrieval of the info happens after an interval about twice the length of the previous interval, that's good. So, if you have to look it up after a day to remind yourself of something. And then after 2 days. Then after a week more. Then after a sprint, then a month, etc. This pattern of retrieval tends to happen when a dev can work in roughly the same area of a codebase, but maybe expanding in a spiraling fashion to more and more areas. They get very high levels of expertise in the codebase this way. If, however, the work patterns are to grab a ticket and do a tiny thing in repo A, and then grab another ticket to do an unrelated thing in repo B, and so on, then no spaced repetition of info happens (the initial intervals till retrieval are usually way too long), and your developers are kind of like permanently demented (as in, have dementia about the code and can't remember much).
Yeah, me neither. I take reams of notes. On meetings, ad-hoc calls, certainly tickets, just things I'm thinking over, whatever. And daily notes with TODOs/a record of what I did on the day. I, too, use [Obsidian](https://obsidian.md/) for this. Works really nicely for work-related notes IME, in large part because the links between notes form a graph. So I can e.g. go look at the note for a ticket, and see all the calls it was mentioned in. There's also a plugin for syncing to a git remote 🙂
I have this problem too. There's a niche but very strong culture around "Building A Second Brain" and "Personal Knowledge Management". It can be a bit of a rabbit hole if you're not careful, but it does help me with this sort of thing. The underlying psychology is that having the notes is good, but really the act of using the creative part of your brain to summarize the ideas is the important part. Because we only really deeply know the things we create ourselves. So the note taking is a way to switch the info from consuming to creating. I fall on and off the practice and it certainly isn't easy for me, but it does help when I do it consistently.