The Unwritten Rules of Slack Etiquette for Devs

Source: Dev.to

Don’t Say “Hi” and Wait

This one is so common there’s literally a website about it: . Yet every single day, in Slack workspaces around the world:

You: “Hey, are you free?”

…and then… nothing. No context. No question. Just a vague, anxiety‑inducing message sitting there while the other person drops what they’re doing and waits.

Do this instead: Lead with your question and give context up front.

You: “Hey! I’m working on the auth‑middleware refactor and I’m running into a weird issue where the token refresh silently fails on 401s. I’ve tried wrapping it in a retry but it loops indefinitely. Have you seen this before, or know where I should look?”

Now the person on the other end can triage the request, decide when to respond, and give you a useful answer without a five‑message ping‑pong.

Thread Your Replies

Threads exist for a reason: to keep #backend (or any channel) from looking like a Twitch chat.

• When someone posts a question or an update and you have a follow‑up, reply in the thread.
• When three people are troubleshooting something together, do it in the thread.
• When you want to drop a related link or a “same here,” thread it.

Unthreaded conversations in busy channels are genuinely hard to follow. You end up scrolling through 40 messages trying to figure out which reply belongs to which question, and half of it is two separate conversations overlapping. It’s like trying to listen to two podcasts at once.

Exception: If a thread reaches a conclusion that’s useful for the whole channel, post a short summary back in the main channel. The discussion itself? Keep it in the thread.

@channel and @here Are Emergency Levers, Not Megaphones

Here’s a rough guide:

If you use @channel to ask if anyone wants to grab lunch, you’ll develop a reputation you don’t want. People configure their notifications carefully, and when you pull the @channel lever for something non‑urgent, you train everyone to ignore those pings entirely, which means real emergencies get missed too.

Use Code Blocks, Please

Slack has perfectly good code formatting:

• Single backticks for inline code: `code`
• Triple backticks for blocks:

def please_format_your_code():
    your_teammates_will_thank_you = True
    return your_teammates_will_thank_you

When someone pastes a stack trace or a config file as plain text with no formatting, it turns into an unreadable blob where indentation is lost and everything smears together. It takes two extra seconds to wrap it in backticks, and it makes the difference between a message people will actually read and one they’ll scroll past while squinting.

If it’s more than about 15 lines, consider a snippet or a Gist link. Nobody wants to scroll through 200 lines of JSON in a Slack message.

Respect DND and Status Messages

When someone’s status says 🎧 Focusing, back at 2 pm, that’s not a suggestion—that’s a boundary. If their status is set to Do Not Disturb, your message isn’t so urgent that it overrides whatever they’re deep in. It can wait. It almost always can wait.

And on the flip side: actually use your own status. If you’re heads‑down on something, set DND. If you’re at lunch, say so. If you’re off for the day, mark it. It helps your team calibrate expectations and reduces “hey, are you around?” clutter in your DMs.

The “Quick Call?” Message

This one’s nuanced. Sometimes a synchronous conversation genuinely is faster than a 30‑message back‑and‑forth. Complex debugging, architecture discussions, or anything where tone matters: a quick call can save everyone time.

But “quick call?” with zero context can feel like being summoned to the principal’s office. If you want to hop on a call, give a reason:

“Hey, I’m going back and forth on how to structure the new event system and I think 10 minutes on a call would save us an hour of typing. Are you free in the next bit?”

That’s respectful. It gives the other person the option to say, “Actually, let me just send you a diagram; I think that’ll clear it up,” instead of feeling like they have to drop everything and join a call right now.

Compose Your Thoughts Before Hitting Enter

You know the person who sends messages like this:

hey
so
I was looking at the PR
and I think
there might be an issue
with the way we handle
the cache invalidation
actually nvm
wait no
yeah there's def a problem

That’s ten notifications for what should have been one message. Every line triggers a ping, a badge, a vibration. On mobile, it’s especially brutal. Take a brea

Emoji Reactions Are Underrated

Reactions are one of Slack’s best features for keeping noise down, and most teams under‑use them. A quick emoji can replace an entire message:

• 👀 – “I’ve seen this and I’m looking into it.”
• ✅ – “Done” or “Taken care of.”
• 👍 – “Acknowledged” or “Sounds good.”
• 🎉 – “Congrats” or “Nice work” (without flooding the channel with 12 separate “congrats!” messages).
• ➕ – “I agree” or “Same here.”

When someone posts an announcement and 15 people each reply “thanks!” it buries the actual message. A bunch of 🙏 reactions communicates the same thing without turning the channel into a wall of one‑word replies. Start using reactions more and watch how much cleaner your channels feel.

Default to Public Channels

There’s a natural instinct to DM people with questions, especially when you’re newer to a team and feel like you might be asking something obvious. Fight that instinct. Most of the time, the question you have is one that someone else will have next week, and if you ask it in a public channel, the answer becomes searchable.

• DM – great for genuinely private stuff: personal matters, sensitive feedback, things that only involve the two of you.
• Public channel – ideal for technical questions, project updates, “does anyone know how X works?” – those belong in channels. You’re not just getting help for yourself; you’re creating a knowledge base for the whole team.

The exception is if you need to give someone direct feedback or discuss something sensitive. Use your judgment, but when in doubt, choose the channel over the DM.

Async Is the Default, Not the Exception

Your teammate in another timezone posted a question at 3 a.m. your time. You don’t need to feel guilty about not answering until your morning—they know. That’s the deal with distributed teams: you send a message when it’s convenient for you, and the other person responds when it’s convenient for them.

This also means writing messages that don’t require an immediate back‑and‑forth to be useful. Instead of “Can I ask you something about deployments?”, write the full question with all the context so they can answer it in one shot, even if it’s six hours later. Think of it less like a conversation and more like a really short, well‑structured email.

Tips for good async communication

1. Front‑load context.
2. Include relevant links.
3. Make the message self‑contained.

It’s a skill worth developing, and your globally distributed colleagues will quietly love you for it.

How to Ask for Help (Without Making People Do Your Homework)

There’s an art to asking good questions, and it applies just as much in Slack as it does on Stack Overflow. A well‑structured help request looks something like this:

What I’m trying to do:
Set up the local dev environment for the payments service.

What’s happening:
The Docker build fails at step 7/12 with a permissions error on /var/run/secrets.

What I’ve tried:

• Running with --privileged
• Clearing the Docker cache
• Checking the README (last updated 8 months ago)

My question:
Is there an additional setup step for the secrets volume that isn’t documented, or is this a known issue with the latest Docker version?

Compare that to “The payments service doesn’t work, help?” One of those gets a useful answer in minutes; the other starts a 20‑message interrogation just to figure out what’s actually going on.

Bonus: The Worst Slack Crimes

A non‑exhaustive list of things that will make your teammates sigh deeply:

• Sending voice messages in group channels. Nobody wants to put in earbuds to hear your two‑sentence question that could have been typed in 15 seconds.
• Editing a message after someone already replied to it. The reply now makes no sense and everyone looks confused. If you need to correct something, add a follow‑up instead.
• Replying to a thread and checking “also send to channel.” Pick one. That checkbox exists for rare occasions, not as a default.
• Using @channel in #random. No.
• Deleting messages in an active conversation. The replies are still there, floating in the void, referencing a ghost message.
• Marking everything as urgent. If everything is urgent, nothing is urgent. You’re the Slack equivalent of the boy who cried wolf.

It All Comes Down to Empathy

Most of these “rules” boil down to a single idea: think about the person on the receiving end of your message before you hit Send.

• Is this clear?
• Is this interruptive?
• Will they have what they need to help me?
• Am I making their day slightly easier or slightly harder?

Good Slack etiquette isn’t about being formal or walking on eggshells. It’s about being considerate in a medium where tone is invisible and everyone’s already drowning in notifications.