“Insufficient detail. Please ask a specific question.”
This is a very real problem from the answering side. So many people would rather have you guess what they’re trying to ask and then get mad at you when you guess wrong.
I know whenever I try to help someone with a Linux issue it’s always an uphill battle to get them to stop guessing what they think the problem might be and show me the logs.
People really don’t want to give you the information you need to help them.
I make sure to give my guess and also append as many logs and exact information as possible, right down to every step I took that produced the problem.
So far my success rate with the forums is 0%. But hey, people at least tried to be helpful!
It’s not a real problem on Stack Overflow. Because Stack Overflow isn’t just a forum, it’s supposed to be a repository for reference. Let’s examine a hypothetical:
Newbie programmer Tim submits a question on Stack Overflow. “How do I deserialise a JSON in C?” An answerer replies “that doesn’t make any sense. What are you actually trying to do?” Tim explains that he’s trying to make two parts of his program communicate, and he heard some out of context advice that a JSON is a good way to do it. The answerer helps Tim out by explaining a better solution to the problem.
A year later, professional programmer Mark googles “how to deserialise a JSON in C”. Mark’s client wants to pass JSON data from a web application into a C program they bought, and they don’t care whether it’s good practice. Mark understands this situation isn’t good practice, and he suggested a better tool, but the client doesn’t care because they spent a lot of money on this licence and using a different tool would make them look like fools. Mark isn’t happy, but he’s going to try his best.
Mark finds the stack overflow thread created by Tim, and it’s completely useless. Nobody actually answered the question that Tim asked. Tim is happy because Tim’s individual problem was solved. But Stack Overflow isn’t any help to Mark, or the hundred people like him who were also put in an unreasonable situation by their bosses and clients. By helping Tim, the answerer frustrated everyone else.
This is a very real problem from the answering side. So many people would rather have you guess what they’re trying to ask and then get mad at you when you guess wrong.
I know whenever I try to help someone with a Linux issue it’s always an uphill battle to get them to stop guessing what they think the problem might be and show me the logs.
People really don’t want to give you the information you need to help them.
To be fair, people who know which logs to attach and how to get them usually already know enough to troubleshoot the issue by themselves.
This is such a hard part of learning Linux. “Just look at the logs” Which logs? Where? How?
journalctl > logs.txt(don’t actually do this)(what does this do?)
deleted by creator
You’d think so, but the logs often contain a ton of noise along with the one line that tells me what the actual issue is.
I make sure to give my guess and also append as many logs and exact information as possible, right down to every step I took that produced the problem.
So far my success rate with the forums is 0%. But hey, people at least tried to be helpful!
Yep. I do triage on potentially bad questions and this is probably the most common response I give.
It’s not a real problem on Stack Overflow. Because Stack Overflow isn’t just a forum, it’s supposed to be a repository for reference. Let’s examine a hypothetical:
Newbie programmer Tim submits a question on Stack Overflow. “How do I deserialise a JSON in C?” An answerer replies “that doesn’t make any sense. What are you actually trying to do?” Tim explains that he’s trying to make two parts of his program communicate, and he heard some out of context advice that a JSON is a good way to do it. The answerer helps Tim out by explaining a better solution to the problem.
A year later, professional programmer Mark googles “how to deserialise a JSON in C”. Mark’s client wants to pass JSON data from a web application into a C program they bought, and they don’t care whether it’s good practice. Mark understands this situation isn’t good practice, and he suggested a better tool, but the client doesn’t care because they spent a lot of money on this licence and using a different tool would make them look like fools. Mark isn’t happy, but he’s going to try his best.
Mark finds the stack overflow thread created by Tim, and it’s completely useless. Nobody actually answered the question that Tim asked. Tim is happy because Tim’s individual problem was solved. But Stack Overflow isn’t any help to Mark, or the hundred people like him who were also put in an unreasonable situation by their bosses and clients. By helping Tim, the answerer frustrated everyone else.