Asking a question in slack is exactly what I’m referring to. It is async but if we’re on the same schedule then chances are you’ll reply within a couple minutes if not an hour. I massively prefer this style as opposed to walking over to somebody’s desk. However OP is suggesting async also implies you can be working on different schedules with no downside but it’s the differing schedule that is causing the problem.

I agree, we have a sister team which resides half-way around the world (we’re west coast of US, they are in Germany). Over the years, we’ve found the asynchronous communication between us to be a point of friction that has slowed down progress. Waiting for a peer review from them introduces days of lag on what should be faster iterative development cycle.

As a result, we’ve factored this into new architecture plans which further decouple the two teams to operate more independently. We may not have cared as much if we all were operating in approximately the same time zone but asynchronous work will undoubtedly slow development progress on any interface boundaries or when working with dependencies. In a micro-services oriented organization this will almost always be the case. For some areas I can see IC’s being sufficiently isolated in a way that asynchronous could work well but for my organization it would be a nightmare.

Seems like there are two very different modes of development being mentioned here. You seem to be describing a mode where you just need to concentrate and bang out your lines of code for the day. The previous comment seems to be referring to creative, collaborative development. The industry probably needs both, but I’m much more personally interested in the latter, and I’m worried that async/remote is disastrous for that mode in ways that might not be realized for years. To use a crude example, if you’re in a rock band composing songs together, you would never consider that suggesting a change to the riff the bass player is playing would be “an interruption that cost them 20 minutes of focus.”

Your not the bass player you are the record label worrying about if a single exists.

If you interrupt the songwriter every 20 minutes because you have a question around lighting you end up without a song.

Many rock bands create their parts separately or one person creates it all and everyone else learns the material.

Surely it would be managers or executives that would be analogous to the record label executives. We’re talking about ICs on a collaborative team.

> To use a crude example, if you’re in a rock band composing songs together, you would never consider that interrupting the bass player to suggest a slightly different riff would be “an interruption that cost them 20 minutes of focus

Bad analogies are not very persuasive

If you think software development can be a collaborative creative process, it’s really not a terrible analogy.

This analogy sucks because a rock band cannot make songs without actually playing together over and over again. You can however build software in modules or independent parts as long as you have clear specs about what each part should do and proper testing. Thats why you can outsource some software dev but you cannot outsource a rock band.

Terrible analogy.

If you want to pick something that makes more sense to compare, it would be something that is engineering related.

> You can however build software in modules or independent parts as long as you have clear specs about what each part should do and proper testing.

Where do these clear specs come from? That’s the creative process I’m talking about.