4 ms·

I understand what you're saying, but for many of us, the threshold is much higher for a call. I tend to, and I know I'm not alone here, accomplish most of my w

by wheels 4y ago

I understand what you're saying, but for many of us, the threshold is much higher for a call. I tend to, and I know I'm not alone here, accomplish most of my work in very focused blocks that often take me multiple hours to get into. Often I'll go a whole work day without being able to get there, and often when I'm in the flow, I'll work 12+ hours because that's how I'm most productive. Your 5 minute call may cost me 3-6 hours of productivity. Once I've pulled my head out of what I'm working on, it's not a given that I can jump right back in. Sometimes that's worth it. It's possible not having that call may cost you 3 hours of productivity. But because some people have different work styles, people who focus easily (or are working on easier problems) often don't think of the costs for those who don't.

nightpool 4y ago
Okay, but in this situation you are the one that asked them for help with your code. There's no "interrupted productivity" here if you're already blocked and waiting for advice or help with something. And besides, if you spend 3-6 hours working on completely the wrong thing because you were "in the zone" and that misunderstanding could have been resolved with a 5 minute call, then the 5 minute call is worth it every single time.
- wheels 4y ago
  You're assuming both people are working on the same thing. I'm assuming they're not. You're also assuming there's only one task the developer could be working on. That's a very rare scenario.
  - nightpool 4y ago
    The person you're replying to said "If you want my help with just about anything code related, that's a call. Screensharing is way easier for me to see what you are talking about, and it's much easier for us to be on the same page if we're both looking at the same thing." I think that's an entirely reasonable position. How does this depend on "If both people are working on the same thing"? If I'm trying to help you debug something, and it feels like pulling teeth when I know I could solve your problem with a 5 minute screen-share, I'm probably going to choose the 5-minute screenshare over the hour-and-a-half of 10 different messages spread out over random intervals. The GP said the exact same thing: It's also a massive peeve of mine when someone asks a question on messaging, refuses to have a call, and then proceeds to take forever getting back to me. It's one thing [if] I say something like "Try this, this, and this. Let me know what works" and then I can get back to my work. But if I'm trying to step you through something and you sometimes reply immediately, sometimes in 5 minutes, sometimes in a half hour, then you get to have calls whenever you want my help from then on.
zls 4y ago
I’m having trouble following. Presumably the person you’re interrupting is also doing serious-business-focus work. First off, since you’re the one interrupting them, common courtesy suggests you should try to accommodate their communication preferences. Second, that five minute call is saving you 45m of text back-and-forth, which lets you get back to focusing faster. Not to mention saving the helper frustration, if you’re regularly leaving five minute gaps between replies. And not even getting into the pernicious effects of having a culture where pseudo-synchronous instant messaging is broadly preferred over synchronous calls. In such cultures, all communication is so inefficient that everyone is in several conversations at all times; good luck ever achieving focus in that environment. There’s a reason why Cal Newport hates Slack, and he literally wrote the book on focused work.
- wheels 4y ago
  I read the grandparent differently than you and nightpool. I read the first two paragraphs as general policy, and then the following lines as specific cases. To come to the interpretation you guys had, you have to assume that the fifth paragraph supersedes the first. It's possible that's how the author meant it, but that's not obvious. The first paragraph implies virtually always preferring calling, independent of which direction the help is flowing. Addendum: I don't love Slack, but my company is small, and the number of messages per day is in the 10s. Nevertheless, I have notifications disabled for all messengers, because I also find them interrupting. I only see messages when I'm switching windows anyway. I have the same on my phone: I only have visual notifications. I disable sounds and vibrate. When I'm either being particularly productive, or particularly struggling to focus, I close all communications apps.
- nottorp 4y ago
  > Second, that five minute call is saving you 45m of text back-and-forth Except five minute calls tend to last 60 minutes... > pseudo-synchronous instant messaging is broadly preferred over synchronous calls. Yep, you should go fully async.
  - zls 4y ago
    Haven’t had that problem with calls. People have had to learn how to politely end conversations probably about as long as we’ve been using language. Once you learn that, the calls don’t drag. On the other hand, if a call takes five, ten, fifteen minutes for good reason, it would have been hours or even days of messages. How many times have you spent ten minutes helping fix a newbie’s dev environment, and afterward they say “wow, thanks, I’ve been stuck all morning”? And those calls aren’t rare! Knowing how (and when) to use calls over messages has been one of the most useful “soft skills” in my career toolkit.

by wheels 4y ago

nightpool 4y ago

Okay, but in this situation you are the one that asked them for help with your code. There's no "interrupted productivity" here if you're already blocked and waiting for advice or help with something. And besides, if you spend 3-6 hours working on completely the wrong thing because you were "in the zone" and that misunderstanding could have been resolved with a 5 minute call, then the 5 minute call is worth it every single time.

wheels 4y ago
You're assuming both people are working on the same thing. I'm assuming they're not. You're also assuming there's only one task the developer could be working on. That's a very rare scenario.
- nightpool 4y ago
  The person you're replying to said "If you want my help with just about anything code related, that's a call. Screensharing is way easier for me to see what you are talking about, and it's much easier for us to be on the same page if we're both looking at the same thing." I think that's an entirely reasonable position. How does this depend on "If both people are working on the same thing"? If I'm trying to help you debug something, and it feels like pulling teeth when I know I could solve your problem with a 5 minute screen-share, I'm probably going to choose the 5-minute screenshare over the hour-and-a-half of 10 different messages spread out over random intervals. The GP said the exact same thing: It's also a massive peeve of mine when someone asks a question on messaging, refuses to have a call, and then proceeds to take forever getting back to me. It's one thing [if] I say something like "Try this, this, and this. Let me know what works" and then I can get back to my work. But if I'm trying to step you through something and you sometimes reply immediately, sometimes in 5 minutes, sometimes in a half hour, then you get to have calls whenever you want my help from then on.

zls 4y ago

I’m having trouble following. Presumably the person you’re interrupting is also doing serious-business-focus work. First off, since you’re the one interrupting them, common courtesy suggests you should try to accommodate their communication preferences. Second, that five minute call is saving you 45m of text back-and-forth, which lets you get back to focusing faster. Not to mention saving the helper frustration, if you’re regularly leaving five minute gaps between replies. And not even getting into the pernicious effects of having a culture where pseudo-synchronous instant messaging is broadly preferred over synchronous calls. In such cultures, all communication is so inefficient that everyone is in several conversations at all times; good luck ever achieving focus in that environment. There’s a reason why Cal Newport hates Slack, and he literally wrote the book on focused work.

wheels 4y ago
I read the grandparent differently than you and nightpool. I read the first two paragraphs as general policy, and then the following lines as specific cases. To come to the interpretation you guys had, you have to assume that the fifth paragraph supersedes the first. It's possible that's how the author meant it, but that's not obvious. The first paragraph implies virtually always preferring calling, independent of which direction the help is flowing. Addendum: I don't love Slack, but my company is small, and the number of messages per day is in the 10s. Nevertheless, I have notifications disabled for all messengers, because I also find them interrupting. I only see messages when I'm switching windows anyway. I have the same on my phone: I only have visual notifications. I disable sounds and vibrate. When I'm either being particularly productive, or particularly struggling to focus, I close all communications apps.
nottorp 4y ago
> Second, that five minute call is saving you 45m of text back-and-forth Except five minute calls tend to last 60 minutes... > pseudo-synchronous instant messaging is broadly preferred over synchronous calls. Yep, you should go fully async.
- zls 4y ago
  Haven’t had that problem with calls. People have had to learn how to politely end conversations probably about as long as we’ve been using language. Once you learn that, the calls don’t drag. On the other hand, if a call takes five, ten, fifteen minutes for good reason, it would have been hours or even days of messages. How many times have you spent ten minutes helping fix a newbie’s dev environment, and afterward they say “wow, thanks, I’ve been stuck all morning”? And those calls aren’t rare! Knowing how (and when) to use calls over messages has been one of the most useful “soft skills” in my career toolkit.