Most of the questions asked seem of much lower quality than those that used to appear under the code golf tag on StackOverflow. Here, I see these problems repeatedly:

  1. Poor problem definition, often lacking any clarity on what to do
  2. Problems far too small to have any meaningful room for golfing
  3. Very lax input/output requirements, sometimes to the point of absurdity
  4. Presupposing a very narrow set of languages

In short, I'm not finding the problems here nearly as interesting as the ones we used to have on SO.

So... What can we do about this? How can we get the quality up?

  • \$\begingroup\$ Can you give some examples for 4.? stdin/stdout is probably not that narrow. \$\endgroup\$
    – Joey
    Commented Feb 21, 2011 at 10:47
  • 3
    \$\begingroup\$ I propose kidnapping LiraNuna. \$\endgroup\$
    – ninjalj
    Commented Feb 24, 2011 at 22:52
  • \$\begingroup\$ And for the answers, we kidnap Donald Knuth. \$\endgroup\$ Commented Apr 29, 2011 at 1:50
  • \$\begingroup\$ Looking back at this, I can see that Puzzling.SE had precedent for its initial shakiness. \$\endgroup\$
    – Joe Z.
    Commented Apr 6, 2015 at 19:45

4 Answers 4


The way we maintained high quality on Stack Overflow was by mercilessly bullying posters to fix the deficiencies, endlessly linking them to the meta questions (and later the tag wiki), and closing the ones that weren't fixed or were unrecoverable.

In other words, we have to quit cutting those posters any slack, and we have to be prepared to be called names.

But before that can happen we need some kind of consensus about what makes a question "good".

I would submit that the rules we used on Stack Overflow are a good place to start.

  • \$\begingroup\$ We had rules on SO? \$\endgroup\$
    – J B
    Commented Feb 22, 2011 at 20:39
  • \$\begingroup\$ @J B: The "meta questions" link. And the tag wiki which was more or less taken from it. \$\endgroup\$ Commented Feb 22, 2011 at 20:43

I think the biggest problem is when the asker links to external sites without adequately describing the problem on the page. I'll pick on Hamming numbers. It doesn't even say what the Hamming numbers are, it just links to an article where I have to dig to find them. It could at least list a few of them. A worse offender is Morse code translator, which could, in a matter of seconds, be edited to display the open-licensed Morse Code table.

Askers, please post what you are asking directly on the page! Don't make me go to some website to find out what you're talking about. I don't mind going to another page to get the finer details, but a Code Golf question should function as an advertisement of the problem and how interesting it is.

  • 2
    \$\begingroup\$ The morse code one is a svg. Blame SE for not letting us upload svg as images \$\endgroup\$
    – gnibbler
    Commented Feb 20, 2011 at 21:23
  • \$\begingroup\$ On the other hand, nothing's stopping you from converting it manually: wget -O - http://upload.wikimedia.org/wikipedia/commons/b/b5/International_Morse_Code.svg | convert - International_Morse_Code.png (unfortunately, the title gets clipped). SVG isn't quite as well-supported in browsers as other formats, but it'd be nice if SE could do the conversion automatically. \$\endgroup\$
    – Joey Adams
    Commented Feb 20, 2011 at 22:33
  • \$\begingroup\$ I approved your edit on the morse code question ;) \$\endgroup\$
    – gnibbler
    Commented Feb 21, 2011 at 20:54
  • \$\begingroup\$ @gnibbler: Did you open a thread on meta about svg? \$\endgroup\$ Commented May 2, 2011 at 4:27

Problem definition: I feel most of the problems on SO were not as rushed in as they are here. The beta status tends to push us in a "we need questions asked or else" mood that's detrimental to quality.

Problem size: There are some long and complex problems out there (check the "unanswered" page), but they're definitely not low-hanging fruits. Less traffic, less votes, less visibility. And beware the other edge of the sword: some of the most complex ones I'd never answer myself, they've been dismissed as too boring long ago. Partial personal list: Self-compiling compiler (TCC's already out there), Write a compressing util for gzip files., Implement PCRE in your language. FWIW, I also tend to dismiss problems where I feel there's no right way to rank out the answers, and would end up in a language popularity contest. (and this already happens quite a bit in actual well-phrased problems)

Lax requirements: I'm guilty of this myself, as a reaction to the over-strict problems where the requirements subconsciously favor a single perspective in programming languages. This could be addressed with a few templates for "classical" problem categories, where we'd agree what the normal way of processing I/O is, what tolerances are usually allowed to specific languages. As templates, they'd be overridable per problem.
As far as I'm concerned, a major part of the fun of golfing is bending the requirements as far as possible in the small code size direction. I love seing a solution output unexpected mixed-case or random spacing as a side effect of shorter code. I smile at solutions that work 90% of the time because they run their luck on the number of set bits in their PID. Most of this, and the fun that goes with it, tends to be rubbed away with too strict requirements.

I'm not sure I see what you mean about presupposed languages.

  • \$\begingroup\$ I kinda like having the big, hard challenges sitting there, but of course I haven't been willing to start on any of them. You're almost certainly right about the beta encouraging ill-stated or ill-thought-out questions. \$\endgroup\$ Commented Feb 22, 2011 at 20:48

Here is what I think:
To answer #1, I think that everyone should describe what they want to do, and then people will edit it to make it shorter and more concise. You should also try to make it less technical, so those who don't fully understand the meaning can help. I've seen problems where it sounds really complex, but when rephrased it was actually much simpler.

#2 and #3 are actually very simple to fix - either let the poster know how they could fix their question, or call a close-vote. I would prefer to avoid close-voting, but there are times when it's necessary. But don't jump straight to a vote. See if you can help the poster before that - sometimes it can be a good question if written properly.

For #4, you should suggest some languages, and see why they would only choose those languages or omit others. Were the languages too simple? What if they only run/understand/need the one or two?

Most of all, be nice, they might be new. Most of these problems are caused by new people, but they're just trying to figure out how the site works. (I speak from experience on this one, my first question was edited within 5 minutes.) Try explaining how they could fix it, and let them know how things work (and why what they did was wrong).

  • \$\begingroup\$ I approve of your last paragraph, as my first question was closed within five minutes. It does take a while to figure out how things work here. \$\endgroup\$
    – Gryphon
    Commented Jun 22, 2017 at 10:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .