I find it helps to focus on a 'successful' path through the code, starting with an important entry-point and ignoring error conditions and validation. Once I've

I find it helps to focus on a 'successful' path through the code, starting with an important entry-point and ignoring error conditions and validation. Once I've covered a fair chunk of what the software does, I can go back and delve into the parts I didn't understand. I'm also wary of comments as I find they can often have 'drifted' in old code and become misleading. I make detailed notes of things that look dodgy or could be improved separate from the code. I'd add that if the project has poor-to-no build scripts that require a lot of manual steps it's worth at least bandaging it up with a shell script early on. I recently worked on a project that had many separate modules with independent build scripts, requiring copy-and-pasting built artifacts that others depended on, and several manual configuration tweaks post-packaging. That stuff is very tedious and sucks your energy. It's not generally a priority to rewrite all the build scripts, but if you're editing several modules it's worth being able to do a one-shot build from early on.