[lmg643]

I think "reading the manual" can be be interpreted not just in the literal sense of whether there's an actual manual, but also in the metaphorical sense, to make sure we're considering easily available sources of information. Great advice.

[mtlmtlmtlmtl]

The code is the best manual you'll every get in my experience. There's no substitute when working on a codebase.

When I'm introduced to a codebase I'll be doing significant work on, I'll often spend hours at a time just reading the code. Start at main() and skim until you get a feel for the overall architecture, then go figure out whatever subsystems seem mysterious to you. Rinse and repeat. Makes a huge difference when making changes, because that requires reading code anyway, and you'll have a much better idea of what code to read/change.

[adave]

Imo reading gets you nowhere and is inefficient. Key piece is to add some form of self explanation or diagram to map the overall picture, since it takes a lot of repetition to understand the code flow but only hours to come up with a data flow diagram and revisit/update when needed. Even faster when someone on the team has already done it.

Maybe its just me but plain text does nothing for me so i convert it into visual elements.

[tstrimple]

Code also has the advantage of not getting out of date with what the application actually does. Invariably, documentation outside the code base often rots over time until it reaches a point it's outright misleading.

[jen20]

> Start at main() and skim until you get a feel for the overall architecture

Man I wish that worked for Java ;-)

[sigha887]

And it will for all future make it impossible for you to distinguish official API and implementation details.

[nickjj]

Yep this is a really important skillset.

I've written a post around this topic because you can do this in a systematic way to learn pretty much anything https://nickjanetakis.com/blog/how-i-quickly-find-answers-to....