So... "shouting across the room" for a ticket which is so trivial it doesn't need to be documented is OK, but telling someone to "fuck off" for doing it is not?

Your priorities are backwards. I would not work at a place where interrupting me during coding to fix a trivial bug is considered acceptable.

Each to their own, I wouldn’t want to work at a place where we were just working on our own stuff and if you need something from someone you have to raise a jira ticket before you talk to them even though you are in the same room.

The best teams I have worked with tend to be more collaborative.

There are a lot of ways to communicate to someone without interrupting them. If you are communicating about a bug in code, a ticketing system is a good one because it communicates that something needs to be done, the person you are communicating to can handle the issue when it's not interrupting their current work, and gives them an effective way to let you know it's complete. In most cases the issue in question will get handled quicker because usually multiple people can take care of the task and the one who has free time first can handle it.

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.

> An atmosphere where interrupting people randomly is commonplace is almost never good for productivity.

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.

Maybe it's just a poor turn of phrase, but when someone talks about "shouting" across the table to get some minor issue fixed, that isn't the kind of place where good coding happens.

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.

> The best teams I have worked with tend to be more collaborative.

which means more writing to be done. not everbody knows what was SAID an hour ago.