I wish more people used threads on platforms like Slack and Discord. And I think the reason to use threads is very similar to the reason why one should aim for modularity when writing software.
Here’s an example. I posted this question in the #haskell-beginners Discord channel asking whether it’s advisable for someone learning Haskell to use a linter. I got one reply, but it wasn’t as a thread. It was a normal message in #haskell-beginners. Between the time I asked the question and got a response, there were probably a couple dozen other messages. So then, I had to read and scroll through those to get to the response I was interested in, and to see if there were any other responses.
Each of the messages were part of a different conversation. I think of it as something like this:
There is a linear structure for something that more naturally structured as a tree.
Function Programming Discord server
#haskell-beginners channel
Conversation A
Message 1
Message 2
Message 3
Message 4
Conversation B
Message 1
Message 2
Conversation C
Message 1
Message 2
In writing software, imagine that you have three sub-problems that you need to solve. And imagine if you approached this by doing something like this:
// stuff for sub-problem #1
// stuff for sub-problem #1
// stuff for sub-problem #2
// stuff for sub-problem #3
// stuff for sub-problem #1
// stuff for sub-problem #3
// stuff for sub-problem #1
// stuff for sub-problem #2
We generally prefer to avoid writing code this way. Instead, we prefer to take a more modular approach and do something like this:
solveSubProblemOne();
solveSubProblemTwo();
solveSubProblemThree();
function solveSubProblemOne() {
...
}
function solveSubProblemTwo() {
...
}
function solveSubProblemThree() {
...
}
By writing the code in a modular fashion, you can easily focus on the code related to sub-problem #1 and not have to sift through code that is unrelated to sub-problem #1. On the other hand, the more imperative non-modular version makes it difficult to tell what code is related to what sub-problem.
Similarly, using threads on platforms like Slack and Discord make it easy to see what messages belong to what conversations.
And like software, the importance of this gets larger as the “codebase” becomes more involved and complex. Imagine a Slack channel with lots and lots of conversations happening simultaneously without threads. That is difficult to manage. But if it’s a small channel with only two or three conversations happening simultaneously, that is more manageable.
Threads are pretty good, most help channels should probably be a forum (or 1 forum + 1 channel). Discord threads do have a significant drawback of lowering visibility by a lot, and people don’t like to write things that nobody ever sees.
Discord threads do have a significant drawback of lowering visibility by a lot, and people don’t like to write things that nobody ever sees.
Meh. If you start a thread under the message “Parent level message” in #the-channel the UI will indicate that there are “N Messages” in a thread belonging to “Parent level message”. It’s true that those messages aren’t automatically visible to people scrolling through the main channel, they’d have to click to open the thread, but if your audience isn’t motivated to do that it seems to me like they aren’t worth interacting with in the first place.
I do prefer how Slack treats threads though. They’re more light and convenient to use in Slack.
I wish more people used threads on platforms like Slack and Discord. And I think the reason to use threads is very similar to the reason why one should aim for modularity when writing software.
Here’s an example. I posted this question in the
#haskell-beginners
Discord channel asking whether it’s advisable for someone learning Haskell to use a linter. I got one reply, but it wasn’t as a thread. It was a normal message in#haskell-beginners
. Between the time I asked the question and got a response, there were probably a couple dozen other messages. So then, I had to read and scroll through those to get to the response I was interested in, and to see if there were any other responses.Each of the messages were part of a different conversation. I think of it as something like this:
There is a linear structure for something that more naturally structured as a tree.
In writing software, imagine that you have three sub-problems that you need to solve. And imagine if you approached this by doing something like this:
We generally prefer to avoid writing code this way. Instead, we prefer to take a more modular approach and do something like this:
By writing the code in a modular fashion, you can easily focus on the code related to sub-problem #1 and not have to sift through code that is unrelated to sub-problem #1. On the other hand, the more imperative non-modular version makes it difficult to tell what code is related to what sub-problem.
Similarly, using threads on platforms like Slack and Discord make it easy to see what messages belong to what conversations.
And like software, the importance of this gets larger as the “codebase” becomes more involved and complex. Imagine a Slack channel with lots and lots of conversations happening simultaneously without threads. That is difficult to manage. But if it’s a small channel with only two or three conversations happening simultaneously, that is more manageable.
Threads are pretty good, most help channels should probably be a forum (or 1 forum + 1 channel). Discord threads do have a significant drawback of lowering visibility by a lot, and people don’t like to write things that nobody ever sees.
^ Forum
Meh. If you start a thread under the message “Parent level message” in
#the-channel
the UI will indicate that there are “N Messages” in a thread belonging to “Parent level message”. It’s true that those messages aren’t automatically visible to people scrolling through the main channel, they’d have to click to open the thread, but if your audience isn’t motivated to do that it seems to me like they aren’t worth interacting with in the first place.I do prefer how Slack treats threads though. They’re more light and convenient to use in Slack.