3 ms·

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 beca

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.

Closi 6y ago
> 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.
- ogre_codes 6y ago
  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.

Closi 6y ago

> 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.

ogre_codes 6y ago
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.