Live data from Hacker News

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

critter.blog

171–180 of 329 posts

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

#171

I disagree with this article. This is what was said about GMail when it first came out - you need folders, without folders you can't keep organized, etc. Turns out indexing and mechanisms to make use of that indexing (labels, advanced sorts, filters) work better than folders. Persistent chat that can be labelled, indexed, searched and filtered is amazing for work related chats, or any chat that becomes part of a long…

The sheer volume of information that Chat holds makes it hard to search. The noise to signal ratio is higher than on channels with lower throughout (e.g. documentation products). Chat doesn't let you send one message and craft it over time, like a mission statement, proposal, or architecture guide. It has a fundamentally different character.

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

#172
Slack isn't a bunch of chat rooms, it's a database disguised as a bunch of chat rooms. I've never had a problem pulling up some random conversation from three years ago as long as I remember the general topic.

In that regard it's no different than using email, everything is indexed and you're just searching a different database.

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

#173

Earlier quoted context omitted.

I don't know of any productivity tool that handles archiving well. You can store done tasks in some way, but all the context is lost. Over time, it's annoying even on a small - individual - scale.

I think Azure DevOps handles context pretty well. I can look at old tasks and see associated commits, conversations, and related work.

yeah, the info is there and you can do the same with most tools, but it often requires a lot to extract it. how well organized is it? how hard is it to go from line of code to complete discussion around when it was last changed?

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

#174
> I’m not saying live chat is useless. It’s great at some things:

> - Quick answers to quick questions

> - Low-stakes status updates

> - Swarming around red alerts or outages

Well OK, but the problem is that sometimes those things also matter after today. So in practice, it often does end up being better to just save everything in an indexable form, because you can't realistically decide in advance to every conversation whether or not it's going to be important. You can pretend to, you can put every conversation you're going to have in one of those bins -- but you'll just be pretending, you're not going to get the prediction right every time.

The second problem is that sometimes conversations fluctuate and change form, and it is not uncommon to have a good long-form conversation that needs to occasionally dip into quick questions and status updates. When the boundaries between your chat environments are too rigid, you can have the same productivity losses because people delay having important conversations or just avoid them entirely. This kind of categorization of communication often ignores that communication is extremely fluid. You can change between longform training and technical discussion, quick status updates and questions, and even affirmation multiple times during the same conversation.

Most people on HN already understand how much harm context switching and interruptions can be for productivity in programming. But the same can also be true in communication. If you're in the middle of a chat and there's a clear opportunity in-line with what you're already talking about to explain something or reach a decision, you are basically imposing a giant context switch if you say, "well, no, don't talk about it. Let's all schedule a meeting." Or even if you just say, "keep it in your head until you get back to your desk and then email me."

Sometimes that interruption is warranted, and sometimes it costs a lot of focus/productivity for very little gain. It's situational.

I'm not sure it's wise to have binary rules about how and where people on your team should communicate. A lot of the advice I see around team organization and management ends up being generally good advice but taken to the extreme, where it wraps back around to being a barrier to actually getting stuff done. Encouraging people to use email for longform technical discussion is a good idea, but I suspect that trying to make some kind of policy about may be a bad idea for most orgs.

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

#175

Earlier quoted context omitted.

I hate it when I'm emailing someone with a deliberately long response and by the time I send, the thread has already gone on and I have to re-merge it.

The obvious solution here is to not merge the whole thread into your email, instead including only the parts of the message that are directly relevant.

I’d like to see email clients offer a nice one-click “rebase on top of latest” button.

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

#176
post #162

Earlier quoted context omitted.

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…

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.

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

#177
post #166

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…

We've been using self-hosted Zulip for about 18 months now, and it's exactly what our company needs. I have been recommending it right and left to people who don't need federation in their chat system. If there was a clear gateway to federation -- enabling a Matrix room as a Zulip Stream, for instance -- I would enthusiastically recommend it for everyone.

Same here. If you like email, Zulip is what you need.

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

#178

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 --…

Use Zulip. It solves all the problems that email has and also enables a bunch of other things you never knew you needed, like a sane model for browsing messages.

It can even serve as real-time communication for #random and other such work-adjacent channels.

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

#179

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…

I've commented this too much in this thread, but it's important: Zulip solves all this, has other advantages and a fast and extremely usable interface.

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

#180
post #145

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…

Zulip really hits the sweet spot for a communication tool. Especially with large amounts of users communicating across many different threads. The FHIR community "chatroom"[0] is a Zulip server and is indispensable for communication and knowledge building across thousands of users. [0] https://chat.fhir.org/#

I signed up for that to see what Zulip is like, but there are only 19 messages visible if you do that, so I shouldn't have bothered. It seems nice, I guess.
Post reply on HN