How to torment Samaritans

[Roedy Green]

Karl Rove of the Republican party asked me to write an essay on how to
torment Samaritans. I felt unqualified to write on the topic
generally, but I offered to write on the more limited topic of
comp.lang.* Samaritans who volunteer their time to help others with
computer problems:

1. be as vague as possible about your problem. Volunteer no relevant
details. Never mention your platform or any special libraries you are
using.

2. Use Marilyn Monroe baby-talk to describe symptoms. E.g. "broken"
"din't work". You don't want people guessing if you have a compile
time error, run time exception, or simply unexpected behaviour.

3. never post code. Claim national security if pressed.

4. When asking help with a compiler error or exception, paraphrase it.
Never quote the line in question or the code context.

5. When asked to perform an experiment to help narrow down the
problem. Don't do it. Pretend you did not hear the request.

6. Start off posts with "You have to help me." and "You have only10
hours to solve this for me.". Every hour add a followon post berating
people for not solving this yet to your satisfaction.

7. Post your old homework assignments verbatim under 5 assumed names.

8. even when tempted by a desperate need for a quick solution, never
succumb to writing an SSCCE. See http://mindprod.com/jgloss/sscce.html

9. When offered a solution or explanation of why what you want to do
is unwise or impossible, no matter how appropriate, say, "that's just
not good enough", but don't elaborate why.

 

[Andrew Thompson]

Roedy Green wrote:

3. never post code. Claim national security if pressed.

LOL! I've had a few like that recently. That
was my favorite, but 7. and 9. also deserve
'honorable mention'.

However you also forgot ..
10. Don't even consider reading the group, either for
answers to your question, or for tips on how to best get
answers (that would cut into the time you spend 'berating' -
see 6.).

 

[Andrea Desole]

1. be as vague as possible about your problem. Volunteer no relevant
details. Never mention your platform or any special libraries you are
using.

2. Use Marilyn Monroe baby-talk to describe symptoms. E.g. "broken"
"din't work". You don't want people guessing if you have a compile
time error, run time exception, or simply unexpected behaviour.

3. never post code. Claim national security if pressed.

4. When asking help with a compiler error or exception, paraphrase it.
Never quote the line in question or the code context.

5. When asked to perform an experiment to help narrow down the
problem. Don't do it. Pretend you did not hear the request.

6. Start off posts with "You have to help me." and "You have only10
hours to solve this for me.". Every hour add a followon post berating
people for not solving this yet to your satisfaction.

7. Post your old homework assignments verbatim under 5 assumed names.

8. even when tempted by a desperate need for a quick solution, never
succumb to writing an SSCCE. See http://mindprod.com/jgloss/sscce.html

9. When offered a solution or explanation of why what you want to do
is unwise or impossible, no matter how appropriate, say, "that's just
not good enough", but don't elaborate why.

I'm sorry, but I have to add this.

How to be tormented:

answer the posts that follow one of more of the rules above.

I don't mean to be polemic, but these people will always be there, as
well as people who tend to be quite rude, if not offensive.
It can be annoying, but I don't really think you can change it. Just
forget them

 

[ER]

Never the less I have the feeling that you people enjoy every moment of
it...

Just know this: there are some of us out there that appreciate what you are
doing.

Thank you.

 

[Dave Glasser]

Wed, 05 Oct 2005 05:35:16 GMT in comp.lang.java.programmer:

8. even when tempted by a desperate need for a quick solution, never
succumb to writing an SSCCE. See http://mindprod.com/jgloss/sscce.html

For a few years now Andrew Thompson has been relentlessly promoting
the use of the initialism "SSCCE", which stands for "Short,
Self-Contained Compilable Example". But a few minutes with Google
Groups reveals that a.) the term is used very infrequently outside of
comp.lang.java.* groups, and b.) in most instances where it's been
used, it was by Andrew himself, and c.) in most instances where Andrew
or others used it, they felt it necessary to provide a link to a page
explaining what the term means.

In other words, "SSCCE" has failed to enter the programmers' lexicon.
That's too bad, because SSCCEs are very useful things, and having a
commonly-recognized name for them would also be useful.

Why has the use of "SSCCE" not caught on? IMO, the main reason is that
"SSCCE" does not roll off the tongue, like a pronouncable acronym
(e.g. "SOAP") or initialisms with more distinct-sounding letters (e.g.
"XML" or "JDBC"). Try rapidly saying "SSCCE" to yourself three times
in succession and you'll see what I mean. And because "SSCCE" is so
cumbersome to pronounce, it's not easily remembered. And because it's
not easily remembered, it's not "sticky", i.e. it's not commonly used,
or associated in people's minds with the thing to which it refers.

Although I have no specific suggestion for a replacement, I think it
needs to be replaced.


--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net

 

[HalcyonWild]

8. even when tempted by a desperate need for a quick solution, never
succumb to writing an SSCCE. See http://mindprod.com/jgloss/sscce.html

Many a times it is not possible to post the complete code, since it is
required to hide internal logic of a program. I wonder if it is a right
thing to do to reveal the source code of any project being done for a
company. Also , many a times, a small code snippet might not compile.
If it does, it probably does not give out enough information to track
the issue. One should try to post as much information as possible in
the code, while cutting out the irrelevant.

 

[Chris Smith]

Many a times it is not possible to post the complete code, since it is
required to hide internal logic of a program. I wonder if it is a right
thing to do to reveal the source code of any project being done for a
company. Also , many a times, a small code snippet might not compile.
If it does, it probably does not give out enough information to track
the issue. One should try to post as much information as possible in
the code, while cutting out the irrelevant.

I wrote the following some time ago to explain the exact purpose of this
general technique. This was way before Andrew's "SSCCE" acronym
existed, but it conveys the same point.

Incidentally, aside from the attitude (which I don't like), my problem
with the "SSCCE" fad is that it's used as a way to chastise posters for
not helping us. The concept is better understood as a debugging
technique, with recourse to asking others (on newsgroups or elsewhere)
as a last resort. There is no need for the adversarial context, wherein
we assume the role of deciding when the OP has given enough information
that they deserve our help.

Everything that follows is what I wrote several years ago.

----------------------------

Also, a bit of advice that's often heard in comp.lang.java.* is that,
once you've got a simple example that's working and a complex example
that's not, you take the following steps:

1. Make a copy of the more complex example, so you've got one that you
can keep, and one that you can play with.

2. Pick a detail (preferably one that you think shouldn't be relevant to
whether this works or not) that exists in the complex example, but not
in the simple example.

3. Remove it from the complex example, and retest. If the modified
complex example works, go to step 4; else, go back to step 2.

4. Think about why this fixed the problem. Do you understand what the
problem was now? If so, fix it in the original code and you're done.
Else, go to step 5.

5. Replace the change that fixed the problem, so that you've again got a
working and a nonworking version.

6. Avoid any changes that you know will cause the code to start working,
and pick a different and seemingly insignificant difference between the
working and non-working code. If there isn't any other difference you
can pick out, go to step 8.

7. Remove it and retest. If the modified code works, go back to step 4;
else, go back to step 6.

8. Post, to a relevant newsgroup, your current working and non-working
examples. Explain exactly what the differences are between the two
examples. Explain what happens with the working sample (ie, the
expected results) and what happens with the broken sample (ie, the
unexpected results). Post any error messages in their entirety, and if
your error messages contain line numbers, point out what lines those
are. Do it nicely.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Monique Y. Mudama]

["Followup-To:" header set to comp.lang.java.help.] On 2005-10-05,
HalcyonWild penned:

Many a times it is not possible to post the complete code, since it
is required to hide internal logic of a program. I wonder if it is a
right thing to do to reveal the source code of any project being
done for a company. Also , many a times, a small code snippet might
not compile. If it does, it probably does not give out enough
information to track the issue. One should try to post as much
information as possible in the code, while cutting out the
irrelevant.

All of that is fine and dandy. But surely you recognize that an
inability to post concise and compilable code results in a reduced
chance of getting an answer.

People seem to assume that the request for source represents some sort
of hazing, or that it's some arbitrary and mean-spirited way to
withhold information until one performs the appropriate incantations.
It's not that at all. It's just that it's easier to solve a problem
when you can see the code. If you can't or won't provide the code,
that's fine, but it means that you're reducing the likelihood of
getting useful help.

Note that I don't hold with chastising people for not posting their
code. But I'm likely to ignore the post entirely. Chastising could
be interpreted as a better approach, in that at least a person knows
*why* they're not getting any useful feedback.

 

[Oliver Wong]

I'm gonna some pedantic nitpicking here. Don't take it personally. I
agree with what you say, but I don't think it applies in the context of an
SSCCE.

Many a times it is not possible to post the complete code, since it is
required to hide internal logic of a program. I wonder if it is a right
thing to do to reveal the source code of any project being done for a
company.

An SSCCE is not a request for the complete code; quite the opposite,
it's a request for as small an example as possible which still demonstrates
the problem. If you need severals megs of code to demonstrate the problem,
then the problem probably lies in the design of the application, which is at
a higher level than programming in any particular language (e.g. Java). At
that level, you might want to describe the general algorithm and ask for
opinions why it would or would not work, and at that level, seeing actual
source code is less interesting.

Also , many a times, a small code snippet might not compile.

An SSCCE, by definition, is compilable.

If it does, it probably does not give out enough information to track
the issue.

The intent of the SSCCE is to demonstrate the problem.

One should try to post as much information as possible in
the code, while cutting out the irrelevant.

This is the intent of the SSCCE, I think.

- Oliver

 

[Oliver Wong]

3. never post code. Claim national security if pressed.

Alternatively, post code that is different from the code with which you
are working on. After the samaritans have spent hours debugging it and
showing you the line where the problem occurs, tell them that you had
mistyped that line, and that the *real* code already looks exactly like the
fix they proposed, and that the problem still exists elsewhere.

5. When asked to perform an experiment to help narrow down the
problem. Don't do it. Pretend you did not hear the request.

Or pretend to do it, and make up the results based on what you think the
outcome would have been. If "thought experiments" are good enough for
Einstein, they should be good enough for the samaritans of comp.lang.*

- Oliver

 

[HGA03630]

11. Write a non-descriptive simplest subject title. "Help!", "Java
problem" and
"Urgent!" are the best among them.

 

[Andrew Thompson]

Although I have no specific suggestion for a replacement, I think it
needs to be replaced.

Good for you.

 

[Thomas Weidenfeller]

Karl Rove of the Republican party asked me to write an essay on how to
torment Samaritans. I felt unqualified to write on the topic
generally, but I offered to write on the more limited topic of
comp.lang.* Samaritans who volunteer their time to help others with
computer problems:

[...]

You are absolutely right Roedy. I stayed a way from the comp.lang.java.*
groups for some weeks, and started to read them again today. Just after
a few minutes of reading I again started to think that the time is
probably not worth it.

Just in these few minutes I saw two cases were regulars attempting to
help were flamed by incomprehensible first-time posters for "not being
helpful". People demanding answers. People posting their stupid
homework. People who can't read their textbooks, API docs, tutorials,
old postings, new postings, etc. even if their life would depend on it.

Reading clj* seems like a awful waste of time.

/Thomas

 

[HGA03630]

Reading clj* seems like a awful waste of time.
Archive, search on them and the FAQ compiled
by T.W. is always invaluable. Often better than
the Sun Java forum archives because regular
writers quality is much higher.

 

[Monique Y. Mudama]

["Followup-To:" header set to comp.lang.java.help.] On 2005-10-06,
Andrew Thompson penned:

Good for you.

I won't claim that it needs to be replaced, but I will admit that
after several months of reading this NG, I can't remember how many S's
and C's there are in the acronym, but I do suspect that it has
something to do with short and compilable. Or is it concise instead
of short? Then why the S? Hrmm ...

"Post your code" is probably a more effective suggestion.

 

[Thomas G. Marshall]

Andrew Thompson coughed up:

Good for you.

Don't take this personally. I also think that SSCCE is hard to remember,
because the phonemes involved make me sound like I'm lisping.

You will still be regarded as the originator. I might suggest something
like:

CRAP - Compileable, Runable, And Pared down




--
I've seen this a few times--Don't make this mistake:

Dwight: "This thing is wildly available."
Smedly: "Did you mean wildly, or /widely/ ?"
Dwight: "Both!", said while nodding emphatically.

Dwight was exposed to have made a grammatical
error and tries to cover it up by thinking
fast. This is so painfully obvious that he
only succeeds in looking worse.

 

[Tim Tyler]

For a few years now Andrew Thompson has been relentlessly promoting
the use of the initialism "SSCCE", which stands for "Short,
Self-Contained Compilable Example". But a few minutes with Google
Groups reveals that a.) the term is used very infrequently outside of
comp.lang.java.* groups, and b.) in most instances where it's been
used, it was by Andrew himself, and c.) in most instances where Andrew
or others used it, they felt it necessary to provide a link to a page
explaining what the term means.

In other words, "SSCCE" has failed to enter the programmers' lexicon.
That's too bad, because SSCCEs are very useful things, and having a
commonly-recognized name for them would also be useful.

Why has the use of "SSCCE" not caught on? IMO, the main reason is that
"SSCCE" does not roll off the tongue, like a pronouncable acronym
(e.g. "SOAP") or initialisms with more distinct-sounding letters (e.g.
"XML" or "JDBC"). Try rapidly saying "SSCCE" to yourself three times
in succession and you'll see what I mean. And because "SSCCE" is so
cumbersome to pronounce, it's not easily remembered. And because it's
not easily remembered, it's not "sticky", i.e. it's not commonly used,
or associated in people's minds with the thing to which it refers.

Although I have no specific suggestion for a replacement, I think it
needs to be replaced.

You could call them SAS examples.

 

[Andrew Thompson]

...I also think that SSCCE is hard to remember,
because the phonemes involved make me sound like I'm lisping.

You will still be regarded as the originator.

?

Beyond the acronym, there is nothing in the document
to claim originality over. A lot of the tips in the
SSCCE document were 'known to the Phoenicians'.

If it is so strongly associated with me, it is mostly
because I am the one who is promoting it (to the point
of generating animosity from those who have heard
...about it, or ..from me 'too often' already).

..I might suggest something
like:

CRAP - Compileable, Runable, And Pared down

'Don't give us code snippets, give us CRAP'

....hmmm. I can't say it works for me. :-(

 

[Thomas G. Marshall]

Oliver Wong coughed up:

I'm gonna some pedantic nitpicking here. Don't take it personally.
I agree with what you say, but I don't think it applies in the
context of an SSCCE.


An SSCCE is not a request for the complete code; quite the
opposite, it's a request for as small an example as possible which
still demonstrates the problem. If you need severals megs of code to
demonstrate the problem, then the problem probably lies in the design
of the application, which is at a higher level than programming in
any particular language (e.g. Java). At that level, you might want to
describe the general algorithm and ask for opinions why it would or
would not work, and at that level, seeing actual source code is less
interesting.

An SSCCE, by definition, is compilable.


The intent of the SSCCE is to demonstrate the problem.


This is the intent of the SSCCE, I think.

- Oliver

It *is* time to rename this acronym. I can't even read this without
arduously sounding it out in my head. It's just a clumsy set of letters.



--
Puzzle: You are given a deck of cards all face down
except for 10 cards mixed in which are face up.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.

 

[Thomas G. Marshall]

Andrew Thompson coughed up:

?

Beyond the acronym, there is nothing in the document
to claim originality over. A lot of the tips in the
SSCCE document were 'known to the Phoenicians'.

If it is so strongly associated with me, it is mostly
because I am the one who is promoting it (to the point
of generating animosity from those who have heard
..about it, or ..from me 'too often' already).


'Don't give us code snippets, give us CRAP'

...hmmm. I can't say it works for me. :-(

Works well for me: "You have to give a CRAP in order to get help!"



--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.