Great team dynamic if one of the members is blocked or has an issue because of something that another person wrote, and they get told to fuck off.
Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.
The best teams I have worked with tend to be more collaborative.
An atmosphere where interrupting people randomly is commonplace is almost never good for productivity.
> The best teams I have worked with tend to be more collaborative.
Collaborating doesn't require interrupting people in the middle of a task.
Almost everywhere I have worked there has been a way to signify that you don't want to be disturbed and you are working in the zone, be it setting do not disturb on slack or wearing headphones.
It's not an either/or situation, and if John has the credentials to a server and sits opposite me and doesn't have headphones in, I'm asking him to pop them across rather than raising a ticket to him.
With regards to your previous comment, I already said above
> "The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now...."
—and—
> "In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it."
If you are a developer and your workplace is filled with interruptions because people lack credentials or things are poorly documented, then your productivity is going to be terrible.
I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now.
> I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets).
In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it.
But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.