For a large codebase, normally I use the thing, note the different UI elements and messages, search the code to find where they are created and set up, pick one

For a large codebase, normally I use the thing, note the different UI elements and messages, search the code to find where they are created and set up, pick one, and look into what happens when that particular element is triggered by the user. In other words, ask "how does button ABC do its thing?" or "where does message XYZ really come from?" and plunge down the rabbit hole. This tends to be a more fruitful approach than trying to understand how the whole application works from start to finish. Moreover, with existing codebases it usually happens that most of the issues are not in starting and finishing, but in all that happens in between. In terms of IDE support, for me the most important feature is good search. When I stumble upon a hairy-looking method, for example, I want to be able to quickly see where and how it is being used.