3 ms·
> I'm one of those people who almost always wants to immediately get on a call to solve a problem rather than typing it out. I get that it's tiring being on cal
by MuffinFlavored 4y ago
> I'm one of those people who almost always wants to immediately get on a call to solve a problem rather than typing it out. I get that it's tiring being on calls all the time but it's also much more effective to have a call for most types of work conversations, even as a software dev.
I find it interesting that something measurable like this feels (not saying it is) like an opinion.
It's my opinion (maybe because I'm a semi-effective text communicator?) that handling it "async" on chat is more often than not quicker. Maybe I'm wrong/biased? I wonder how something like this is measured. It does feel like people who want to not accept calls are in the minority based on my experience/the response this is getting.
- mindcrime 4y agohandling it "async" on chat is more often than not quicker. I'm sure there are times when it is better, and times when it isn't. I generally find that if a question is REALLY simple, then async is fine. Eg: Q: What's the IP for the bumblefraxx gateway again? A: 10.0.14.233 Ok, sure. Done, handled in a few seconds. But for anything that goes beyond about 2 Q/A "cycles", I generally find that a call is faster, because I can figure things out a lot faster when I can see all of the relevant details myself. Eg: Q: The bumblefraxx gateway isn't working, can you help? A: Did you make sure the IP is right? Q: Yeah. Do you think the frozgibbit might be wedged? A: ... 15 minutes later Let's have a call so I can see this myself /me looks at screen. Notices some trivial typo in config for bumblefraxx gateway. Problem fixed in 15 minutes and 15 seconds, when it could have been 15 seconds
- idontpost 4y agoWith async communication you really need to define what quicker means. I suspect you're not defining it the same as people who prefer a quick call.