Read most current tickets to do, probably some of the backlog to get an overview of what people have problems with.
Then I probably start reading what is the main entry point and go through everything just looking for code that is badly written, optimizable, or can otherwise be improved.
Finding bad code I write notes to myself on what needs to be improved. I make a ticket to fix things. I go fix things, now I have sort of a high level overview of how the different parts of codebase work together.
Maybe I have found architectural things to be fixed (this is of course assuming I am better with language/solution space than team I am coming on to but I often am when hired as a consultant) - for example current project I am on had mixed routing and display of components which in this case was bad architecturally (IMHO it's always a problem but in this case it definitely was one) so I fixed that which further made the structure of whole project clear.
If stuff I don't understand I ask whoever is leader, don't just change things that you don't understand to be something you understand, there might be reasons why things are the way they are.
Now I probably have had a full week on project and done several improvements. Also going through things I might find stuff that relates to the tickets I saw, if I can see that something relates to a ticket I read take that ticket and fix it as part of other stuff doing. All this helps develop overview of how project hangs together and what problems are.
If possible (either via docs or guidance from other developers), I find a major API and then follow it to its end point. You will usually come across other major pieces of the codebase this way and you can make a note of them if you wish to do further digging.
I have a strong suspicion that if I just used the right tooling (eg maybe a GUI that displayed some of the flow of the program's state, or something that made it easy to inspect the running program?) it might be a bit easier.
Any tips about y'all's favorite C/C++ tools for learning a new codebase?
I first read or find out as much about what the code is supposed to accomplish. After this, I jot down the primary aspects of the program I would expect to see - decompose main functions. Every ancillary aspect of the code I meet I put under headings that I have written down. I write down aspects I expected but didn't find.
Beyond this, you get a panga blade! Good luck