I’m interested in practical workflows that experienced engineers use.
Then I like to check out the database (or algorithms & data structures if no db) and see how data is stored and manipulated, usually tells you a lot about choices that have been made.
Then open the project(s) and trace those 3-4 workflows once I understand it from the top level workflows. Part of this is also of course, getting the project(s) loaded and building locally as needed also reviewing tests, CI/CD, dependencies etc.
Lately, I've used Claude Code to help me with this, have it build a function map or class map and have it breakdown key insights about the code and trace those few workflows for me that I then validate. My process is pretty much the same just Claude does a lot of the initial lifting. I'll also dump the entire DDL for most databases (if they are more then a few tables) and send it to Claude and use that as a way to look for patterns/issues etc. For older monolith apps I've had to break the DDL into chunks sometimes just because some of these older apps have a very large number of tables/indexes/constraints etc that have been added over the years. Same thing works for json stores too fwiw.
And if you have no task you are aiming at, find the main entry point of the code and start tracing where it goes.
But either way, I would not actually start with the code. The code glues together the data and the UX, so go figure those out first. Use the app. Browse the data schema. Figure out some connections. Once you understand that "datum A" is used in "UX widget B", the code just becomes a middle point to step through to connect them. And stepping through it once for one data field will likely teach you the patterns used in the codebase, so you can apply that learning to everything else.
And don't forget to read documentation. It isn't always kept up to date, but something is better than nothing.
