How I do it is play with the system as a user first, and think of small stuff to change. It might be real features or bugfixes, but at this stage, it's often th

How I do it is play with the system as a user first, and think of small stuff to change. It might be real features or bugfixes, but at this stage, it's often thowaways like "make that button report the current frommet count", or "add a new token to the file format", etc.. small changes that require communicating from disparate parts of the system or require touching deeply buried parts of the codebase are best. Often in a large codebase trivial changes can be quite hard to track down. The act of digging through and finding and making these changes give me an overall map of the codebase. Fixing bugs is a great way to do this. If I'm new to a project, I will spend a few days just going through the bug backlog if I can. Half the time (at least) the bugs are not even real, no longer applicable or otherwise non-fixable, but just tracking that down is useful (and it feels good to close tickets) Also, learning quickly what parts of the codebase you can simply ignore and treat as a black box, and where you need to change.