On the other hand, though, I really wish people would take at least ten minutes to do that digging through the code or reading through the documentation before asking.
One, reading code in general is a good thing to do when you're new, and it's a skill that should be built up in general.
Two, you might actually find what you're looking for, and answer your own question! It's a nice little boost to realize you're getting self-sufficient.
Three, you'll have a lot more context for me, which will make it easier for me to give you the answer. "Hey, how come this function doesn't return what I expected" is a much harder question to answer than "This function says it returns a list of items a user has accessed in a given workspace, but it's returning an empty list; I've checked my local database and it has a good set of seed data I think, and from looking at the function there's nothing obviously filtering out users, so what's going on?"
At my first job, at a consulting company, they had a good rule, which was basically "show initiative when asking questions". What this boils down to is if you ask how to do X, you should first research and think about it, and then you can say "I think Y is how I do X, am I on the right track?"
A lot of the time, you'll answer your own question getting to Y. If not, it will save the person you're asking a bit of legwork, and show you are not trying to have them do your job for them and have respect for their time.
Agreed, now that I'm the person getting these questions, it's hard to reconcile "it would have saved me a ton of time when I was new to this codebase" with "why can't you do even a basic amount of due diligence to even figure out what you're trying to do". (As I mentioned -- it's still important to figure out what the right question is!)
It's hard to find the right balance, and I agree with the author's framing of it as a spectrum, but I also agree that I at least (and most junior engineers, in my experience) leaned way too far on the side of being, um, self-motivated.
I certainly do notice myself getting frustrated by people asking questions when IMO they should know better, and I'm never sure whether I should be more lenient there or if I should tell them off for not putting in that tiny bit of effort.
One, reading code in general is a good thing to do when you're new, and it's a skill that should be built up in general.
Two, you might actually find what you're looking for, and answer your own question! It's a nice little boost to realize you're getting self-sufficient.
Three, you'll have a lot more context for me, which will make it easier for me to give you the answer. "Hey, how come this function doesn't return what I expected" is a much harder question to answer than "This function says it returns a list of items a user has accessed in a given workspace, but it's returning an empty list; I've checked my local database and it has a good set of seed data I think, and from looking at the function there's nothing obviously filtering out users, so what's going on?"