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

131–140 of 187 posts

Re: Curing Our Slack Addiction

#131

Post by Morgawr »

SunShiranui wrote: post #102
sgift wrote: post #101

I still try to understand what Slack is that IRC isn't. At the moment I'm in the "someone managed to make money out of copying IRC"-phase including copying all the problems/pain points of IRC according to this article and comments here so far (highlighting, channel inflation, multiple conversations in one channel at the same time overlap ..) - what do I miss?

I don't use Slack, but perhaps people prefer its UX?

IRC is a protocol, it has nothing to do with UX... You can tack IRC on top of a pretty client and you can get pretty similar results I'd assume.

DISCLAIMER: I never used Slack.

Re: Curing Our Slack Addiction

#132

Post by firepoet »

The article inspired me, next time I'm on a product team, to pair Slack with the discipline of the Pomodoro technique. If a notification comes in and I need to take a "soft interruption" to check it in the midst of a pomodoro, I'll respond like I would IRL: ask "I'm in the middle of a pomodoro; can I get back to you in 12 minutes?" If yes, write down a task on my to do list and return to it at the end. If no, cancel the pomodoro and reflect on how to improve our process in the future to avoid such costly interruptions.

If enough Slack interruptions happen, it will hopefully become clear that I just need to close the app in the midst of the pomodoro, only opening it on breaks, and even then only to triage to do items for future pomodoros. If not, then simply continue down that path.

The trick would be to get everyone to buy in to protecting their own time to focus. That requires a very disciplined culture indeed. One that values balancing people's ability to create with clearing other people's obstacles and above all else encourages every person to participate fully in the governance of their team.

Re: Curing Our Slack Addiction

#133

Post by swalsh »

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…

"Integrations.. are a gimmick"

I disagree, some are. Giphy, though a pleasure to have on the team is a gimmick. Hubot is an essential member of the team. Our company is deploying pretty much all day, and the integration of our deployment system with the bot scripts make things so much easier.

Re: Curing Our Slack Addiction

#134

Post by kevincox »

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

If you use a quality mail client (such as Thunderbird) it doesn't rely on subject for threading and fixes these problems. As well as displaying the replies in a proper tree rather then as a giant list.

Re: Curing Our Slack Addiction

#135

Post by phillc73 »

katheriin wrote: post #129
dbbk wrote: post #116

Earlier quoted context omitted.

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

Hadn't heard of Fleep before, but thought immediately that it might solve one use case for me.

After checking the pricing (good), if there was a self-hosted version (no, but maybe not a deal breaker) I looked for the Android app installer. Only available from Google Play Store. Unfortunately, that kills Fleep for me.

Please consider making your app directly downloadable and not reliant on Google Play Services.

Re: Curing Our Slack Addiction

#137

Post by Robin_Message »

kuschku wrote: post #130
michaelt wrote: post #127

Earlier quoted context omitted.

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

And packaging. Just picking on one of the ones you've suggested: Quassel is an app, so I can't easily try it out. I certainly can't invite everyone in my company to use it by clicking a single link in an e-mail. It doesn't have an iPhone app, I think those are quite popular. And so on.

Seriously, all these things are pretty easy, as evidenced by the fact they've been working since the 80's in the form of IRC.

The value appears to be in packaging them up as a modern web app (and having a lot of success in tech-industry PR which is where Slack has excelled beyond e.g. HipChat. But even that is partly down to the good packaging of the onboarding process).

Re: Curing Our Slack Addiction

#138

Post by Robin_Message »

Morgawr wrote: post #131
SunShiranui wrote: post #102

Earlier quoted context omitted.

I don't use Slack, but perhaps people prefer its UX?

IRC is a protocol, it has nothing to do with UX... You can tack IRC on top of a pretty client and you can get pretty similar results I'd assume. DISCLAIMER: I never used Slack.

UX != UI

Simple example: with Slack (or another hosted, web-based chat app), I can invite the non-technical head of sales to join it via e-mail, and they can. They literally cannot install an IRC client.

I can get similar results, but "I" isn't enough for a communication tool to be useful.

Re: Curing Our Slack Addiction

#139

Post by krisdol »

swalsh wrote: post #133
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…

"Integrations.. are a gimmick" I disagree, some are. Giphy, though a pleasure to have on the team is a gimmick. Hubot is an essential member of the team. Our company is deploying pretty much all day, and the integration of our deployment system with the bot scripts make things so much easier.

Agreed. We have custom integrations with Sensu and Kapacitor to alert us about HTTP 500 errors, services with high resource usage, scheduled tasks that didn't succeed, etc.

Re: Curing Our Slack Addiction

#140

Post by a-saleh »

stephengillie wrote: post #83
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…

> 2. Don't expect people to be online. It's the same as irc. If people are there, they are expecting to be interrupted / they are feeling helpful at that moment. One of the reasons I don't like Slack is that people contact me when I'm off shift. I support APAC and so work different hours from most of my company. If I have a problem, I have to either email someone, or DM someone who isn't online. Either way, my voice…

This really seems to be a culture problem.

We have long time established custom, that if you want to communicate with somebody via chat, you send him a 'ping' first, and wait if he responds.

Post reply on HN