Skip to content

Instantly share code, notes, and snippets.

@andrewxhill
Last active November 19, 2020 12:40
Show Gist options
  • Save andrewxhill/fed2ab60d0a8b68f30f9884c057ef461 to your computer and use it in GitHub Desktop.
Save andrewxhill/fed2ab60d0a8b68f30f9884c057ef461 to your computer and use it in GitHub Desktop.

On chatting to people

Chat is not the same as conversation. When you tag someone using the "@" or if you send them a direct message, you may be directly forcing them to change their focus to your problem. While this is good for you, it can be bad for a healthy and productive community. Here are a couple of rules to abide.

  • Only "@" tag people's names in the following cases.
    • Your comment is urgent/time-sensitive and you need the help of the "@" target. What is urgent? You are running a production application with 100s of users facing a broken API, it's urgent. You are experimenting or taking part in a competition and want an answer quickly, it's not urgent.
    • Your comment has grown stale and you still need an answer that the "@" target can provide. What is stale? In most cases, more than 2 days seems reasonable or if it's a weekend, 3 or more.
    • You comment is in a channel or thread where the "@" target is not present but you need them aware.
  • Abide by the "no hello" rule at all times. Provide the topic of your conversation immediately. This means, never start a DM or tag a person with the "@" symbol with a simple "hello", "good morning" or another nicety. While this is polite, it can cause a lot of inefficiency in group chat.
    • Example bad message: "Good morning @andrewxhill! Hope you are doing well".
    • Example good message: "Good morning @andrewxhill! Could you help me with this error message I see in the Powergate. Error(not enough coffee).
    • Read more about the "no hello" rule here: https://www.nohello.com/

On asking technical questions

Asking questions is an art. When asking questions on an asynchronous chat platform, these pointers can help you get answers a lot faster (while keeping those responding excited to help).

  • Most questions about an issue should be asked like a good ticket on GitHub. If you aren't familiar with what a good ticket contains, here's a summary
    • A brief description of the problem
    • The steps that led you to the problem
    • The steps you've tried to solve the problem
    • Any links to code with the problem or links to the process you followed.

Asking all of that in the first comment of your chat will make you a star in the channel.

What if your question is not technical? You are in luck! More information to help the responder(s) figure out what you are asking is always appreciated.

On creating threads

Threads are a welcome feature in Slack. They can help you reduce the noise in channels, group interested parties, and reach a conclusion. Here are some pointers on using Threads

  • Create threads as much as you can.
  • Only include the minimum number of people required in a thread. Threads trap participants.
  • Make sure your threads are short lived. Long-lived threads trap participants, hide solutions, and more. Reference an old thread, but don't get stuck in it.
  • Make sure your threads have a specific topic. Using the same thread to address many topics can bury answers, trap members, and become a nuisance.

Only DM if it is private or there is only one person in the world that can answer the question. Shared channels help create shared knowledge. Determine the right channel for your question

Bonus: Comic

A lot of the above is designed to ensure you don't interrupt other people who are responsible for a lot of other work. There are a lot of great reasons why this is important. Here's one of my favorites (think about what happens when you message someone and it becomes a notification on their computer): https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment