1. 18
  1.  

  2. 9

    I love email, but in my experience there two things that make it an annoyance in almost every company I worked:

    1. No-one understands basic mail hygiene. That means that maybe you should not have every tool spam every unimportant message to every member of the team. I don’t switch jobs that often, but the times I started a new position I had always a full inbox at my first login. One time there were even thousands of mails in there. Yes, you read that right. No wonder people dislike it. Then Google (and others) step in and offer to “help” you manage all those mails, always with some kind of model that apparently was trained by a group of drunk monkeys, which only increases the noise.

    2. People don’t know how to write a full sentence anymore, let alone a whole paragraph. Without the real time back and forth of Slack to clarify things, this causes a lot of miscommunication and frustration. Reading more than a few sentences one after another is hard too, it seems.

    In short: email is still the same, but the people using it are not.

    1. 4

      Without the real time back and forth of Slack to clarify things, this causes a lot of miscommunication and frustration.

      I was talking about this with a friend the other day. Her and I both treat email more like sending a letter, but many of her coworkers will send several emails on the same topic, each containing a snapshot of their current thinking on a subject. This latter “style” is what you’d expect to see on Slack (and, indeed, the organization also uses Teams).

      I don’t think it’s that people don’t know how to write a sentence, though, because some of those same people do just fine when they email people outside the organization, etc. But when talking to a coworker, they drop into a “conversational” mode. Ultimately, they should probably just use Teams for those messages.

    2. 8

      I sometimes feel like the only person here who hates email for anything other than longer-form communication with one or two other humans. No, I don’t want to comment on pull requests over email, there’s a lovely web interface for that that shows me syntax-highlighted diffs and lets me dig further into a diff easily. No, I don’t want to manage task tickets over email, there’s also a lovely web interface for that and it shows me a visual representation of what’s happening. No, I don’t want to receive an email when something needs my attention, that’s what Slack (or whatever) is for. No, I don’t want to have large discussions over email, I want to see the conversation thread visually and not have to worry about accidentally including a mess of nonsense in my reply (I absolutely would not read Lobsters if it was an email list). And it’s not like I’m a youngster who has never used email, I started using email in the mid-90s. I just don’t understand why everyone loves it so much.

      1. 4

        No, I don’t want to have large discussions over email, I want to see the conversation thread visually and not have to worry about accidentally including a mess of nonsense in my reply (I absolutely would not read Lobsters if it was an email list).

        Don’t forget forget the top vs. bottom posting or plain text “debates”, which everyone in the real world ignores because they use graphical email clients. A lot of email enthusiasts feel detached from the reality of how people actually use tools when they get into it.

        1. 2

          Because it is familiar, reliable, and it doesn’t change out from under me every time some web designer chasing the fad of the week gets a wild hair. Web based mail user agents change that picture a bit, because the user ends up being at the mercy of web designers, but I don’t use those.

        2. 4

          There is a third dimension that his analysis is lacking: persistence, the quality of being available for long durations without human intervention. A ticket comment system is maximally persistent. A wiki may be persistent. A centralized, searchable email list is maximally persistent, but personal email conversations may be quite transient. Some chat systems are searchable and persistent, some are terrible at making history presentable.

          1. 3

            My preference is an issue tracker with excellent email integration. Everyone gains.

            At my last job we used RT, and most of my ticket-tracking workflow was through email. RT provided organization, mediation, and long-term storage. I loved it.

            1. 1

              My team (IT and Ops) uses RT for issue tracking, but the dev groups have insisted on JIRA for a while. We’ll need to get them over to something else in a couple of years, since self-hosted JIRA is going away.

              1. 3

                That’s really weird, I’ve never seen an org where the devs have preferred JIRA over anything, it’s always been PM and management.

            2. 1

              The Dovecot project runs a public read-only IMAP server for their mailing list archives. In theory, this is great because you can just add that server and then reply to threads and messages before you joined the list. In practice, the UI for this kind of thing is terrible in most mail clients and is even worse when you consider multiple clients and wanting to be able to access it from your desktop / laptop / tablet / phone / whatever. If you’re running your own Dovecot server then it’s fairly easy to add a read-only folder that’s actually backed by a remote IMAP server.

              I’d love to see some standardisation around this so that I could just click on a link and have my mail client tell my mail server to act as a proxy for a remote read-only IMAP server with that folder appearing in my normal IMAP folder hierarchy.

              1. 3

                I really appreciate public-inbox for this. It is an “archives-first” approach to list management, and archives are available through the web, NNTP, or IMAP. Personally I use NNTP to read lists that have public-inbox archives; it’s pretty easy to add a new group to my newsreader, even if it is hosted elsewhere than my primary NNTP server.

              2. 1

                That is a good point as well. Whenever I advocated for email-based workflows in person, I always mention mailing list archives and how they can be an invaluable tool for people trying to figure out a reason for something long after the author left the company. Somehow, that aspect slipped through the cracks in this post.

                I’m a bit skeptical about calling ticket comment systems maximally persistent. I haven’t had that many jobs in my career, but it seems like every organization is constantly in the process of migrating to a new wiki and a new ticketing system. Because you need to run software to serve the comments in the “old” ticketing system or wiki (i.e., the raw database contents are kind of useless without a viewer), I consider them equally unreliable as far as persistence is concerned. (Not to mention that during the prolonged migration, you have two systems and so people ignore one anyway - and it’s not always the old one!) Serving mailing list archives can be anywhere from complicated (fancy web UI reader) or extremely simple (static mbox people can import as needed).

                I agree that personal email conversations, even though they are email, aren’t great for communicating with your team. But this is no different from using any other 1:1 medium and so a bit out of the (implied?) scope of the post - team-wide communication.

              3. 1

                I meant to tag with “email” and “practices”. But a11y works too…