[tppiotrowski]

I agree with this and would add Slack to the equation. It's just faster to ping a senior engineer on Slack than to spend 5 minutes looking into an issue.

I've also seen new hires burn an entire week because they were afraid to ask a question.

But I think the balance has definitely shifted towards asking too much help...

[jreese]

When I started at BigCo, the recommended policy was to spend two hours trying to solve it yourself, including searching the wiki, debugging code, etc. If you hadn't made any progress in that time period, then ask someone from your own team or make a post in a related internal support group. Only after exhausting that route, and getting no help, should you escalate to the team/oncall that owns the tool/service you are having problems with. It seems that culture has been lost.

[noisy_boy]

I still do this and I don't think this is entirely about culture. Some people do the legwork and some take the laziest route. Sure if the technical tools at hand make it that much hard to do the due diligence, maybe promptly reaching out for help can be (somewhat) justified, but I don't think that is usually the case.

[PikachuEXE]

Here is my balance:

Study a bit, WRITE my discoveries down

Craft a message with issues and background clear to readers (that includes myself when I forgot about this)

Send message to selected recipients, continue studying depends on free time available and issue importance