I'm not sure this is the same thing but I waffle between wanting to not look stupid and also not wanting others to think I'm not trying hard enough.

Let's say there is something I need to do at work. I could read docs in the company internal site. I could read the code. Maybe the thing I need to do is figure out why a test is failing. It's possible it's failing because there's a bug in the code. It's possible it's failing because there is a bug in the test. It's possible it's failing because there's a bug in the CI/CQ. It's possible it's failing because some other dependency changed something.

The question is, when do I keep digging on my own vs ask for guidance and how much guidance? I never have a good feeling for that. I kind of wish the guidance was offered or encouraged as "I know you're not familiar with this stuff so let me walk you through this issue and then hopefully you can do it on your own the next time". But, I never know. I feel compelled to try to work it out on my own. Some of that is ego, like I can't do it on my own I must not be as good as others on my team. But I have no idea how much they asked vs figured out.

A few times when I do get guidance it's not enough. the person giving it isn't aware of all the hidden knowledge that's helping them figure out the issue and therefore doesn't pass it on.

As a mentor, I like to set explicit expectations for how much time someone should spend digging before asking for help, and I encourage others to do the same.

For an intern or new grad whose information gathering skills likely have gaps they don't even know about, I'll tell them to come check with me if they're completely blocked and haven't made progress for an hour, as it's frequently a small pointer or hint from me that can get them back on track. As they get more more knowledge about the systems and experience unblocking themselves, this grows to half a day, a day, and more from there.

The same applies even for experienced engineers who are new to the team, though the timeboxes grow much faster. There will always be little things to learn, and there's no point burning a day of chasing threads if it's some quirk in the system you just happen to not be aware of.

As an intern I feel the same everyday. It feels more natural to me to just keep digging into the codebase until I figure something out instead of asking for help.

Part of it is what you mentioned, as well as the fact that I sometimes feel bad for "wasting" a much more productive engineer's time.

It's also not clear from the other side. Do you give a lot of guidance, so the intern becomes reliant on always having someone telling them what to do exactly on the micro level? Or let them work it out slowly, and during that process get familiar with the systems more closely? I find that having a clear task to solve actually gets me more of an understanding of how everything works, than reading a top-down documentation where I don't have any context of "why".

Also interns can differ a lot. They can need different levels of guidance and can come with widely different levels of prior experience, even in unrelated debugging and troubleshooting like fixing network ports for LAN gaming or whatever kids these days might be doing. Setting up VPN to evade geoblocking or whatever. Others may have no idea what to even do. And those who can do it may take widely different time.

I think an internship is, in fact, a good place to learn these meta-lessons too. You ask for some guidance, then you see it was maybe too much. Another time you don't and spend a lot of time, and have your supervising engineer say "oh I could have told you XYZ very quickly", then you update and recalibrate. There is no single short message that can convey this. That's why experience is valuable.