[jollybean]

The architectural overview, either from the docs or from someone who can tell you, which gives you the 'lay of the land' and a rough idea of what does what. Like having a map.

Then, the custom idioms and weirdness that develops in every project, often it's a set of patterns that the team just 'acquires' - often it's in every file, every function. It's like learning 'words' specific to the language they have created for themselves.

Then get someone to explain the build systems, tooling etc..

And then, just of the sake of it - make sure to build it. Make a change and build it again. I think there's a weird leap in subconscious confidence that comes along with 'building it'. Like riding a wild horse for the first time, if you can do it for one second, you can do it for longer.

Once you have you head wrapped around the system, and the 'systematic things' (like idioms) and can navigate the tools ... then it a matter of breaking thing down into details. Which is where the work is of course.

But you need a 'map' and a 'cart' and your 'hammer' before you can start waltzing around Campus thinking about fixing things.