You're also assuming there's only one task the developer could be working on. That's a very rare scenario.
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.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.
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 5th 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.
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.
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.
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.