[Gigachad]

Typing indicators are an anti pattern imo but async work doesn't seem like a desirable thing. Very few people are doing jobs where they can just go offline for a day and come back with a result.

Most work, especially software development requires frequent communication. Being able to quickly bounce ideas off people and verify your plans before committing to them is so valuable. I can't count how many times I have been right in the middle of something, had to make a questionable choice, spoken to a coworker just to verify the idea, and they tell me something that completely changes the outcome. Being able to get this done within the hour vs getting it right at the end in review is so valuable.

[michaelchisari]

| Most work, especially software development requires frequent communication.

This hasn't been my experience. Long periods of deep focus are more important than constant connection.

[Gigachad]

What is worse than being interrupted is spending days in deep focus only to find out at the end that you made a foundational mistake that invalidates the rest of your work. Through no fault of your own you could have the wrong understanding of what the user wants or how it fits in with other parts of the system. Being able to quickly sync up with the end user for a change or validate your ideas with another developer is so valuable.

If you need to wait a day to get a response from anyone, you either have to drop the work and do something else while waiting (breaking your deep focus). Or assume you are right while waiting and risk throwing out a days work if you are wrong.

[jdavis703]

IME many large, non-tech companies are so bureaucratic they essentially have an async flow. Which perhaps is fine, there’s already a defined process for what needs to be done. But for a startup where even the next two weeks are foggy, async work can be detrimental.

[karottenreibe]

That's a strawman. You're conflating async with no communication. There's perfectly fine asynchronous communication methods. You have to communicate differently on async, not stop communicating.

[em-bee]

almost all FOSS work is async. any company that has teams across multiple timezones does async work.

for me, unless we are doing pair programming, i expect communication to be async, even if we are in the same office. you don't get to interrupt on demand, but you better wait until i am mot focused on something else, and respond to your message

[Gigachad]

I have found FOSS to really illustrate the problems of async work. It’s extremely difficult to break in as a new contributor. There is no help like in a corporate job, you can post on GitHub and hope someone gets back to you at some point, but no one is going to get on a call with you and walk through a problem or the context.

Which shows in the contributor stats where 1-3 people do all the real work and everyone else submits trivial patches.

[em-bee]

that is a very good point, but just like there are companies with good and bad onboarding, there are FOSS projects with good and bad onboarding.

it's worth mentioning here that GSOC may have motivated a lot of projects to improve their onboarding and make it easier for new contributors to join.

these are solvable problems. and bad onboarding is not limited to async work, nor is async work a hindrance to good onboarding.