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

Curing Our Slack Addiction

blog.agilebits.com

Post reply on HN
Print view View original

121–130 of 187 posts

Re: Curing Our Slack Addiction

#121

Post by Already__Taken »

stevetrewick wrote: post #98
gumby wrote: post #93

Earlier quoted context omitted.

I have a hard time agreeing that "Slack's a far sight better than email." The lack of threading and context (mentioned in AB's writeup) means you have to maintain a lot of state (and keep up to date) in order to get any value. That defeats the point of having automation! For good or ill, the 40+ year history of mail means there are various tools and conventions that allow your computer to do part of the work for you.

I recently disabled threading in my email as I have an unfortunate number of people who regularly : send mail using identical subject lines, reply to whatever my previous email to them was rather than come up with a new subject line or send multiple versions of important documents under the same subject/RE the same message over the course of months. This results in a hideous nightmare of thread spaghetti where I can'…

This is a symptom of bad address books in the email software.

Re: Curing Our Slack Addiction

#122

Post by Already__Taken »

stevetrewick wrote: post #98
gumby wrote: post #93

Earlier quoted context omitted.

I have a hard time agreeing that "Slack's a far sight better than email." The lack of threading and context (mentioned in AB's writeup) means you have to maintain a lot of state (and keep up to date) in order to get any value. That defeats the point of having automation! For good or ill, the 40+ year history of mail means there are various tools and conventions that allow your computer to do part of the work for you.

I recently disabled threading in my email as I have an unfortunate number of people who regularly : send mail using identical subject lines, reply to whatever my previous email to them was rather than come up with a new subject line or send multiple versions of important documents under the same subject/RE the same message over the course of months. This results in a hideous nightmare of thread spaghetti where I can'…

This is a symptom of bad address books in the email software.

Re: Curing Our Slack Addiction

#123

Post by jeeva »

yannyu wrote: post #42
pbw wrote: post #15

I'm wondering if Slack will ever implement something like Sococo or teamspeak's always-on voice chat. If you have not seen these it's quite a weird idea. If you are in the channel your speakers are always-on. Someone can speak to you without dialing and without you answering. They can simply say "Hey Fred..." and start talking. I have not worked with these, but did try Sococo briefly. The way this would work in slack…

Discord is a bit like Slack but focused on voice chat for the gaming community. It has voice rooms that work as you describe. https://discordapp.com/

> a bit like Slack

The UX and general usage is so similar (in my eyes), I actually assumed it was a spinoff from the same company for a good while.

Re: Curing Our Slack Addiction

#124

Post by dsr_ »

Our private xmpp server logs everything into static HTML pages. This is useful for compliance with legal things, but also for turning q&a sessions into wiki documents -- cut, paste, a little editing and you're done.

It's also, you know, private.

Re: Curing Our Slack Addiction

#125

Post by theknarf »

educar wrote: post #29

Here's my best practices list: 1. The best use of slack is the free edition which has limited history. Once this lack of history is made clear, people use it simply for online pings. Since notes, files and everything will disappear, people will automatically put the effort to put those things in the right tools (wiki, bug tracker etc). 2. Don't expect people to be online. It's the same as irc. If people are there, th…

Having build statuses posted in a channel for each commit is a great for forcing CI and CD.

Re: Curing Our Slack Addiction

#126

Post by douche »

dingo_bat wrote: post #53
tootie wrote: post #12

I love electronic communication and Slack in particular. For a distributed team, it's an absolute must that every important chat happen on Slack. Stuff spoken in person is imprecise, secretive and easily forgotten. Slack is clear, persistent, and public. Everyone is on the same page. I too feel the need to read every conversation, but compare that to having those conversations just happening without my knowledge. The…

>Stuff spoken in person is imprecise, secretive and easily forgotten. Slack is clear, persistent, and public. I don't get how verbal stuff is imprecise but slack is clear. I find it to be the opposite. It's much better to have a face-to-face chat or a voice chat than converse in writing. It's more clear and you can get more feedback from the other person. Also, if you need to be more precise, you can just write stuff…

Anything that is is written down tends to have less hand-waviness and bullshit than the random spew that comes out of people's mouths when they are making up their ideas as they go along.

Re: Curing Our Slack Addiction

#127

Post by michaelt »

kuschku wrote: post #119
ianbarton wrote: post #103

Earlier quoted context omitted.

I agree that some integrations are a gimmick, but having content relevant integrations has helped out our team immensely. We'll have channels specific to a project, so notifications that JIRA stories have been resolved, knowing if a build fails, exception logs from production, are all intertwined with us discussing the project throughout the day so they get exposure. One thing that we've loved is being able to log in…

So, in best case, the integrations are equivalent to the whole ecosystem of IRC integrations in existence? That's interesting. And still leads to the question "why slack, not IRC"?

I've asked that question myself - particularly considering how expensive slack is. Some differences include:

1. Secure usernames integrated properly into the protocol, instead of relying on nickserv and configuring your client to send a dm when you connect which is far from a simple/intuitive system. This includes options for google/corporate single-sign-on and 2-factor auth.

2. Infinite searchable scrollback which keeps position properly across multiple devices. As an experienced IRC user I can achieve something similar using ssh+screen+irssi - but it's hard to use even for advanced users, and I can't imagine trying to use it from my phone.

3. Offline messaging that doesn't rely on the user knowing the right magic commands to activate the bot. Bob is offline - do I need to !tell bob whatever or !ask bob whatever? Can I DM it to the bot to avoid spamming the channel? What's the help command? Can I use that over DM? Is there even a bot in this channel?

4. Integrations are exceptionally easy to write. You can post to a channel with a single curl command. Obviously writing IRC bots is possible, but it's a lot more complicated.

For me personally, even these differences taken together don't seem worth the expense of slack. But I would understand if other people see it differently, especially if they're not that experienced with IRC.

Re: Curing Our Slack Addiction

#128

Post by cm3 »

I've seen teams rely only on Slack for communication, including technical discussions.

I don't get it, and I'm concerned about the following:

1. proprietary service with no interoperability and high potential for loss of records

2. important technical details/arguments hidden in a chat log and not made part of a ticket/commit/comment

3. removal of async communication leading to more interruptions and less async emails one has thought about before responding

4. teams boasting the use of 10 or more channels

There are other issues with relying solely on Slack and killing off email, but these are the most important ones that always come up when I'm confronted with a Slack-only team.

I've had the same issue with IRC, so it's not my kind of communication medium to monitor 24/7, whereas I love bulk responding to emails and often ponder about a response for a while.

If there's something urgent, one picks up the phone, and usually one thinks twice before calling (interrupting) someone.

Using proper email threads, ticket discussions, etc. give you an electronic trail of the technical decision, and that's also why Fossil's inclusion of a distributed ticket system is such a great idea. Two years later, you can easily inspect how the code evolved and why it did in a certain way.

How do dev teams cope with Slack? I couldn't work without async email and use real time communications (text or voice) only on demand, in order to limit interruptions.

Re: Curing Our Slack Addiction

#129

Post by katheriin »

dbbk wrote: post #116
moron4hire wrote: post #105

Earlier quoted context omitted.

Also, email is an open standard, with plenty of choices in both client and server software. Slack is a proprietary system. Why are we actively axing solid, widely distributed, open ecosystems for proprietary ones? It'd be like if everyone woke up one day and decide "eh, Linux is just not animated-giphy enough, let's all switch to this startup OS with a crippled free version."

I don't think any of these corporations that use Slack are axing email. They still need to communicate with people outside of the organisation, right?

In fact, Slack users have reported an average of 50% reduction of internal email (source: https://slack.com/results). But you're right, Slack is a closed system, and thus it cannot really replace email when used for external communications.

This is where Fleep comes in - a messenger that works with email, too. You can include anyone in a conversation with their email address, and if they're not a Fleep user yet, they can participate in the conversation via email. Fleep: https://fleep.io/

(Disclaimer: I do work at Fleep, and I love it :) )

Re: Curing Our Slack Addiction

#130

Post by kuschku »

michaelt wrote: post #127
kuschku wrote: post #119

Earlier quoted context omitted.

So, in best case, the integrations are equivalent to the whole ecosystem of IRC integrations in existence? That's interesting. And still leads to the question "why slack, not IRC"?

I've asked that question myself - particularly considering how expensive slack is. Some differences include: 1. Secure usernames integrated properly into the protocol, instead of relying on nickserv and configuring your client to send a dm when you connect which is far from a simple/intuitive system. This includes options for google/corporate single-sign-on and 2-factor auth. 2. Infinite searchable scrollback which k…

For the first, IRC has a solution for that, too.

1. SASL auth – some servers even support Oauth via SASL, or certificate login.

2. That’s what Quassel and IRCCloud provide as a one-click solution.

3. With everyone using Quassel or IRCCloud, this also becomes easy.

4. There are many services that provide webhook -> IRC services ;)

As someone who has been using Quassel, where everyone else uses Quassel, and who uses SASL auth, all the issues you mentioned stopped existing long ago.

Add the expense of Slack, and one seriously wonders if it’s just discoverability.

Post reply on HN