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!