Hacker News Reader

Comment by EqNoteqp | Hacker News Reader

I get the intention with Slack. I’ve never understood, except for the geek cred, pushing work into chat services. Github is open to the team too.

I hear complaints about chat distractions and see engineers create those distractions. I’m at a loss why we want to do that to ourselves?

Nevermind it’s one more pipeline for messages to lost in. It’s needless complexity and configuration too.

View on HN

The main reason is to use a chat solution is as a unified ledger / single pane of glass. Silly as it is, there isn't really a better solution out there for "integrate all of my third-party deploy, CI, build, etc. status updates in real time, in one place." Sure, someone can click into GitHub, but if you use another service to deploy into, does GitHub pipe the status of that service into your dashboard? How about error logs and alerting, do they go there? If there's a customer incident, does the trust site status show up as well?

On Slack and other chat solutions, it's possible to set up a #operations style single-pane-of-glass channel with deploy notifications, error alerting, and customer communication platforms all pushing to the same place. If an incident occurs, engineers, product, support, etc. can all collaborate around what's going on in real-time without needing to ask "hey has someone updated the trust site yet?" or click into 10 different tabs.

It's honestly pretty good when it works well and really bad and noisy when it doesn't, but it has a place.

Non-engineering are usually in Slack too, which really helps when support, product, or the field need quick answers to easy questions like "has this commit been deployed yet today?"

Perhaps for looking back to see the history of things, a unified ledger is convenient. But as a notifications/alerts solution it’s terrible because it essentially guarantees that the signal to noise ratio will be incredibly low.

This just depends on how disciplined you are. We use a system where backend errors are logged to slack, and then we treat addressing the source of the errors as an immediate priority. Keeping the SNR high is a priority. Plus generally being very selective about what goes into the channel.

Chat is a multi-player CLI. Anything you would do in a terminal that your team members should also know about can profitably be integrated with chat.

I'd never, ever go back to working without chat.

We've switched to Discord (because reasons. Slack is much better for work though) and I rewrote a bunch of Slack hooks to get Dicord notifications.

> I hear complaints about chat distractions and see engineers create those distractions.

People will complain no matter what.

Reply on news.ycombinator.com