The way I make myself familiar with new code is to find some process of interest and write out a psuedo code stack trace from the trigger through execution. So, function names, relevant params, leave out error handling and irrelevant branches. If a step is async, reset indentation and annotate the "stack" with "and later..."
This process can collapse large amounts of code into a hopefully a single page of text that can be well understood. Without it, I find it very difficult to keep all of the relevant code in my head when it's spread across the code base.
No filenames. Just functions. Collapsing info from multiple files is a big part of the goal. IDE search works well enough that I rarely know what file I'm in.
I use names from the code. I do want to be able to locate the code later.
I try to omit most conditionals. The goal is to show the path of interest, not all possible paths. Some conditionals are interesting though --very likely errors, process cancellations, scary bug-tempting edge cases.
Some ideas:
Spend time learning how to do thenusers jobs, understanding how thenusers use the system. Go into the code, pick one spot, and understand what it does very well. For that one spot, make a list of all the external things it uses that you don't know about. Go to each spot in that list and make notes about how that thing works, indented under the list item. Repeat that process recursively for a level or two, or as many as you have patience for.
Pair program with someone else who knows the system. Write unit tests.
Reading automated tests and doing extensive searches in the codebase (with recursive `grep`s) is often helpful. If you use an IDE with a go-to-definition function, it can replace grep.
This process can collapse large amounts of code into a hopefully a single page of text that can be well understood. Without it, I find it very difficult to keep all of the relevant code in my head when it's spread across the code base.