Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Are code troubleshooting posts allowed?
I assume "help my code isn't working"/troubleshooting posts - which make up much of SO questions - are allowed. However from reading the FAQ, it's not obvious to me that they are. The "on topic" bullet point that most closely approaches this is "questions about database design, programming, or access through SQL (SQL programming)", but it's not clear to me that "questions about programming" includes "troubleshooting code".
If it is allowed then maybe it should have its own bullet point (near the top) as presumably that's how you will get more participation. If not then it should be added to the "off topic" section.
4 answers
These questions are very helpful to the person asking, and great for driving activity. I think it is good to allow these questions to be asked and to answer them.
At the same time, they are not good for keeping on the site indefinitely. Many years ago, I did not understand what lambdas were and asked a bunch of very specific questions about why this and why that and wherefore syntax error in this piece of spagetti code. This was back in the good old days and people on SO actually helped me understand it. But does it matter now? Would anyone read the question? Another person with the same problem would have trivially different code. But if they are a novice, they would not be able to see past the trivial differences.
Moreover, the real value in troubleshooting is not solving the immediate issue, unless that exact issue is extremely common. The real value is a hands on lesson in learning how to fish.
It would be great if we could find a way to do that. For example, in my lambda example, perhaps the solution would be to close the specific question, and create a new one saying "how to troubleshoot syntax errors [involving lambdas?]"?
I think the Latex community at SE started a great tradition of asking for MWEs. I believe the R community later started adopting this as well. But not every problem can be easily turned into an MWE. However, every troubleshooting/debug problem should reduce to a generic problem solving case study.
So we need a way to handle these questions, but unlike others, simply answering a troubleshooting question does not actually grow the knowledge base of the site. Extracting generalized take-home lessons from the troubleshooting grows it. So the specific problem is not the issue, it's how to approach that type of problem. We need to somehow convert the troubleshooting questions into that type of generalism.
Perhaps some kind of chat function would work for this? We could encourage users to ask for debugging help in chat, and from there point them to or encourage making questions like "how do I troubleshoot errors of X class in Y context?"
1 comment thread
Yes
Questions about troubleshooting your non-working code are on-topic, provided that you include enough information for the community to understand the context (SO names this minimal reproducible example) and at least one attempt / debugging information.
I have also updated the What type of questions can I ask here? section to explicitly allow such questions.
As a side note, it might be a good idea to randomly browse existing questions, answers and comments, before asking your first question. This might provide great insight into how a good question looks like.
Also, good comments ask for clarifications that help you understand the key aspects to include so that the question is clear and answerable.
tl;dr: Allowing beginner-level "help me diagnose this" questions will generate large volumes of duplicates if the site ever scales. We need to think about how to structure things if we want them.
I have certain reservation about this.
I've said before that I don't think question-and-answer is a good format for the kinds of questions that beginners ask when they're just starting out. My reasons are twofold: firstly the format is less than ideal for providing the best help, but more pressingly the questions that result are of limited value and tend to generate many, many duplicates.
I'd like to address this by starting with an observation and getting back to my points in a bit.
Of course beginners have a lot of questions, and more than that if we compared notes we find that we shared many misunderstandings and failures to appreciate the implication of what we'd been told. Certainly we didn't all have the same set, but I'm sure that every pairing of two experienced programmers would generate a set of common "you wouldn't believe the stuff I didn't get at first" stories. These things are ubiquitous.
So it might seem that the world would be well served by a bank of these questions carefully answered to serve as a resource for the up-and-coming generation of beginners, right?
But the core problems are searchability and askers recognizing that existing question match their own. If you've ever mentored beginners you know that generally when a newbie comes to you with a perplexing issue the first thing you have to do is decode the way they present the problem. Because beginner share a set of misconceptions but they don't share a common mindset, focus of attention, and vocabulary to discuss either what they have done or what they expect.
This has two implications:
-
That having a relationship between the learner and teacher makes the translation more reliable and lets the teacher steer the students ways of talking about their programs and problems into a consistent and conventional groove slowly than a Q&A framework where the asker may be dealing with a different set of answerers on each followup question.
-
There are dozens or hundreds of ways in which they ask the "same" questions and don't accept that existing questions answer their query. Those of you who participated in the early days of Some Otherplace will recall the endless duplicate wars which resulted. The issue of experienced users answering duplicates because it was easier than finding an earlier instance was never resolved (which proves that the searchability issue is non-trivial).
If we are going to have beginner-level "help me out with this code" questions (something I have the feeling that many people are in favor of), we need to think about what they will look like on the site in the event that it scales up. For instance, do we want a separate category for diagnose and fix this code questions similar to the separate category for code review questions?
You are right, the on-topic page is confusing - trouble-shooting and general programming questions should obviously be on-topic!
Perhaps we considered it so obvious that it fell between the lines on What type of questions can I ask here? That on-topic page is still kind of in the draft stages.
We first had a very early draft, for which there was no consensus but lots of discussion: https://software.codidact.com/posts/277235
The first bullet in that initial draft said:
- Specific programming problems, where the poster includes their own attempts to solve or debug the problem.
Basically the very same deal as SO.
One of our moderators then gathered all what was said in that discussion and re-wrote it. Their original text is found in the question of this post:
Community feedback: What type of questions can I ask here? (still active, everyone is welcome to contribute & vote)
Now this had become
- questions related to software design/review...
As per community consensus here https://software.codidact.com/posts/278786#answer-278786, that text was then changed again to:
- questions about software design, architecture, or modeling
(modeling -> modelling btw)
This does however in retrospect sound like the site is all about big picture design issues, which was never the intention. Perhaps my original bullet, or some version of it, should get re-added to the on-topic list?
1 comment thread