It's a hard problem, and one I waver back and forth on.

I personally learn best by example. Two or three well-chosen examples will show me an approach or strategy far more rapidly than the most well-written explanation. So I think it's a good thing to provide example code, since I usually can't solve a problem without typing up an example or two anyway. Frankly, the practice I get doing that is part of what makes PerlMonks valuable to me.

On the other hand, giving someone a drop-in solution encourages copying and pasting without comprehending. I don't care if someone copies and pastes my example code, but they should understand it.

So I try to use toy code. I distill the code snippet down to the simplest example that still shows how to solve the problem. Toy code should run anywhere and not depend on things like databases. It's simpler to understand than an actual rewrite of the original code, and the poster must reapply the knowledge in my reply to their original code, so I don't need to worry about encouraging bad copy-and-paste habits.

The exceptions are:

1. Folks that already know how to solve the problem, and are asking about style improvement. I'll happily rewrite their code to do the exact same thing.
2. People who do not post any code at all and do not indicate the (possibly substantial) work they've already put into the problem.

Getting newcomers to read the basic documentation is also a puzzle. I don't like flaming people at all; in fact, I hate it. I don't even like downvoting nodes. However, I think that reading the docs is more enlightening than the most spot-on post, because of the things you'll learn while reading them. I will do whatever I can to encourage reading the docs and O'Reillys, using whatever carrots and sticks I can apply.

stephen