This is all great advice. Two things that have helped me in particular
(1) applying the "analytical reading" rules defined in "How to Read A Book" to a code base. One of those rules, as Olikas said, is formulating hypotheses and questions and "actively engaging" with a code base (or any text).
(2) Compare and contrast a similar project (i.e. using the same language and framework) to figure out whether the structure of the project in question is following a general layout or not (e.g. Maven projects in Java).
I’d seen that book a while ago but not picked it up. I’m now going to. Thanks!
> formulating hypotheses and questions
I think this reduces to “how do you keep those hypotheses organized?” which sounds kinda like the problem of “How do I write an outline?”
> Compare and contrast a similar project
This makes sense to me for web apps. Less so for a package manager.
I suppose that means the questions splits off into lots of domain-specific quesions like, “what should I pay attention to when reading a RESTful service?” “What should I pay attention to when reading a package manager?” Etc.
————
For a RESTful service, I would recommend first getting and idea of the core models from the API docs and then from reading structure.sql or models.py or whatever holds the relationships among tables. Draw an entity-relationship diagram on a big piece of paper of the important models.
Then, try and trace the path of a web request from the outside in through middlewares to the controller then to rendering and back out again.
(1) applying the "analytical reading" rules defined in "How to Read A Book" to a code base. One of those rules, as Olikas said, is formulating hypotheses and questions and "actively engaging" with a code base (or any text).
(2) Compare and contrast a similar project (i.e. using the same language and framework) to figure out whether the structure of the project in question is following a general layout or not (e.g. Maven projects in Java).