I read it like a book and Google all the tooling I don't understand. Usually the first page will be something like a make file. Understanding every detail of th

I read it like a book and Google all the tooling I don't understand. Usually the first page will be something like a make file. Understanding every detail of this file will reveal the many hacks needed to get the project to run and that tells you a lot about the project. After that, I look for the entry point and try get a sense how the code files have been organised. If it's good code, it will look like a curated library of small functions with few inter-module dependencies. It should be easy to add and remove functions without having to change countless files. From this, you can start thinking of improvements and how to add them to the existing software. It's a lot easier if it's only for your use as you can get by with something that 'works' rather than something that 'works well.' Second what another poster here said too: if there's too many files its easier to work with the code than try read all of it.