4 ms·

It's a shame, I was hoping for actual insight, but all I got was complaints. There are absolutely challenging anti-patterns in the remote work world, but I hav

It's a shame, I was hoping for actual insight, but all I got was complaints. There are absolutely challenging anti-patterns in the remote work world, but I have yet to see actual concrete suggestions for how to deal with them. No, "nohello.com" is not an actually useful suggestion (ignoring the fact that I fundamentally disagree with the premise). Just complaining about ad hoc meetings doesn't solve for the occasional need for quick discussions that, in a textual medium, would drag out or lead to misunderstandings. "Be more asynchronous" denies the reality that some work is synchronous. If I need something from you, I have to wait until you give me what I need. Development is a team sport, despite what the stereotypes would have you believe. I'd love to see how "remote native" companies are doing this, but according to the author, they just devolve to this state, too.

BlargMcLarg 4y ago
>"Be more asynchronous" denies the reality that some work is synchronous. Development is a team sport, despite what the stereotypes would have you believe. "Be more asynchronous" is advocated to swing the pendulum, see what sticks and see what doesn't. It's not meant to be "throw the baby out with the bathwater", which most seem to kneejerk to. Right now, the problem is a lack of evidence on a long term (1-2 generations), with a status quo unwilling to try anything despite a promising two year event. You don't make conclusions without evidence. >If I need something from you, I have to wait until you give me what I need. The far majority of cases, you'd have another task to work on before syncing up because most coworkers don't appreciate being disturbed when they are working on something important either. Now replace syncing up with sending them a message, and they respond at their disposal. Either way someone is going to lose out on their individual work and it depends entirely on the context who's going to lose out more, and which choice would have helped the team get more work done. >Development is a team sport, despite what the stereotypes would have you believe. Which doesn't at all say anything about "sync vs async". Surely we don't have to point at the dozens of "tap on your shoulder manager" anecdotes to showcase being in person, in the office, allows for just as much solipsism.
- BaseballPhysics 4y ago
  > Right now, the problem is a lack of evidence on a long term (1-2 generations) I'm very curious where you got this idea because it certainly doesn't reflect reality. As others have pointed out, working across multiple timezones/geographies has requires asynchronous work for decades, now, and anyone who does it will tell you have enormously painful it can be. > The far majority of cases, you'd have another task to work on before syncing up If you're a developer, you must know what it's like to be heads down in the middle of something extremely mentally taxing, only to find you need an answer to a question or something, and that context switching to something else in the meantime becomes an enormous cognitive burden vs getting a quick answer and being able to continue on-task. Humans don't multitask. It's a myth. Every context switch requires at least 20-30 minutes of ramp-up time on anything requiring any real thought. "Just be more asynchronous" is predicated on a faulty idea of how the human brain works.
  - BlargMcLarg 4y ago
    >You must know what it's like to be heads down in the middle of something extremely mentally taxing, only to find you need an answer to a question or something, and that context switching to something else in the meantime becomes an enormous cognitive burden. So why is it okay if you have a need of someone else to force it on them? You can make the exact same argument pulling someone out of their flow to support you keeping yours. >Humans don't multitask. It's not multitasking. It's a context switch made out of necessity to keep yourself doing something. If it turns out your teammate responds early and you have to restart on the old task and ultimately you lose time, yes, that sucks. But what else are you going to do? Again, you're either taxing yourself, taxing someone else, or twiddling your thumbs to avoid the tax in hopes it ends up being the most profitable choice. It's because I'm a developer I know exactly how annoying it is to be in either situation, both as the one who needs to help others, and as the one who needs help from others. >I'm very curious where you got this idea because it certainly doesn't reflect reality. We only had a single pandemic lasting 2 years with some evidence suggesting some subpopulation would do better asynchronous, remote or both. That's a far cry from running a larger experiment over the course of 20 years in an environment you're not forced to almost fully isolate yourself otherwise. If you're claiming there is large scale evidence proving sync is obviously and clearly better than async, in an environment which at least attempts to accommodate async, by all means, present it.

BlargMcLarg 4y ago

>"Be more asynchronous" denies the reality that some work is synchronous. Development is a team sport, despite what the stereotypes would have you believe. "Be more asynchronous" is advocated to swing the pendulum, see what sticks and see what doesn't. It's not meant to be "throw the baby out with the bathwater", which most seem to kneejerk to. Right now, the problem is a lack of evidence on a long term (1-2 generations), with a status quo unwilling to try anything despite a promising two year event. You don't make conclusions without evidence. >If I need something from you, I have to wait until you give me what I need. The far majority of cases, you'd have another task to work on before syncing up because most coworkers don't appreciate being disturbed when they are working on something important either. Now replace syncing up with sending them a message, and they respond at their disposal. Either way someone is going to lose out on their individual work and it depends entirely on the context who's going to lose out more, and which choice would have helped the team get more work done. >Development is a team sport, despite what the stereotypes would have you believe. Which doesn't at all say anything about "sync vs async". Surely we don't have to point at the dozens of "tap on your shoulder manager" anecdotes to showcase being in person, in the office, allows for just as much solipsism.

BaseballPhysics 4y ago
> Right now, the problem is a lack of evidence on a long term (1-2 generations) I'm very curious where you got this idea because it certainly doesn't reflect reality. As others have pointed out, working across multiple timezones/geographies has requires asynchronous work for decades, now, and anyone who does it will tell you have enormously painful it can be. > The far majority of cases, you'd have another task to work on before syncing up If you're a developer, you must know what it's like to be heads down in the middle of something extremely mentally taxing, only to find you need an answer to a question or something, and that context switching to something else in the meantime becomes an enormous cognitive burden vs getting a quick answer and being able to continue on-task. Humans don't multitask. It's a myth. Every context switch requires at least 20-30 minutes of ramp-up time on anything requiring any real thought. "Just be more asynchronous" is predicated on a faulty idea of how the human brain works.
- BlargMcLarg 4y ago
  >You must know what it's like to be heads down in the middle of something extremely mentally taxing, only to find you need an answer to a question or something, and that context switching to something else in the meantime becomes an enormous cognitive burden. So why is it okay if you have a need of someone else to force it on them? You can make the exact same argument pulling someone out of their flow to support you keeping yours. >Humans don't multitask. It's not multitasking. It's a context switch made out of necessity to keep yourself doing something. If it turns out your teammate responds early and you have to restart on the old task and ultimately you lose time, yes, that sucks. But what else are you going to do? Again, you're either taxing yourself, taxing someone else, or twiddling your thumbs to avoid the tax in hopes it ends up being the most profitable choice. It's because I'm a developer I know exactly how annoying it is to be in either situation, both as the one who needs to help others, and as the one who needs help from others. >I'm very curious where you got this idea because it certainly doesn't reflect reality. We only had a single pandemic lasting 2 years with some evidence suggesting some subpopulation would do better asynchronous, remote or both. That's a far cry from running a larger experiment over the course of 20 years in an environment you're not forced to almost fully isolate yourself otherwise. If you're claiming there is large scale evidence proving sync is obviously and clearly better than async, in an environment which at least attempts to accommodate async, by all means, present it.