Explore and understand a project's structure and functionality. Use when starting work on a new or unfamiliar codebase.
Arriving in a codebase, the temptation is to start reading files. Files are the least informative thing available.
The goal is not coverage. It is a model good enough to predict: where would a change of this kind go, what would it touch, and what would object.
Before structure, purpose. A system's shape only makes sense against what it is trying to do — the same directory layout is elegant for one purpose and absurd for another.
The README if it is honest, and what runs when the thing starts. Follow one real path from entry point to outcome — one request, one command, one frame. A single traced path teaches more than any amount of breadth, because it shows what the system actually does as opposed to what it contains.
Most of a codebase is consequence. A small part is decision, and that part is what needs to be understood.
Look for:
Consistency is cheap to learn — see the pattern once and it holds everywhere. The information is in the exceptions.
The module that does not follow the convention, the special case in an otherwise uniform dispatch, the comment explaining why something obvious is not done. These encode what was learned the hard way, and they are exactly what a newcomer will violate first.
When something looks wrong, assume a reason before assuming a mistake. Sometimes there is none — but the reason, when there is one, is usually the most valuable thing available.
Orienting ends not with a summary of the codebase but with a usable map, and maps are honest about their edges.
Worth stating plainly: what the system does, the words it uses for its concepts, where the important decisions are, which parts are settled and which are moving, and — critically — which parts have deliberately not been understood yet.
The last one matters most. A model presented as complete when it covers a third of the system leads to confident changes in the unexamined two thirds.