[Zababa]

> 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.

[opportune]

Yeah, knowing when to ask questions is itself a skill. I didn’t mean to insinuate in my comment anything negative towards junior engineers or imply I hate when they ask questions. But I’d say knowing how to read code and understand it on your own vs recognizing when something is almost unknowable without asking someone is a hallmark of a more mature engineer. But I stand by my insinuation that people aren’t deliberately hoarding knowledge, they just learned what they know effectively (via primary sources and doing) rather than through hearsay or lectures. Or they “know how to know”, they seemingly know everything because they know how to find answers to any question.

What you say about business logic is definitely true. In general the more something is an “emergent” property or itself only a high level concept (eg “Why do we use Mesos?” “How do we implement load shedding?”) the better it is to ask. The more implementation specific (“Why won’t this compile? What does this error mean?”) the worse it is. It’s not only about the time to find something out but also how it can be found out - whether it’s a web search or codebase search away, or not. The other problem is the senior people you ask may not always know the answer of the top of their head, and in answering your question will have to answer it themselves - typically you want to avoid that too.

For one I would always be more than happy to truthfully answer a mentee’s question regarding if they are asking too much.

[Zababa]

> I didn’t mean to insinuate in my comment anything negative towards junior engineers or imply I hate when they ask questions.

That's not how I took it, sorry if this wasn't very clear but my point is that it's difficult on both sides, and it's interesting to share our struggles to see if we can find better ways to transmit knowledge.

> . In general the more something is an “emergent” property or itself only a high level concept (eg “Why do we use Mesos?” “How do we implement load shedding?”) the better it is to ask. The more implementation specific (“Why won’t this compile? What does this error mean?”) the worse it is. It’s not only about the time to find something out but also how it can be found out - whether it’s a web search or codebase search away, or not.

That's a great heuristic.

> The other problem is the senior people you ask may not always know the answer of the top of their head, and in answering your question will have to answer it themselves - typically you want to avoid that too.

I think that may be a good thing in some cases, as long as you don't demand/need the answer now and the question is good. If there's something that even senior people are not clear on, that's an opportunity to clarify things for everyone. I think that's what people mean when they talk about the value of new hires being able to see surprising stuff that feels normal to the people inside.

> For one I would always be more than happy to truthfully answer a mentee’s question regarding if they are asking too much.

That's great!