Great guide! I would add fixing bugs. I often learn most about a code base by fixing my bugs. A good debugger can be a blessing. Profiling is part of debugging to me. Questions can come up about why something is taking a long time that lead to more debugging and thinking about what is going on.

The best runs I've had working on others' codebases is to jump into documenting it. Many projects love having someone read, ask questions about, and document code, even (or especially) from a naive standpoint since that's who'll benefit the most from it, and in the process you learn how the code's structured, track where references lead to, and more often than not kick over some bugs worth fixing in the process.

Good advice! I especially like the first advice

> The first step to understanding the internals of any project is to become a user of the project.

It's normally easier to figure out complex behaviour from the spec/doc/interaction than from the code.