I've worked from home extensively myself and find that these situations are rare. If they occur frequently, perhaps there is an underlying issue present.
Nevertheless, when they do occur, you essentially have an typical computer architecture design problem in a human setting, so we can use solutions from that field.
Essentially we are waiting for a communication operation to finish so our computational unit (the programmer in the human setting) is idle. Common solutions are branch prediction and hyperthreading.
For branch prediction in the human model we simply send the question through a slow channel (e.g. email), but rather than waiting for the response, we try to predict the response value. If it turns out we were wrong, we have luckily been using clean git strategies and can easily delete out work. Even with random responses, in the common case of 2-option choices, this is a .5 production modifier, probably less than what we would get when dealing with constant interrupts.
For hyperthreading, we stop working on the current problem, and work on a different one while waiting for an answer. The cost of this strategy is dependent on context-switching cost and granularity of the tasks. It also requires making some modifications to popular teamwork strategies like scrum, but that should be a given when working remotely and asynchronously.
I've worked from home extensively myself and find that these situations are rare. If they occur frequently, perhaps there is an underlying issue present.
Nevertheless, when they do occur, you essentially have an typical computer architecture design problem in a human setting, so we can use solutions from that field.
Essentially we are waiting for a communication operation to finish so our computational unit (the programmer in the human setting) is idle. Common solutions are branch prediction and hyperthreading.
For branch prediction in the human model we simply send the question through a slow channel (e.g. email), but rather than waiting for the response, we try to predict the response value. If it turns out we were wrong, we have luckily been using clean git strategies and can easily delete out work. Even with random responses, in the common case of 2-option choices, this is a .5 production modifier, probably less than what we would get when dealing with constant interrupts.
For hyperthreading, we stop working on the current problem, and work on a different one while waiting for an answer. The cost of this strategy is dependent on context-switching cost and granularity of the tasks. It also requires making some modifications to popular teamwork strategies like scrum, but that should be a given when working remotely and asynchronously.
This answer is amazing.