NEW: There's a domain for this…
See http://sscce.org/, where someone else has expressed the principle hinted at below at a more formal level.
It's Occam's Razor adapted to the jungle of debugging.
The question "why does my code not work?" is far too often accompanied by either too little or too much information. Neither facilitates good answers. Getting the amount of information right should be easy, but apparently isn't. This little flowchart might help.
Hint: Usually programming errors can be reproduced in no more than one screenful of code, and quite often much less. Exceptions to this are heisenbugs (memory corruptions and threading errors), which are notoriously difficult to reproduce outside their natural habitat. The process of reducing the size of code necessary to reproduce the problem should result in you finding the problem yourself in ~80% of cases - it's a highly educational process.