[fs2]

My experience exactly. The most common observation with Slack is how people praise it as the next big thing in productivity. But this is always during the honeymoon phase, after a few months of working with Slack it usually quickly wears off.

[rjdagost]

I think the worst part of it (as the article mentions) is that it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not. You're generating conversations, notifications, and in general producing tangible output that for me is subconsciously gratifying. That hooks me in to using the service even though consciously I know that I'm not getting real work done.

[ethbro]

The benefit I've found is in cross-team communication.

Specifically of the "I need to reach out to this team I don't know about their product" variety.

A) If they interact with Slack, I can search previous answers

B) It promotes a culture of openness. Huge benefit in some orgs! We talk about our projects, warts and all, in public channels. If all your org channels are private, you're definitely Doing It Wrong

C) It's far more scalable than ticketing. Issues can be resolved in three lines of text, rather than ticket creation, queue, assignment, closing, etc.

As an above commenter noted though, you can and should push back on expectations of constant availability. Slack is asynchronous, not for initiating hi-pri issues.

[Jedd]

> Slack is asynchronous.

You are describing a proprietary, expensive, intrusive, demanding rewrite of SMTP.

[StavrosK]

I very much like Zulip, it's open source and much closer to email, even culturally. It encourages long-form replies and messages with subjects, so it requires at least a tiny amount of thought before you start talking to someone. I think it's a great cross between Slack and email.

[ethbro]

Just looked at it.

What keeps Zulip threads from exploding in practice? Either on the UI or usage side?

E.g. How to I keep from going from "One channel with a hundred unread messages" to "One channel with twenty unread threads"?

Also, what features exist when a thread diverges from the original topic?

E.g. We were talking about the "afternoon lunch" at the "annual meeting", and then someone mentioned their favorite restaurants in the area, and now people are replying to both?

Organization seems more like a usage problem than a technology problem. Or at least one that I can't see manual categorization solving.

[tabbott]

The point is that it's a lot faster to process 20 unread threads with 100 messages than 100 unread messages, because they're nicely grouped. E.g. you can skip reading the 30 messages in the thread about "afternoon lunch", without having to look at those messages (as you would with slack if you wanted to find out that the 'annual meeting' announcement happened).

For diverging topics, you can easily edit the topics of the messages that are a diversion to be a new topic. This helps a huge amount when you have new users who haven't learned the convention of creating a new topic when bringing up something unrelated, since anyone can clean it up in a few seconds.

[ebiester]

The protocol isn't the issue.

It's like SMTP, if nearly every conversation went to list-all and our email clients were designed to intelligently allow us to choose what sub-section of the thousands of messages a day are important to us.

Or, like we already knew, it's an expensive, intrusive, proprietary upgrade of IRC.

[ethbro]

This is the Slack vs Jabber/XMPP debate. Pro and cons for each side.

But Slack is certainly easier to install and use (by being centralized).

[grogenaut]

Don't forget mailman + elastic search.

[Agathos]

> It's far more scalable than ticketing. Issues can be resolved in three lines of text, rather than ticket creation, queue, assignment, closing, etc.

My experience has been that it goes on for thirty or three hundred lines of problem report -> steps to reproduce -> troubleshooting -> proposed solution -> etc. Two days later someone else gets pulled in so they look at a Jira ticket with an empty description and zero comments...

[ethbro]

It's a balance.

At some point, a channel should be created for the issue (if long lived) or Slack conversations transplanted onto a ticket.

On the other hand, I've had an equal number of times where ticket formalism led to a misunderstanding, someone on another team taking an incorrect action, and a couple weeks to get resolved.

Work that could have been saved with 10 minutes of direct communication.

Or the dreaded hot potato ticket that out of misunderstanding / laziness gets reassigned to different teams, until a week passes without any actual work done.

So, I guess the optimal solution is to know what each tool is good and bad at, and let those guide actions and policies.

[tw20190412hbqcg]

> it feels like you are doing something productive when you're using Slack, but the majority of time you're actually not

That's been my main complaint about GitHub throughout its meteoric rise. Its public contribution graphs and user profiles littered with hundreds of dead forks certainly encourage this behavior.

And I say this not as a person who has an unreasonable disdain for things like business processes and engineering tools (such as bugtrackers); I tend to favor (good) process more than other people—I've had personal projects where I'm the only contributor and user, and yet if you peek into the bugtracker you'll see hundreds of comments from me explaining exactly what's going on wrt the root cause and any fixes, and all known issues at any given time have an appropriate bug on-file.

But when I use GitHub, it's like every interaction ends up getting sidetracked either due to input from users trying to feel productive by leaving comments that are ultimately value-negative, or some weirdo contributor responding to my bug report as if I'm filing a support request and who then tries to "help" me by explaining how I can work around it (I have no problems working around it—in fact, by the time you're hearing from me, that's old news. But this is a bugtracker! For, you know, tracking bugs!), or the peanut gallery using the bugtracker like it's a phpBB forum dedicated to general chatter and expressions of gratitude related to the project (instead of, you know, tracking bugs!).

The worst is when somebody is showing off a project, I take a look, find something like a simple typo, and let the person know, and then they ask me to file a PR. First, I'm probably not even interested in your project even as a leeching user. Secondly, if you can't be bothered to do anything about this thing in your own project that you already understand that that you probably already have opened in your IDE right now, do you really expect me to clone the repo, poke around until I understand the busted directory structure you're using to organize the code, locate the appropriate source file, commit it, and then use GitHub's needlessly convoluted pull request workflow that involves pushing those changes to a third fork and asking you to review them? Do you understand that all this is happening on top of the assumption that I even have a GitHub account in the first place? Why don't you just Alt-Tab over there and help yourself instead of offloading work onto some random stranger who has no vested interest in your project but who decided to spend a little effort typing out a message that would be of interest to the person currently pimping out their project?

... and then every time I mention this, someone comes around, totally misses the point, and leaves an obnoxious comment that "You don't have to clone the repo! You can make minor fixes like that from the GitHub web UI!"

It's like nobody knows how to distinguish between busy work vs things that are actually necessary to the process and/or indicators of real, forward motion.

[res0nat0r]

People keep wanting to blame Slack for this problem, but it really is the folks you're working with who are the issue.

Slack is getting such a huge valuation so quickly because it is incredibly simple to use and is very user friendly. IM tools like Skype / Sametime / whatever have been around for companies forever, but Slack is much more user friendly and frictionless to use from the ground up, and with plugins even more useful.

I think most of the hate here keeps coming back to issues with peoples coworkers, not whatever IM platform they want to dislike that is currently making tons of cash.

[skohan]

I find it has utility in the fact that it's a searchable record of technical conversations I have had with my colleagues where I can go to recover details I might not remember from a month ago. Then again email also does this just fine, and doesn't cost as much.

[grogenaut]

Search is one of slacks worst features and I resort to scrolling which is also majorly painful. I can count on one hand the number of times I've found what I needed via slack search in 4 years with it. I've had it be unable to find the exact text of a message on screen in a channel I'm searching in a day later (tested).

[alehul]

Search is one of my favorite parts of Slack.

It assumes that I want to search within a certain channel or messages with a certain person when that's where I'm clicking the search bar from, but I can quickly erase that if desired. Files, messages, and people, are all searchable. It's pretty powerful and extremely user-friendly (most non-techies would have trouble with the syntax for specifying who a message should be from while searching).

Meanwhile, with Gmail, I discovered yesterday that when I'm part of a mailing list attached to an email address (let's say [e-mail]), and I search an email address that was cc'd on the [e-mail] email, nothing comes up. Resulted in a lot of wasted time.

[jasonlotito]

I'm gonna also have to disagree. Slack search works. I can rely on it to save the information needed, and my ability to recover it.

[strokirk]

I've got to disagree completely - my search experience with Slack has been really great, even surpassing Gmail, which I also like. There are a lot of tools to dig in to results bit by bit, and they're cached so returning to the search screen is fast after you've investigated a hit.

[tanseydavid]

I will have to agree, the search feature in Slack is nearly useless. Or, perhaps 'I am using it wrong' to join in the chorus.

[jbay808]

Email doesn't do this just fine. If a new employee joins your group, how are they going to search your inbox for records of technical discussions that they never were part of?

[retzkek]

Email lists and newsgroups have been around for a very long time, and are often archived. My organization still runs a listerv for this very purpose.

[icedchai]

Put that stuff in a Wiki. Or pull requests.

[jbay808]

By "that stuff", do you mean "technical communications you have had with colleagues", such as what Slack or email might otherwise be used for? That is what the GP was referring to.

It's hard to imagine using a wiki for that, but if that's how you do things I guess it's fine. As long as it doesn't rely on people copying their email discussions to wikis manually. Not sure how you'd be alerted by an important wiki update that you need to respond to, though.

[icedchai]

Let's use a concrete example. A new engineer joins your company and needs to set up a dev environment. This environment has changed many times over the years. Do you point them to Slack, Email, a Wiki, or a shared Google doc? In any sane company, it is one of the latter.

[jbay808]

Replying a little late, but we are discussing

"technical conversations I have had with my colleagues where I can go to recover details I might not remember from a month ago. Then again email also does this just fine, and doesn't cost as much."

For static instructions like setting up a dev environment? Sure a wiki is perfect. But I don't use a wiki for technical conversations like "Hey icedchai, I'm getting an error message that the COM port is not detected and I remember you said something about solving it in yesterday's standup. Can you point me to where the fix was?"

That message is better suited for slack or email than a wiki. (Your solution might be in the wiki but I'm contacting you because it wasn't easy to find, or searching for the error message didn't turn it up).

But if I use email, then when we hire a new employee a month later who gets the same error, your answer will be in my records but not theirs.

Another poster suggested a mailing list, that is a good option that makes email viable for this.

[mikewhy]

So search multiple places instead of just the one?

[icedchai]

If you use a Wiki for everything, no. However, that is unlikely. You'll have to search more than one place anyway. Making Slack your primary store of institutional knowledge is unwise. Chats are full of garbage, random discussions, old / bad decisions, etc.

[skohan]

And there's no guarantee that slack will exist forever.

[dajohnson89]

there's a hidden danger of using slack as a record of technical conversations: people start to rely on it, and less formal/rigorous specifications fall by the wayside.

but as i'm starting to learn: nobody really documents things anyways.

[icedchai]

Nobody really documents things because that's not "agile." Agile is do it now, break it later, fix it in the next sprint.