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

Why we’re betting against real-time team messaging

blog.doist.com

Post reply on HN
Print view View original

141–150 of 220 posts

Re: Why we’re betting against real-time team messaging

#141

Post by Stratoscope »

dood wrote: post #76
onion2k wrote: post #71

Earlier quoted context omitted.

Real-time chat happens quickly — one line at a time — discouraging full, thoughtful conversations. Slack supports shift+CRLF for line breaks, so users can write epic poems broken up in to hundreds of stanzas if they want to. Using Slack as a one-line-at-a-time chat service is a choice that a user makes. Slack itself doesn't enforce it. Topics are all jumbled together in a channel so it’s nearly impossible to piece to…

It is true that Slack allows multi-line posts and discrete conversations, but both go totally against the grain of the system design. Expecting people to use Slack in a way it wasn't designed for can only result in failure or constant friction.

Not just the system design, but also the culture. I know a few people who post coherent, properly punctuated and capitalized sentences and paragraphs here on HN, but they write on Slack like this:

one line at a time

no caps or periods

stream of thought

enter each time

I posted a parody of this style a while back:

https://news.ycombinator.com/item?id=11239614

Re: Why we’re betting against real-time team messaging

#142

Post by nsm »

lightedman wrote: post #136
TheRealmccoy wrote: post #55

The biggest drawback of a real time communication tool like Slack is the React v/s Respond conundrum. Productive communication and teamwork requires that we respond, rather than react. What happens specifically with tools like Slack which start off as demi-official tool and then transcend to official is that, one gets into the habit of reacting, instead of responding. I have personally seen this "fastest finger first…

"Productive communication and teamwork requires that we respond, rather than react." I argue if you're too lazy to do both at nearly concurrent times then you might not be suited for that line of work. I have no problems handling upwards of 10 concurrent 'lines' (aka customer input or manufacturer input issues) on my own. Systems for this exist. Learn about them and use them, or fall by the wayside. These complaints…

This comment would have been more useful if you had mentioned some of these systems so we would know what to learn about.

Re: Why we’re betting against real-time team messaging

#143

Post by linkregister »

TheRealmccoy wrote: post #100
mediocrejoker wrote: post #96

Earlier quoted context omitted.

I have never heard of react vs respond. I wonder if you could explain a bit of what it means?

Event: Your boss shares an article on @channel at Slack. Reaction:: Since our boss has posted it and you don't want to be seemed a second rung player and the one who is NOT on her/his toes, you jump on the keyboard and first "Like/Thumbs Up" that post and then comment for the heck of it, something like "Wow", Amazing", "Insightful". Then you look over your back ie, to see how many others have commented before you, an…

This seems like the hallmark of a pre-dysfunctional workplace. None of the engineering managers I've worked with wouldn't expect their engineers to drop what they're doing and look at an article. All but one were too busy themselves to be doing that sort of thing. None would want to jeopardize their schedules by distracting their engineers. Most managers aren't trying to be friends with their engineers; they have their own friends.

Maybe this is common in startups or in teams where the manager expects to be friends with their engineers. I suppose I've been fortunate to never be put in the situation where chatting with the boss overrode doing solid work.

Re: Why we’re betting against real-time team messaging

#144

Post by linkregister »

Stratoscope wrote: post #141
dood wrote: post #76

Earlier quoted context omitted.

It is true that Slack allows multi-line posts and discrete conversations, but both go totally against the grain of the system design. Expecting people to use Slack in a way it wasn't designed for can only result in failure or constant friction.

Not just the system design, but also the culture. I know a few people who post coherent, properly punctuated and capitalized sentences and paragraphs here on HN, but they write on Slack like this: one line at a time no caps or periods stream of thought enter each time I posted a parody of this style a while back: https://news.ycombinator.com/item?id=11239614

Guilty at charged

^ as

Re: Why we’re betting against real-time team messaging

#145

Post by twobyfour »

dasil003 wrote: post #93
twobyfour wrote: post #14

Earlier quoted context omitted.

More granular controls really would fix this problem. For instance, per-channel settings to have the channel highlighted in the sidebar when it has new messages, but without badging the tab/dock. That way you could reserve the badges for the channels you really need to monitor closely, but not have to check every single other channel explicitly to see if there are new messages.

Take a look at the Channel List under Preferences -> Advanced to only show unreads, then combine that with individually muted channels. That's how I have most channels set up so I can passively aware of activity with badges.

The problem is that instead of having to check every single one of my dozens of muted channels once or twice a day, I'd like them to be highlighted in the sidebar (but not badged!) when unread. Plus it'd be nice to still get notifications of mentions and highlight words in said channels.

Re: Why we’re betting against real-time team messaging

#146

Post by skMed »

So basically a forum? Knowledge Management is a broad topic and it's hilarious seeing the same solutions brought up again and again.

I have all this persistent information! New people need to get up to speed fast - where do I put it? Cue the Wiki fad.

I have to get things done and elicit quick feedback ASAP! Cue the Chat fad.

I want async communication so I'm not bogged down all the time! Email and Forums.

There's a time and place for all of these.

Re: Why we’re betting against real-time team messaging

#147

Post by beat »

skMed wrote: post #146

So basically a forum? Knowledge Management is a broad topic and it's hilarious seeing the same solutions brought up again and again. I have all this persistent information! New people need to get up to speed fast - where do I put it? Cue the Wiki fad. I have to get things done and elicit quick feedback ASAP! Cue the Chat fad. I want async communication so I'm not bogged down all the time! Email and Forums. There's a…

I read this criticism and I think of my initial reaction to Slack - wtf are you doing a chat app? Aren't there a million options already?

I was not the only person with this reaction. I was very, very wrong.

Re: Why we’re betting against real-time team messaging

#148

Post by alexkavon »

skMed wrote: post #146

So basically a forum? Knowledge Management is a broad topic and it's hilarious seeing the same solutions brought up again and again. I have all this persistent information! New people need to get up to speed fast - where do I put it? Cue the Wiki fad. I have to get things done and elicit quick feedback ASAP! Cue the Chat fad. I want async communication so I'm not bogged down all the time! Email and Forums. There's a…

Yes this will forever be the case and engineers should get over the fact that solutions will forever rotate and be reintroduced. This is due to several possibilities: software ages, becomes unmaintained, company goes out of business, becomes too bloated, etc.

There are also trends and fads to consider, such as social media.

There is also human habits to consider. Not everyone knows about or is signed up for slack and uses it. They may eventually find out or not.

Re: Why we’re betting against real-time team messaging

#149

Post by lightedman »

TheRealmccoy wrote: post #55

The biggest drawback of a real time communication tool like Slack is the React v/s Respond conundrum. Productive communication and teamwork requires that we respond, rather than react. What happens specifically with tools like Slack which start off as demi-official tool and then transcend to official is that, one gets into the habit of reacting, instead of responding. I have personally seen this "fastest finger first…

"I have personally seen this "fastest finger first" played, almost always."

There's your problem - typing first.

Put everyone on a voice/video collab stream. Now at least you get to hear what's being suggested first like a real office, and respond without having to move away from your work window. "That idea is nonsense, it won't work within our framework guidelines for x reasons." Bam no waiting for people to read what they should be hearing in the first place.

No wonder nobody wants my solution - everyone's too busy listening to the hype of programs instead of the soundness of their workflow.

Re: Why we’re betting against real-time team messaging

#150

Post by ryanbrunner »

tzakrajs wrote: post #109

I see Slack as being real time and asynchronous because the contents of your conversation remain resident in the chat and there is no expectation that you respond immediately.

I think in practice Slack becomes a far less effective tool the more asynchronous it becomes. If a room is even halfway active, a post from a few days ago is more or less lost to history and a conversation that takes place over a few days is almost impossible to follow.
Post reply on HN