Should I be asking shorter questions?

Question

Background

I've been meaning to ask this for a while, and this meta question prompted me to finally write something. I've read the answers to that question and the ones to which it links, and the impression I get is that, other than the hard limit of 65K characters, there's nothing wrong with longer questions per se.

At the time of this writing, I have asked seven questions, three of which have received no answers:

• Printing binary trees (~8 KB, ~150 LOC)
• Tracking the bounding box of a map (~6 KB, ~70 LOC)
• Filling a Boot with CIDER (~9 KB, ~90 LOC)

Sanity check

I compared my questions against Simon's Guide for posting a good question:

Is your question on-topic?

The binary tree and bounding box questions both do exactly what they're supposed to do, so they're definitely on-topic. For the workflow question, I went back and forth between posting it on Stack Overflow and Code Review, and I'm still not quite sure where it belongs.

Motivation

The bounding box and workflow questions are both real problems that I've run into and would really appreciate insight on possible better solutions. The binary tree question was just a little project that I thought was kind of cool.

Usage code, example inputs and outputs

I think I had a pretty good number of example inputs and outputs in the binary tree question. I suppose I didn't have so many for the bounding box and workflow questions, though.

Description

Describe the details and your approach

Class/Method summary

I wrote a lot of description of my code and the reasoning behind it in each of these three questions. Probably way too much description, actually.

Don't assume that everyone knows what you are talking about

I'd like to think that I did a good job on this one, but I think someone else would really have to be the judge of that.

Does your code do anything useful or interesting?

The binary tree printer is kind of cool, I guess. I think the bounding box tracker illustrates a more general question of how to extend data structures and handle coordinated (nonconcurrent) change in a functional way. The workflow question is something that I would consider to be essential for programming in Clojure (for me, anyway), but again, someone else would have to be the judge of that.

Screenshots

Doesn't apply; the only question that involves a GUI is the workflow one, and the GUI is not the focus there.

Take your time, don't be lazy

All the specific questions I have about each of these pieces of code are things that I cannot figure out how to solve, not things that I would solve myself but am too lazy to do so.

Possible things you cannot use

Doesn't apply; if there's already a way to solve any of the problems I've posed, I would love to hear about it.

What should I do?

There are a few possibilities I can imagine that would explain the lack of answers:

• My questions are in a relatively unpopular tag
• My questions have too much code
• My questions have too much description
• My questions are uninteresting

I simply don't know which of these are correct, if any. What's particularly interesting to me is the fact that, while the binary tree and workflow questions both have zero upvotes, the bounding box question has five. What's special about that question? Is it the tags? The giant headers that I used to break it up into four sections? The specific problem that I'm trying to solve?

In addition, my four other questions, which are all considerably shorter than these three, have each received at least one answer. To me, that says that the problem with my longer questions is almost certainly the fact that they're, well, long.

Anyway, I'm fairly confused and frustrated with myself about this. What should I be doing differently in my questions in order to receive answers?

Answer 1

Your code is average, maybe a bit on the large size, nothing that I'd not answer.

Your problem is I see a wall with code, text, some lists, more text, more code, more text, more code and then 'how can I improve my code'. I instinctively just go "No." press back and don't think twice about it. Someone else can answer, I'm not going near that.

It's harsh I know.

Honestly I'd much rather your question be a complete code block, it'd simply cause the following 'production line' "copy -> paste -> run -> improve -> test -> answer". But I have to take a lot of effort to just get to run, there's now tons of copy's and pastes. And honestly I've done that 'production line' more than once and it still helps people as you can read their code.

If you want to still write a massive amount of description that's fine, I'll ignore it. But if you do use `fn-name` to highlight your function names, keep your description and code separate and let us lazy ones be lazy.

Currently you have the text:

Finally, since I'm going to be combining sparse strings in addition to just creating and printing them, I'll need a function to shift the reference point of an existing sparse string:

This broke the code block, a no-no. Which could be.

Finally, in shift, since I'm going to be combining sparse strings in addition to just creating and printing them, I'll need a function to shift the reference point of an existing sparse string.

It has the entire context in the text, and won't break the code block! I can then read the code after reading your description, or just your code. And caters to everyone.

Answer 2

I don't think that there is anything wrong with your question length. If anything, I would guess that the fact that your questions are written in Clojure is a bigger factor in explaining why they haven't been answered. If you have asked 6 clojure questions and gotten 3 of them answered, that's not too bad.

Code Review is a community-run website to improve programming skills through peer review. That means that the answers have to come from the community. You have posted 7 questions but only 2 answers. I'm not saying that posting answers to others' questions will lead to your own questions getting answered, but please keep in mind that you are also part of the community that we are trying to build. Every little contribution helps!

Answer 3

There are a couple of subjective reasons which may or may not impact the lack of answers.

You seem to be quite focussed on code-length. Some of the reviewers, including myself, are not interested in such questions. If we take the first question you linked to as an example:

And that's it! Very long, I know. Is there a way to make it shorter? Cleaner? Faster? Better in any way? The one thing I'm most interested in is how to break down some of those longer functions into shorter, simpler ones.

You emphasize on code length and it sounds like you don't really know what else should get priority after that. Shortening functions is good, but shortening functions usually leads to a small amount of overhead which could increase the total length of your code. In my opinion (and many others with me), this potential overhead is worth it. Comparing functions by their Lines of Code is over-hyped and dangerous. Readability and performance are always more important. Conciseness can be a part of readability, but don't overdo it.

Your tags aren't popular. Not much to do about that. clojure has 165 questions, that's not much.

Your third question gives a lot of context (too much, actually) and ends with questions which could be misinterpreted as stand-alone Stack Overflow questions.

Conclusion

Your questions are on-topic, but could use a more structured approach. Tell us what problem the code solves and what your primary concerns with the solution are. Don't overdo the amount of information you give.

Answer 4

It seems like you're looking for a review... a Code Question Review!

I looked over your unanswered questions, and they seem to be very long (as you have noted). Actually, the code is fine, but you just have a lot of words in the question. (Ironically enough, it applies to this very meta question, too.)

Length in itself isn't bad, but it creates a reliance on the structure of the content. When I read your questions, I have a very hard time trying to piece together the parts. People's attention only lasts so long before they give up and move on, so it's important to hook people with your opening.

I think that https://codegolf.stackexchange.com/ has a number of questions with great opening hooks. These questions seem to always follow the same format, so they are very easy to put together and read. Which leads to my next point.

You also don't seem to be organizing your content very well, and you are including a number of irrelevant details. For example, you seem to be writing lengthy summaries of what the code does. I'm not sure if this is necessary to have if your code is well commented. I think that a brief summary of how it works may be more effective.

I think that you are already including all of the things you need for a great post, you just need to assemble them properly.

I suggest that you use a template to help you organize your questions. Maybe something like this:

<What the code does> 
<What language/technology you used>
<Why you wrote it, briefly>
<How it works, briefly>

<How to use the program>
<Sample IO or pictures, if applicable>

<What you want from review>

<Teh codez, ready to copy paste>

Now, I have grouped some lines together because I can imagine them appearing in any order without it mattering too much. It's really more of a guideline, not something that needs to be followed exactly.

Taking this question, I tried my best to model a short example of how you might restructure something to follow the template I made. It's probably somewhat inaccurate (I am using placeholders in several places, too), because I am completely unfamiliar with Clojure, but I hope it will provide you with an idea of how the template would work.

I answered [a question] on SO, and that made me realize how hard printing binary trees is. I decided that I wanted to find a more elegant solution, so I wrote a program in Clojure to do that.

My program takes a "sparse string" and plants the corresponding binary tree. Basically, it recursively generates each subtree, then puts them together so they can be outputted.

Sparse strings follow these rules:

• Each node is separated by spaces, etc, etc, etc.

In order to test my program, I generate the sparse strings with this code: <code>

For example, when <sparse string> is fed to my program, the output is <binary tree>.

I'd really like get some detailed feedback about a few things:

• Is my code elegant?
• Do you think my trees are cool?

Here is my code: <teh codez>

(Side note: code formatting in a block quote is too hard to see on meta.)