Hacker News Reader

Comment by rco8786 | Hacker News Reader

Reasonable list but I do take issue with #5. Synchronous communication is incredibly important in any working environment. Else you end up waiting an inordinate amount of time getting simple answers to simple questions. Not to mention the social aspect of simply having a conversation with a co worker.

we have tools that easily enable this in a remote work environment. I’d suggest that this be re-tooled to be something more like “does the company optimize for focus time/flow time during the workday”

View on HN

That's not universally true, and by subscribing to it you limit the flexibility possible for remote work to similar 9-5 constraints regular work has. In many businesses, remote work doesn't have to be regular work but at home, and for many of us who have been doing it since before the pandemic that is actually the big draw.

Asynchronous by default means everyone is free to work when they are most productive and capable, and it really doesn't matter so long as the work gets done on time.

Funnily enough, remote work for everyone has meant some remote positions have actually gotten worse, as the line between remote lifestyle worker and regulr employee working from home has been blurred.

Fair enough. But on a list that is meant to be full of “universal truths” perhaps the better approach is to leave this out altogether then

You're probably right, at this point the Joel Test should really be the bare minimum if a company is serious about a good software development experience, whereas being asynchronous is a bit extra, and a huge shift for most businesses.

I don't read the screed as being against synchronous communication; just against synchronous communication being the default.

> Else you end up waiting an inordinate amount of time getting simple answers to simple questions

Well, this is the problem. Expecting an immediate response kills deep focus. You should have to wait for a response, for anything that isn't an emergency. Then the question becomes, what's an appropriate amount of time to wait for a response? And how can you a) measure the number of async conversations where ping pong resulted in conversations taking much more time than expected, and b) come up with blameless / systematic responses (e.g. internal wiki maintenance) to reduce that measure over time?

> Well, this is the problem. Expecting an immediate response kills deep focus. You should have to wait for a response, for anything that isn't an emergency.

This is a ridiculous assertion.

"Hey, I think we should change feature Y to do X instead, but this will have an affect on your feature. Can you absorb this into your workstream? Btw I'm writing this code right now and want to push a PR today"

... wait 5 hours because asynchronous ...

"Mmm, maybe. Could we make this slight tweak that will still get you what you want but be easier on me?"

... wait 24 hours because now it's sleeping time ..

etc.

Real-time conversations are extremely valuable. Let's not pretend like they're not.

Yes, waiting five hours to then have a synchronous conversation is one way to handle this. Another way is to not assign feature work asynchronously, but to have a synchronous meeting where the feature is assigned, to try and ensure that people are aligned before they go off and work on their own.

> Real-time conversations are extremely valuable.

Of course they are. It's the ability to have a real-time conversation on demand, with no consideration for the counter-party's focus, that is ruinous.

> “does the company optimize for focus time/flow time during the workday”

I like this rephrase too. I've recently joined a new team, and having several synced meetings helped me onboard quickly.

I hate if we need to have meetings or synced work often in the future. I don't want to be interrupted when I focus, so I like communication should be asynchronous by default.

Still, depending on the situation of team members and the project phase, synchronous communication is sometimes much more productive than completely asynchronous work. Functional teams should be able to choose better communication each time. (I know some people like synced communication too much, and it's often more problem, though...)

I think #8 (weekly syncs) illustrates that even the author doesn't believe in a 100% asynchronous world either. I value a good synchronous discussion when its possible. But between time zone differences and being flexible with people's varying home situations during a pandemic it's an exception rather than the rule.

Reply on news.ycombinator.com