Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If it will matter after today, don't talk about it in a chat room

critter.blog

Post reply on HN
Print view View original

251–260 of 329 posts

Re: If it will matter after today, don't talk about it in a chat room

#251

Post by nmaleki »

I disagree with the conclusion of the article. Using this logic, one could say that you shouldn't speak about long term projects during voice call meetings. I agree that the quality of conversation drops when speaking over chat, but I would also say that communication increases. In my opinion, the increased communication more than makes up for the decline of message quality. I also feel that the author of this article is focused on Slack and Teams. Teams or a poorly implemented slack group can feel very disorganized, so I can see how the author came to the conclusion that they did.

I disagree with the notion that "live chat is for the things that can get lost." If the chat platform you're using has advance search features, announcement channels, and message pinning you can easily find information you're looking for and, in my personal experience, this is usually faster than searching through emails. Despite their major privacy concerns, Discord has an amazing search implementation that I wish more developers would take inspiration from.

Perhaps my view is influenced in part by my young age and by the culture of the company I work for, but I've always felt that people around me waste valuable time formulating emails to try to capture all edge cases of the reply. And usually this doesn't work, so multiple follow up emails over the course of an hour or even multiple hours are needed for something that could have been solved over text chat in mere minutes.

Re: If it will matter after today, don't talk about it in a chat room

#252

Post by dredmorbius »

mumblemumble wrote: post #111
fiddlerwoaroof wrote: post #94

Earlier quoted context omitted.

What’s the difference between that sort of topics and news groups or mailing lists (with archives)? If I want information on something, subscribe; if I don’t want information, unsubscribe: I can always follow/search the archive (or read digests)

It's a second level of organization/subscription so that you can have more fine-grained control over how much you get spammed. News groups and mailing lists don't scale super well, in that, when you subscribe, you then get sent everything . Maybe not terrible for the 5-10 emails a day from my kid's playgroup's email list, but absolutely awful for trying to keep up with a team of 100 people.

when you subscribe, you then get sent everything.

1. Killfiles

2. Contextually-scoped lists. If a topic is of limited concern yet intrusive, split it to a separate list. Moderation and management may be necessary. Technical teams should be scoped correspondingly. 100+ team members is excessive, 3-15 far more typical.

Re: If it will matter after today, don't talk about it in a chat room

#253

Post by ChrisMarshallNY »

I’ve never been much of a fan of realtime chats.

Heck, I even had a personal policy of never scheduling regular meetings (they all needed to be “as-needed”).

However, I worked for a Japanese company, so regular meetings were a part of my life; whether or not I liked it.

I prefer “store and forward” communication (email is the classic form). Working for a Japanese company actually helped, there, as it was damn near impossible to have realtime chats with Tokyo.

If I use Slack that way, I do miss stuff in noisy channels, but I’ve learned to live with it (so have people I work with).

Re: If it will matter after today, don't talk about it in a chat room

#254

Post by xpe »

wpietri wrote: post #192

I find this somewhat incomprehensible. Why the bias for seeing and archiving everything? The implicit model, which is right there in his title, is "talk", which is not naturally archived. I've built products just fine using verbal communication nearly exclusively. [1] We don't need to create some sort of panoptic archive of every conversation ever had to get things done. If people miss things, they miss things. We ca…

It seems you disagree, which is fine. But that is very different from the blog post being incomprehensible.

Re: If it will matter after today, don't talk about it in a chat room

#255

Post by mkr-hn »

I forget which podcast it was on, but Automattic's CEO (Matt Mullenweg) talked about how they use blogs internally for much of their communication, so there's a huge searchable archive of information back to the early days of the company. People occasionally write posts to collect useful information that's fallen too deep.

It was probably either in his interview[0] on The Knowledge Project or a recent episode of his own podcast[1]. Probably the former since the latter usually focuses on what other people are doing instead of his own company.

[0] https://fs.blog/knowledge-project/matt-mullenweg/

[1] https://distributed.blog/podcast/

Re: If it will matter after today, don't talk about it in a chat room

#256

Post by tharkun__ »

thesuitonym wrote: post #184
tabbott wrote: post #139

Earlier quoted context omitted.

Slack and all its clones are based on the chat room model, which structurally has the problem described in this article (and many others for productivity, such as wasting attention). Fundamentally, the chatroom model pioneered by IRC is poor for asynchronous communication because you can't sustain temporally overlapping conversations in a channel. However, you can't "just use email" -- Email's threading model is grea…

I get that you're just trying to get your software out there, but your modern features that email doesn't support are just wrong. >shared history Not if you have a mailing list, and then going off the record is as easy as removing the mailing list from the CC field. >markdown formatting This is an implementation failure, not really a fundamental problem with email. There is no reason that email clients don't support…

This. I mean I get that there are various different chat or chat/email hybrid solutions nowadays that are competing with each other.

Personally though I have nothing to complain about with slack. It has threading. It only has one level threading but that might actually be a good thing because we slack with non tech people too. One thread is sometimes hard for them to grasp. Make that a regular threading model and they will utterly get lost. You can see how that completely breaks down with emails in most places.

We use slack both for synchronous and asynchronous communication. It's all about the culture and what people expect. Not really different from email. Remember the people that send you another email if you didn't answer their first one after 5 minutes?

Group chats you can just link to in a ticket instead of having to paste and reformat from a large email conversation? Priceless!

Markdown is not necessarily required. Most good email clients supported something like it, like actually displaying something like _this_ as italics or * bolded *. It's like saying "but your app doesn't do XML". Yeah well but it does JSON.

Re: If it will matter after today, don't talk about it in a chat room

#257

Post by jaaron »

ogre_codes wrote: post #61
legerdemain wrote: post #25

The problem with "trying it with my team for one sprint" is that I now need to have a long conversation with legal. How will the service provider handle the content (discussions, screenshots, code snippets) that my team will upload? Do our current customer contracts contain any clauses that complicate the use of external discussion sites? In the unlikely event that the service offers the option to host it locally --…

> just fucking use email. I get you. But also: - Email doesn't retain context very well. If I dig back through my email I might have all of the emails in a thread, or maybe not. - Likewise, I can't send someone a link to a previous emailed conversation so it makes for poor documentation. I can forward an individual email, but not the comment in context. - Email is not easy to index or post up for reference. You can't…

Mailing lists is the answer.

- Achievable

- Searchable

- Linkable

- Asynchronous

- Accessible

I like using Slack and we use it heavily with my team, but I agree it has issues.

Meanwhile, we've been using mailing lists for established open source projects for years for all of these reasons.

Re: If it will matter after today, don't talk about it in a chat room

#258

Post by xpe »

silicon2401 wrote: post #141
FalconSensei wrote: post #140

Earlier quoted context omitted.

> I have always thought that Slack is designed to make information go away, and that's why people like it. I think it's exactly the opposite?[0] People like it because, except for the free plan, you can find anything that was ever discussed. [0]: https://slack.com/pricing

This is exactly why at my org, slack is one of the de-facto sources of truth. And it's awesome. I can often find the solution to a specific, niche problem that someone else discussed 4 years ago in a few seconds. Assuming your org pays for whatever it is that allows full archival, it's a great way to capture org-specific, tribal knowledge that you won't find on google, but that nobody will take the time to add to an…

In a few seconds? Wow. I'm a very fast reader and probably need at least 15 seconds to wade through a busy Stack Overflow page.

I've found that Slack's discoverability is severely limited because it seems to prioritize low-effort input. Here's what I mean: in a busy channel, Slack makes it so easy to reply in a linear chain. Unrelated messages get interleaved. Following a train of discussion can be difficult.

In contrast, I very much like how Zulip organizes threads. It allows content to be organized both up-front (at posting time) and over time. This feels very natural to me.

Re: If it will matter after today, don't talk about it in a chat room

#259

Post by pas »

dsterry wrote: post #176
pvorb wrote: post #162

Earlier quoted context omitted.

But isn't that how the typical chat works? Where's the difference? At least that's similar to how the channels in my company are organized. The only difference might be that there's faster feedback in a chat and this leads to shorter posts/messages. But I haven't really used any forum software in the past decade, so I don't know if they don't have similar notifications and unread status icons on threads today.

The problem with chat is the interruptive, thoughtless nature of it. In a large organization, you want durability that you won't get from chat. Internal Q&A, forums, and email all work because you can have long-form conversations on them but an important consideration is discoverability. If a new user wants to find out why X is true for some service, they'd better be able to do that without interrupting someone else.

... why ... not ... just mute it? Also Slack's entire business model builds on storing chat for long and it has a not too bad search. (Though I hate it, because it's slow. But GMail is slow too. Even Thunderbird is, probably because it touches IMAP or whatever for just displaying what I'm currently typing.

VSCode is somehow fast despite running a bunch of linters/compilers/language-servers while typing, and similarly built on web tech, and ... in case of a JS/NodeJS/TS project it also handles tens/hundreds of thousands of files with ease, oh with full text search.)

Re: If it will matter after today, don't talk about it in a chat room

#260

Post by randoramax »

mumblemumble wrote: post #88
fiddlerwoaroof wrote: post #63

Earlier quoted context omitted.

Some of these are solved by things like a corporate NNTP server or mailing lists, right?

Not really, because it still doesn't give people sufficiently fine-grained control over demands on their attention. I think the ideal is the approach you get with discussion forums: Create a set of boards organized around topics, and place named, threaded conversations within those boards. People can join a board, in which case they will be able to get a list of new conversations related to that board's topic. They c…

Sounds like the approach taken by zulip. Check it out, it's a cool paradigm
Post reply on HN