One of the things I try to teach and stress to others when I'm in a team is that while they need to make an honest effort to solve a problem themselves, there are times that they need to ask for help. Spinning on a problem for days isn't helpful to anyone, and even if you do find a solution, it's likely that the time wasn't well spent for the organization.

At the same time, asking someone, or everyone in Slack with an @here, can interrupt and disturb others, causing them to lose their focus. Having someone always interrupt others is also annoying, and can feel like the asked is placing the burden on others to get work done by the others.

I saw an interesting post from a software engineer on when to ask for help. The general rule of thumb was to not spend more than an hour, which I think makes sense. There's also a formula, which takes into account how long you've spent, how long to explain things, and the relative value of someone's time. I don't know if this is a good formula, but there is one good thing.

Write down what you've done. We ask that of people posting at SQL Server Central, and we have etiquette advice on SQLServerCentral about how to post a question, as well as numerous blogs that have tackled the same topic. As the main post above notes, often going through what you have done can help unblock you from simple or silly mistakes.

This is good for general problems, the normal flow of work. In the post, the engineer talks about adopting cloud native techniques, which is likely similar to how orgs might adopt DevOps techniques. In those cases, I do think you might add a step to any problem solving: documentation.

As you learn something, document it for the team, with some eye towards teaching others a few things. We don't want everyone solving the same problem, even if it's through search. Instead, we want people to have a resource to check first: a list of the problems we've already solved, codifying the knowledge of the team.