> This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does.
As a junior, this is a problem for me too. I don't know when it's the right moment to ask something. "When I've been stuck for an hour to half a day" seems to be a good heuristic, but it's not perfect. I don't really know what's the best option for me. If I ask later, I learn more by myself, and improve my skills in figuring out a codebase. I also let senior engineers be more productive. If I ask earlier, I'm more productive. But I take more of the senior engineer's time.
Another heuristic I tend to use is "for code stuff, try asking later, for business stuff, try asking earlier", since business stuff is often harder to figure out. We have code that describes the behavior of our product, that I can read and try to understand, but we don't have code that describes the behavior of the business.
Same dilemma when adding comments. We code in a relatively "plain" style, so "how" comments are mostly useless. "why" comments are more useful, but people tend to not really update them.
I think a way of solving partially that would be to be clear about the meta stuff. For example, I could ask if I'm asking too much or not enough questions, if my productivity seems okay. The senior engineers could also communicate about that. Even sharing how they do themselves stuff would be useful. For example "I tend to look at the code for X minutes before asking someone.". As a junior, I could multiply this time by 2, 3, 4 and do the same. Or ask the seniors about how they did things when they were new to the codebase.
To give a bit of context, we have more than 10 MLOC at work on a 30+ years old codebase, ~200 engineers and half of them are there since 3 years or less.