12.2 Perl People
One of the key qualities of Perl people is how much fun they have with the language. I think this is a synergistic and symbiotic relationship between the language and those people; they create a language that is fun to use, which attracts people who like to have fun and then they put more fun into the language. (Don't think this means that the language isn't suited to serious, important work. Perl people believe that you can get more work done by having fun at the same time. Here's hoping that more managers will catch on to that idea.) Attending a Perl conference is a direct way of finding out what Perl people are like.
12.2.1 How to Ask Questions That Get Answered
Perl people, like any computer experts, thrive on accurate and complete information. (They have to be able to think like a computer works.) They also enjoy helping other people. The best way you can ensure that they answer your question is to make it possible and easy for them to do so. Questions that are vague about what is wanted or don't supply enough information to figure out an answer frustrate the people who are reading them, because they are unable to help. They also see that help as a collaboration between themselves and the questioner; when answering questions for free, they want to promote a "pay it forward" model whereby the questioner becomes empowered to help others himself or herself. That goal is frustrated if the questioner doesn't appear willing to make an equal effort to learn.
Knowing these things about how Perl people think allows us to craft questions that get answered. (Here I am talking only about posting to the various online resources previously listed requesting free help; if you are paying a Perl consultant for help you're entitled to get it under whatever terms you agree upon.) Follow these principles:
Sound coherent. This does not mean that postings by people who are not fluent in the language they are posting in are disparaged; I have seen many postings in halting English that were perfectly clear about their intention. You need to sound like you have enough intelligence to understand the answer, and your words are the only guide readers have for making that evaluation. You must distinguish yourself from the legions of people posting on the Internet who for all intents and purposes sound like infants who have discovered their parents' keyboard. Be clear about what you want. Do you want someone to write a piece of code for you, to tell you what's wrong with something you've written, or to explain a concept to you? Be humble. Or at least appear that way. Show that you understand that anyone helping you is doing it out of generosity; don't give the impression that you believe you're entitled to an answer. Be clear about what happened. If you experienced a problem, report what you did, what the computer's response was, and what you expected it should have been. Don't make assumptions about what the cause was unless you really know, in which case you're not assuming. Give all the information needed to solve the problem. If Perl did something you think was wrong, at a minimum you should report the version of Perl and the platform you were running it on (the output of perl -V is designed for this purpose). Be succinct. If you have a 1,000-line program that generated an error, no one is likely to read the whole thing for free. Condense the problem to the smallest piece of code that demonstrates your issue. Often this process will reveal the answer to you. Code of fewer than 50 lines has a good chance of being read. Show that you want to learn. Say where you have already looked in the documentation for help. Did you try a Google search? See in particular http://groups.google.com/ where you can look to see if someone else has already asked the same question. If you've found something wrong with someone else's code and you think you know how to fix it, send them the fix (preferably in diff -u format). Such an act takes you out of the category of questioner and puts you into the developer camp, where you will be warmly welcomed (especially if your patch works).
An excellent example of such a question was forwarded to me while I was writing this chapter, and I include it here because there's a twist to it. First, the question:
I'm working on two slide shows—one on my personal page with photos of my college reunion. This one is working just fine. Take a look: [URL deleted] I'm using a free perl package from [URL]. When I try the same code on [other Web site] it hangs up with no error message. [hosting service] is the provider for both pages, but they do have different security for personal pages than for business web sites, and they really don't encourage people writing their own perl code, so I'm posing the question to you first. Here's the code and output for the subroutine it hangs in. First, here's the output: [Debugging output mostly deleted. It referred to variables called 'this' and 'that'] this is ..........., that is <--doesn't paste into this message. "this" is 4 of those square boxes, then an N with ~ over it and an upside down ? next to it followed by 9 more square boxes. "that" is similar with a P before the funny N and an s after the next square box. You can view it yourself at: [URL] And here's the subroutine: Note I've peppered it with print statements. [code deleted]
Notice how the questioner provides complete information as to what she's doing, where her code came from, URLs for working and nonworking examples, what the output is (with particular attention to unusual characters she doesn't understand that might not show up the same way for the reader), and the code snippet (not shown) where the problem occurs.
The twist is that the questioner, Mary Byrne, was the 71-year-old mother of a friend of mine. Clearly, age is no barrier to learning how to frame questions properly. Or to learning Perl.
| 