One point I’ll make is that I think it’s important to try to learn the domain and the product on a conceptual level, not just a technical level. That is, don’t just try to understand what the data contains and how it flows – try to understand what the users are using the product to do and how they think about it. Especially if it’s a domain that you haven’t worked in before. My current position is in a very specific domain (university admissions) and I took longer than I should have to get up to speed because I approached it primarily through the code. I would have done better to ask a lot of questions about the admissions process itself first.
In a similar vein, I like to ask someone to walk me through the “happy path” of a given process first, so I can look at the code that supports that path. It’s important to also, later, understand the code that supports the variations and oddities, but it’s confusing to start by looking at all of the code at an equal priority level.
A question I often find useful is “can you sanity-check me on this?” followed by a summary of how I think a certain part of the system works.
Another key thing to start making notes about very early on is: who is the point person to ask about a given topic? You don’t want to pester anyone, but if you know that financial questions go to Tracy and data integrity questions go to Neena, you can move a lot quicker.