[Tutor] Help

[Jerry Hill]

On Fri, Sep 21, 2012 at 10:33 AM, Prasad, Ramit
<ramit.prasad at jpmorgan.com> wrote:
> Ironically, that describes me. So what is the preference for large
> code samples? Just always include it? What about for the main list?

It's tricky.

Ideally, you need to take your large code base, and reduce it into a
short piece of sample code that is runnable and reproduces your issue.
 Yes, this can be hard to do, and yes, it can take a lot of time. It
should be as short as possible, trimming out all of the extraneous
functions and calls.  It needs to be short enough that someone
interested can actually read it and understand what you're trying to
accomplish.  It needs to be long enough to actually demonstrate the
problem you're having.

It's worth the trouble though -- anything longer than a page or two of
code is going to get glossed over by many readers -- they just don't
have time to read and understand your code, see where you're having a
problem and diagnose the issue for you.  You're much more likely to
get help with a 10 or 20 line sample than with a 100 or 200 line one,
much less something that's thousands of lines of code.

The people here are volunteers -- the best way to engage them in your
problem is to be respectful of their time.  Often, that means spending
extra time of your own to save their time.

In many cases, the act of trimming your code down to that form will
actually cause you to find the answer to your own question without
even needing to send it.  This process is sometimes known as "rubber
ducking" -- http://www.codinghorror.com/blog/2012/03/rubber-duck-problem-solving.html

I can't count the number of times that I've had a problem, decided to
send it to a mailing list for help, and in the process of fully
describing the problem I'm having, come up with the solution without
even having to send the email.

-- 
Jerry