Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Meta

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.

Comments on Suggested special feature: Clinic/case study

Post

Suggested special feature: Clinic/case study

+1
−4

We have special features/sections on Codidact, so maybe this is a nice use for them.

What if we had a section named something like "clinic" or "case study" or "debugging"? (name suggestions welcome)

The point of this section would be specific debugging or troubleshooting help questions. The format would still be QA, but the culture would be different. This section will be specifically for questions like "why is this code breaking" or "how do I fix this method returning wrong value".

A lot of people complain about such questions, because they are too localized/specific. In other words, they help just OP and maybe two other people in the world who have that exact problem, and nobody else cares. I personally disagree, because a normal intelligent person can look at the solution of a problem that's not exactly the same as theirs, and still glean enough useful insight to solve their own. I do see the other concern about them not being searchable, and I haven't made up my mind on whether I buy it. But such questions are controversial, so maybe it would help to give them a separate place.

On this new debugging section:

  • Any type of debugging question is welcome, no matter how localized or specific
  • Askers are encouraged to provide all necessary data, ideally MWEs, and no more (redundant data should be deleted)
  • Askers are gently guided with edit requests and comments, not downvotes without an explanation of what's wrong
    • It's very annoying, when you are trying to solve a tough problem, got frustrated, gave up, and are asking for help, then someone downvotes you with no explanation, or yells at you for not doing a bunch more frustrating reading when you're already sick of going in circles through incomprehensible manuals. It feels like "screw you, you're not worth helping, no real reason just cause".
  • "Teaching to fish" is strongly encouraged in answers. So explaining how to solve the problem, rather than just giving the solution. Giving the solution is okay, especially if it helps illustrate the solution method (it's also annoying to solve riddles when you're frustrated and just want some help), but the focus must be on the how not what.
    • Linking to relevant general questions of the Q&A section, or even creating them there, is encouraged. This is a good soft way of recruiting hapless newbie "help vampires" into becoming good users of the main section. They come for the debugging, calm down and feel gratitude when their problem is solved, and stay for the community and quality SWdev discussion.
    • I would go as far as saying you should not upvote answers (but don't downvote unless they're blatantly incorrect) that only give the solution, without explaining how they arrived at it. I consider these "closed-source" answers.
  • Paraphrasing relevant data is allowed.
    • Adding this based on personal experience with Arch forums, which ban paraphrasing and demand excessive logs. This creates a lot of privacy concerns, logs often contain private data that is a lot of work to scrub, they take space, and there's no point demanding them in full if an accurate summary can be provided. Arch forums assume their users are idiots and cannot provide an accurate summary, but we shouldn't.

In principle, the code review section can be used for this. Usually I think of it as "this code works and is as good as I can make it, but is there any improvement areas that I have missed?". But if you paste broken code, obviously a review must explain how to fix it. However, I think it would muddle things too much to reuse code review for debugging, especially if you consider my suggested policy above. Also, currently the code review section requires working code only. As I understand, creating sections is not hard, so why not just make a separate one and be safe?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

4 comment threads

Previous discussion (1 comment)
Already on-topic (4 comments)
Ref. to "too localized/specific" (4 comments)
"the code review section can be used for this." (1 comment)
Ref. to "too localized/specific"
Alexei‭ wrote about 1 year ago

Ref. to "A lot of people complain about such questions, because they are too localized/specific.": Can you clarify if this point from your post refers to SO or to Codidact? I think that this used to be a close reason for SO.

I have rechecked the help section and this type of question is allowed on Codidact. The only offtopic point that is loosely related would be "Simple typos", but this is clearly something different than a general debugging question.

matthewsnyder‭ wrote about 1 year ago

Like many here, most of my experience with QA sites indeed comes from SO.

I know it is not against the rules here per se. However, I have often observed people in meta discussions to suggest various types of "overly localized" questions are undesirable. There does not seem to be much gained by providing a comprehensive inventory of where they've done this.

In this "debugging" section, I would specifically allow questions where the problem is a simple typo.

Alexei‭ wrote about 1 year ago

Indeed, such questions are not exactly welcomed as one of the close reasons states:

not constructive This question cannot be answered in a way that is helpful to anyone. It's not possible to learn something from possible answers, except for the solution for the specific problem of the asker.

I think that this close reason should be improved since it is a little bit contradictory ("in a way that is helpful to anyone" and "the solution for the specific problem of the asker") -> I will raise this issue on Meta.

I am not sure about encouraging simple typo questions though. These questions typically have the following life cycle:

  • are asked
  • receive a hint/answer in the comments -> the asker has a solution
  • are closed as being not constructive (not removed) -> no reason to allow (additional) answers

I see nothing wrong here.

matthewsnyder‭ wrote about 1 year ago

True. But remember I am proposing that instead of answers like "you have a typo in line 4", we should favor answers like "here is how you can find that a typo caused your bug...".

Anyway, why the preoccupation with typos? There is a lot more to debugging than finding typos.