With in-person communication, you can tell if someone has allocated attention to focus on understanding you.
With async communication, you can't. This is a source of impatience on the sender side and overwhelm on the receiver end. There isn't a way to respond to an email with "429 - too many requests" or "503 - service unavailable".
But they do. I have gotten calls from users complaining their mail had not arrived after 30 seconds. Many people seem to treat email as a kind of elaborate IM.
Interesting to read, but maybe to simplistic? I mean, asynchronous communication and synchronous communication each have advantages depending on the work. If I have to code something completely new, i want to be able to work alone with no distraction (and email is still king of asynchronous communication). If i'm debuging or if i'm doing ops stuff, having other devops around me help, whether its by my side or with a shared screen + audio. Human are not robot, and i think/feel that foc creative/innovative tasks, async is the way to go.
I was looking at a Kanbanize board right before reading this post. I asked to my customer on Slack if I should complete a subtask of a card or start a small new one, because I think I won't be able to complete both of them before the end of the day. This is asynchronous and I didn't get an answer yet. I can make it synchronous by calling him but I won't travel the 3-4 km to their office every day I'm working for them only to be able to meet face to face. We did it during the design phases and it's OK. Probably the best way to build a grand design of the system. But email, IM and boards like Kanbanize, Trello, etc are OK for everything else. And Slack or Meet for calls and screen sharing.
Unlike machines that can always respond to a request for synchronous communication, people are often having meetings, doing other work that cannot be interrupted, or in different time zones. All of which necessitates asynchronous communication -- even if the delay is only a few minutes at a time. You can't just take research about distributed computer systems and apply the conclusion to humans.
It’s not a typo, it’s a diaeresis, to indicate the second vowel is pronounced separately from the first vowel instead of being one sound. It’s a typographic convention that’s going out of style on the web.
Unusual in modern orthography, and I have only seen it in the New Yorker house style (the diaeresis indicates that the second vowel should be pronounced separately, which is quite different to how that mark is used in a number of other languages that use the Latin alphabet, like German and Turkish). This is subjective, but it reads as a little pretentious to me as a native speaker, compared with other ways of marking it.
More usual is 'co-ordinating' or just 'coordinating' without marking the syllable break between the prefix and the root.
> which is quite different to how that mark is used in a number of other languages that use the Latin alphabet, like German and Turkish
True, although there are other languages use the diaeresis to separate vowels that would otherwise be a diphthong, for example French in Noël or Spanish in vergüenza.
The New Yorker likes to add the diaeresis in words like this--it's just their style. They do the same with reëlection and other double-vowel words where the second vowel takes a different sound.
Such a clickbaity title. E-mail was meant as a replacement for the paper letter, and in this it succeeded tremendously well. It is quick, distributed, open, cheap and efficient (almost to a fault). It has been with us for decades and will still be with us after the current behemoths of the internet have sunk into their tarpits.
Trouble arises when you start using e-mail for different purposes. E-mail is not chat. E-mail is not a todo-list. E-mail is not a tool for massive collaboration. Running a business using just e-mail is as absurd a proposition as running a business using only paper correspondence.
Yet, in the same way that a spreadsheet is not a database, is not a data-acquisition tool, is not an application programming language: people have used email for all these purposes and not been completely unsuccessful.
That's why general tools are awesome: you can do things with them that the originators didn't dream would be possible -- or desirable.
I agree that it's clickbaity to question whether e-mail was a mistake, when it has clearly succeeded in being adopted around the world. After decades, nothing better has replaced it - and indeed, it will continue to be a fundamental part of the Internet.
That said, I've recently had to migrate a bunch of email addresses and what a pain it's been. The architecture is kind of a Rube Goldberg machine, seemingly overcomplicated. Add to that the incredible difficulty of hosting your own email server, I wish there would be some innovation to overhaul/redesign it with simplicity and ease of use in mind.
> E-mail is not chat. E-mail is not a todo-list. E-mail is not a tool for massive collaboration.
That sounds like a challenge: why can't we use e-mail for all those activities? I guess it would be too difficult to "bolt on" such functionality on the existing infrastructure..
The fact that people are (trying to) to use it in all these different ways suggests there are architectural limitations - not necessarily a mistake, but room for improvement or an opportunity to rethink it from the ground up.
---
Edit: After having read the article, I think that the limitation of e-mail may actually be an advantange. I love asynchronous communication because there's not an expectation to "be on call" and answer immediately.
If e-mail was redesigned to support activities like chatting and real-time collaboration, it would lose the "async" nature of it, and people would just expect instant replies. I can't stand using chat during work, it's an invitation for anyone to interrupt my thinking process. So, stay clunky e-mail, please take your time!
How do you guys find these comics when you want to reference them? Is there a better way than putting some keywords in a search engine together with site:smbc-comics.com?
Email was a good killer app for what was an incipient technology at a time (especially with most of the participants being non-adversarial)
It is certainly not for everything and today it is only usable with a thick layer of verifications and anti-maliciousness on top, but it still has its purpose.
As a freelancer, I maintain an "email-only" policy for new clients. It says so very clearly on the contact form: I don't do phone consultations for new clients.
Even so, every once in a while I get people who use the contact form and demand that I call them back. I politely respond, obviously by email, that I don't do phone consultations for new clients. I rarely hear back from them. Good riddance; I've learned from experience that people who demand synchronous communication from the start tend to be the worst clients. They always want other people to cater to their needs right now, like an obnoxious boss. People who are comfortable with email, on the other hand, are at least a little accustomed to waiting a few minutes for a reply.
The article mentions Scrum, and its synchronous daily meetings. It fails to mention that Scrum is also largely supported by asynchronous communication, like code commits, review requests, reviews and documentation.
The effect in my experience is that the purpose of the Scrum meeting is to offer a birds eye view of the asynchronous systems that make up the bulk of the development process, to enable participation and further comment. "The idea that a quarter of an hour of structured synchrony is enough time to enable a full day of work might sound preposterous" because it is. It's just there to kickstart the day and to give everyone a general idea of what's going on.
For anyone doubting this, I suggest skipping a scrum meeting to see how much it actually impedes your work. Then, if you dare, try to avoid using the asynchronous communication that supports the development process for a day. Compare the results.
Overall I just think that people should consider more carefully whether a topic is more suited for email, phone call or a meeting.
It depends on the situation. Email should be accompanied by a messaging system that a) lets you know if the other person is available to chat, and b) provides real-time interaction.
The combination is more efficient than phone or video conferences, and much more efficient than in-person conferences, especially those requiring a plane trip. These more often involve social banter and often include participants who are only marginal contributors or time wasters.
No it shouldn't. You shouldn't know when I read your email; and if I want to be available for a chat, then I'll have a chat client of some kind (including Signal/Telegram/WhatsApp) to begin with.
Certainly email lists as a discussion medium were always doomed. ;-)
I remember taking part in the first mailing list (1973?) on the ARPAnet, which was, appropriately enough, about mailing lists, hosted by BBN. Flame wars sprung up day and night, even with only a few dozen people.
Email is just a reflection of the humans that use it, so, sure it's a disaster, but still quite useful.
> E-mail was supposed to make our work lives easier and more efficient
Email was supposed to allow us to send textual messages, e.g. letters, notices etc., through computer networks and in a computer-viewable, computer-editable format. And it has done that.
> but the mathematics of distributed systems suggests that meetings might be better.
Huh? that makes absolutely no sense. Very little of my email is even theoretically replaceable with a "meeting" (not the least of which - automatic notifications.) As for the rest of my email - if I had to hold 10-20 meetings a day I'd go nuts.
> They became convinced that synchrony was superior and that spreading communication out over time hindered work rather than enabling it.
No they didn't. Author is probably ridiculously over-generalizing some finding on a certain specific setting and a certain irrelevant metric.
> A major implication of research into distributed systems is that, without synchrony, such systems are just too hard for the average programmer to tame.
Yup, just like I thought. Totally irrelevant. How is reading email a programmatic taming of a system? It isn't. and so on, and so fort.
46 comments
[ 3.0 ms ] story [ 94.9 ms ] threadWith async communication, you can't. This is a source of impatience on the sender side and overwhelm on the receiver end. There isn't a way to respond to an email with "429 - too many requests" or "503 - service unavailable".
(EDIT: Note that I do agree with your sentiment!)
Not with email, but there's no reason in principle an async communication system can't do that.
Pleased that they are two separate apps so you can turn one off when when you just need the other.
1. To show your boss that it is someone else's fault - delays etc
2. To show that it is not your fault there is going to be a delay as a deadline approaches.
I got the answer now, back to work.
As a non-native speaker, I wonder: is this a typo or intentional?
It is somewhat archaic.
https://en.wikipedia.org/wiki/Diaeresis_(diacritic)#English
https://www.newyorker.com/culture/culture-desk/the-curse-of-...
More usual is 'co-ordinating' or just 'coordinating' without marking the syllable break between the prefix and the root.
True, although there are other languages use the diaeresis to separate vowels that would otherwise be a diphthong, for example French in Noël or Spanish in vergüenza.
Trouble arises when you start using e-mail for different purposes. E-mail is not chat. E-mail is not a todo-list. E-mail is not a tool for massive collaboration. Running a business using just e-mail is as absurd a proposition as running a business using only paper correspondence.
That's why general tools are awesome: you can do things with them that the originators didn't dream would be possible -- or desirable.
That said, I've recently had to migrate a bunch of email addresses and what a pain it's been. The architecture is kind of a Rube Goldberg machine, seemingly overcomplicated. Add to that the incredible difficulty of hosting your own email server, I wish there would be some innovation to overhaul/redesign it with simplicity and ease of use in mind.
> E-mail is not chat. E-mail is not a todo-list. E-mail is not a tool for massive collaboration.
That sounds like a challenge: why can't we use e-mail for all those activities? I guess it would be too difficult to "bolt on" such functionality on the existing infrastructure..
The fact that people are (trying to) to use it in all these different ways suggests there are architectural limitations - not necessarily a mistake, but room for improvement or an opportunity to rethink it from the ground up.
---
Edit: After having read the article, I think that the limitation of e-mail may actually be an advantange. I love asynchronous communication because there's not an expectation to "be on call" and answer immediately.
If e-mail was redesigned to support activities like chatting and real-time collaboration, it would lose the "async" nature of it, and people would just expect instant replies. I can't stand using chat during work, it's an invitation for anyone to interrupt my thinking process. So, stay clunky e-mail, please take your time!
https://www.smbc-comics.com/comic/2010-11-26
It is certainly not for everything and today it is only usable with a thick layer of verifications and anti-maliciousness on top, but it still has its purpose.
Even so, every once in a while I get people who use the contact form and demand that I call them back. I politely respond, obviously by email, that I don't do phone consultations for new clients. I rarely hear back from them. Good riddance; I've learned from experience that people who demand synchronous communication from the start tend to be the worst clients. They always want other people to cater to their needs right now, like an obnoxious boss. People who are comfortable with email, on the other hand, are at least a little accustomed to waiting a few minutes for a reply.
The effect in my experience is that the purpose of the Scrum meeting is to offer a birds eye view of the asynchronous systems that make up the bulk of the development process, to enable participation and further comment. "The idea that a quarter of an hour of structured synchrony is enough time to enable a full day of work might sound preposterous" because it is. It's just there to kickstart the day and to give everyone a general idea of what's going on.
For anyone doubting this, I suggest skipping a scrum meeting to see how much it actually impedes your work. Then, if you dare, try to avoid using the asynchronous communication that supports the development process for a day. Compare the results.
Overall I just think that people should consider more carefully whether a topic is more suited for email, phone call or a meeting.
The combination is more efficient than phone or video conferences, and much more efficient than in-person conferences, especially those requiring a plane trip. These more often involve social banter and often include participants who are only marginal contributors or time wasters.
I remember taking part in the first mailing list (1973?) on the ARPAnet, which was, appropriately enough, about mailing lists, hosted by BBN. Flame wars sprung up day and night, even with only a few dozen people.
Email is just a reflection of the humans that use it, so, sure it's a disaster, but still quite useful.
No.
> E-mail was supposed to make our work lives easier and more efficient
Email was supposed to allow us to send textual messages, e.g. letters, notices etc., through computer networks and in a computer-viewable, computer-editable format. And it has done that.
> but the mathematics of distributed systems suggests that meetings might be better.
Huh? that makes absolutely no sense. Very little of my email is even theoretically replaceable with a "meeting" (not the least of which - automatic notifications.) As for the rest of my email - if I had to hold 10-20 meetings a day I'd go nuts.
> They became convinced that synchrony was superior and that spreading communication out over time hindered work rather than enabling it.
No they didn't. Author is probably ridiculously over-generalizing some finding on a certain specific setting and a certain irrelevant metric.
> A major implication of research into distributed systems is that, without synchrony, such systems are just too hard for the average programmer to tame.
Yup, just like I thought. Totally irrelevant. How is reading email a programmatic taming of a system? It isn't. and so on, and so fort.
What a trollish article.