Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Getting Better at Finding Answers

by luis.roca (Deacon)
on Apr 11, 2011 at 21:59 UTC ( #898790=perlmeditation: print w/replies, xml ) Need Help??

The checklist below is based on one I wrote for myself recently fleshed out for further clarity. I hope that in sharing this example fellow new to new-ish Perl programmers will be inspired to create their own system. If you do, I hope it brings great experience, knowledge and a willingness to share them with others.

About This Guide

This guide isn't an attempt to prevent new Perl programmers from asking questions. It's more to put us on a sure road to learning and gaining experience. We will always need answers. Hopefully a process like the one below will equip us to ask even better questions.

We're looking to set up a reliable system that furthers our knowledge of Perl while methodically moving toward strong solutions. Solutions we won't forget while picking up a few other things along the way. Ideally each of us has at least one decent Perl book that we've begun reading. However, because there are so many great Perl books, this guide is purposely designed to not require one.

  1. Grab a note pad
  2. Get away from the computer and write out your problem clearly with pen and paper. A little distance from your laptop, relaxed and thinking loosely can give you better clarity of purpose. If you haven't already, break down your program and the problems you're having into the smallest units possible. You'll realize what started out a large, murky question will now be a handful of smaller, more focused bullet points. Once you have created a working list of questions we can now attack the problem more efficiently.

  3. Has Someone Done This Already?
  4. Probably. Almost definitely. Ask your favorite search engine and find out. Give special preference to sites like PerlMonks and Perl mail lists that are well established and peer reviewed by experienced Perl programmers. A few of these same experienced people also have great blogs that we can rely on when they come up in search results. If it's a blog or forum we never heard of before it doesn't mean the information is wrong but definitely double check the given answer.

    If and when we do find (at least what we think is) a solution there will still probably be a little more work involved in polishing dull spots. We'll add any new questions to our list and move on to #3.

    *NOTE: We'll save a copy of any code we're going to use along with it's corresponding web page. We'll also keep the latest documentation of any modules we decide to try close at hand. (Also keep track of the module version you're using and any recent updates made to it.) When we loop through these steps again (See #4) we'll consult these source pages and documentation to walk us through any errors we've made.

  5. Searching the Documentation for Answers
    1. Open up perldoc perltoc (you can also use perldoc perl) on the command line and keep that open in a nearby window while navigating the other docs for help.

      The perldoc's table of contents is a document we should have open whenever working in Perl. This is nearly always my first stop when I'm looking for something in the perldocs. It's been one of the best ways to learn what the perldocs has to offer and will be valuable in finding our way around.

    2. Ask perlfaq. There are a few easy ways to do this. The first is by looking at perltoc and scrolling down until you see:

      The Questions perlfaq1: General Questions About Perl perlfaq2: Obtaining and Learning about Perl perlfaq3: Programming Tools perlfaq4: Data Manipulation perlfaq5: Files and Formats perlfaq6: Regular Expressions perlfaq7: General Perl Language Issues perlfaq8: System Interaction perlfaq9: Networking

      Below that you'll see that each of the documents has a list of all the questions it covers. See if one of them covers the problem you're having and navigate there.

      For example: A common question is how to display and manipulate dates in Perl. Specifically, I want to see how to display the Julian Day. I look under: perldoc perlfaq4 *(Data Manipulation) and either scroll (or on *nix type '/' followed by search term(s)) to the question: 'How can I find the Julian Day?' I get information on a few modules and some examples on how to use them:

      perldoc -q Julian
      The perldoc then returns:
      Found in /System/Library/Perl/5.10.0/pods/perlfaq4.pod How can I find the Julian Day? (contributed by brian d foy and Dave Cross) You can use the "Time::JulianDay" module available on CPAN. En +sure that you really want to find a Julian day, though, as many peop +le have different ideas about Julian days. See for instance. You can also try the "DateTime" module, which can convert a dat +e/time to a Julian Day. $ perl −MDateTime −le'print DateTime− +>today−>jd' 2453401.5 Or the modified Julian Day $ perl −MDateTime −le'print DateTime− +>today−>mjd' 53401 Or even the day of the year (which is what some people think of + as a Julian day) $ perl −MDateTime −le'print DateTime− +>today−>doy' 30

      Right at the top you'll see the path to perlfaq4. It's not a bad idea to read over the questions found in the perlfaqs in the perltoc a few times. This way when we search them again we might remember that questions about working with dates are in perlfaq4.

    3. Search perlfunc for other ready made solutions.

      There are a TON of functions that come with Perl. It's likely at least parts of what we want to do can be resolved with a built in function. This is a little harder at first because there are so many functions and we're just learning how to write Perl so they may look a little strange to us. However, perldoc perlfunc is an excellent document.

      At the top is a description on how functions are used in Perl. For now we already have an idea of what we want, we just need the name of the function and how it's used. Scroll down to 'Perl Functions by Category'. Let's say we have a list that we need to manipulate. Briefly going through the categories we see 'Functions for list data' with seven functions displayed. We may already recognize some of them like join and qw//. We know what they do and that they won't help us in this particular case. That leaves us with five to research. Functions are listed alphabetically. We look up grep in the same document. (Sort of but not really what we want to do.) Then we look up map and think we've found a function to use for our problem.

      Maybe we already know that we need to look up map based on the example we found in our Google search. We can search perlfunc similar to how we did with perlfaq:

      perldoc -f map
      perldoc perlfunc returns the entry for map:
      map BLOCK LIST map EXPR,LIST Evaluates the BLOCK or EXPR for each element of LIST (l +ocally setting $_ to each element) and returns the list value +composed of the results of each such evaluation. In scalar cont +ext, returns the total number of elements so generated. Eva +luates BLOCK or EXPR in list context, so each element of LIST +may produce zero, one, or more elements in the returned val +ue. @chars = map(chr, @nums); translates a list of numbers to the corresponding chara +cters. And %hash = map { get_a_key_for($_) => $_ } @array; is just a funny way to write %hash = (); foreach (@array) { $hash{get_a_key_for($_)} = $_; } Note that $_ is an alias to the list value, so it can b +e used to modify the elements of the LIST. While this is usef +ul and supported, it can cause bizarre results if the elements + of LIST are not variables. Using a regular "foreach" loop for +this purpose would be clearer in most cases. See also "grep +" for an array composed of those items of the original list for +which the BLOCK or EXPR evaluates to true. If $_ is lexical in the scope where the "map" appears ( +because it has been declared with "my $_"), then, in addition t +o being locally aliased to the list elements, $_ keeps being le +xical inside the block; that is, it canít be seen from the ou +tside, avoiding any potential side‐effects. "{" starts both hash references and blocks, so "map { . +.." could be either the start of map BLOCK LIST or map EXPR +, LIST. Because perl doesnít look ahead for the closing "}" it +has to take a guess at which its dealing with based what it fi +nds just after the "{". Usually it gets it right, but if it does +nít it wonít realize something is wrong until it gets to the " +}" and encounters the missing (or unexpected) comma. The synta +x error will be reported close to the "}" but youíll need to ch +ange something near the "{" such as using a unary "+" to giv +e perl some help: %hash = map { "\L$_", 1 } @array # perl guesses +EXPR. wrong %hash = map { +"\L$_", 1 } @array # perl guesses +BLOCK. right %hash = map { ("\L$_", 1) } @array # this also wor +ks %hash = map { lc($_), 1 } @array # as does this. %hash = map +( lc($_), 1 ), @array # this is EXPR +and works!

      If we haven't solved our problem by now, we should at least have made good progress towards our solution.

  6. Loop Through 1 - 3 Again
  7. * Let's keep attacking items on our list from difficult to easy and again with the easiest to the hardest. We keep moving. We don't allow any one problem to slow us down long. Solving some of the other problems quickly can help reveal a hidden answer for tougher issues. When we're left with items that still aren't fully resolved it's likely we're going to need a little extra help. Looping through the first three steps one more time clarifies our questions further in preparation of #5.

  8. OK, Now It's Time to Ask Someone
  9. We have a clear idea of our overall goal. We've paid attention to specific problems that can be made into clear questions and any code we wrote that shows attempts to resolve the issue. The more organized we are the more successful we will be in encouraging others to help. Our question(s) will look different (probably very different) from the ones we started out with. We organize all relevant code (only what's relavant to our question) ready with any errors we've been returning *(because we remembered to place:

    use strict; use warnings; use diagnostics;
    at the top of our file and consulted the perldocs for their meaning ó right?). We can first stop by the chatter box here on PerlMonks. (Remember to paste all the code in your scratchpad.) If, for any number of reasons, our question can't be addressed there, we'll post (see How do I post a question effectively?) to Seeker's of Perl Wisdom.

    * After PerlMonks, a few other good places to try are Perl's irc channels or the beginners' mailing list.


  1. Break down your problem on paper.
  2. Do a web search.
  3. Search the perldocs:
    1. Use perldoc perltoc as a guide.
    2. Search perlfaq
    3. Search perlfunc
  4. Clarify any remaining questions by repeating 1 - 3.
  5. Time to ask for help.

By no means is this checklist perfect. Although I feel confident it will be helpful as written, if it inspires you to come up with your own ó that would be even better. The idea is not to copy mine or anyone else's but to find a system that works for you. One that you can rely on over time.

A Few Points to Consider When Creating Your Own Checklist

  • Do you filter out problems that are NOT important to you?
    Going through a well designed checklist on problems you realize later aren't worth solving will suck the energy out of having a list in the first place. It's also not great for your overall health.

  • What resources do you consistently have available?
    Recently, I was away for about two weeks with spotty electricity let alone an internet connection. I had print outs I took with me on writing object oriented Perl, some notepads and a sketchbook. I spent most of the time writing essentially fake letters to my imaginary friend about projects I wanted to do and how to do them. (Did I mention caring for your mental health.) Where I knew how, I added variables, statements and subroutines even though I knew most if not all of it wouldn't work as an actual program.

    That's an extreme example but I felt so much better about moving forward with my work and learning Perl. Limit the resources your system relies on to what you ALWAYS have available. You might find that the streamlined approach gives you greater creative space.

  • How do you learn?
    My wife reads (more like completely absorbs) one book at a time. Cover to cover. Quickly and completely. I don't do that. I'll 'graze' among a stack of books over a longer time span. I do it out of mood, necessity or just for immediate comparison. Honestly consider how you process information and tailor your list accordingly.

Again, I hope this helps! :)


* Special thanks to my niece for sharing the test taking tips she's learning in her SAT class. :)

  1. Updated on the 11th of April, 2011: Cleaned up some grammar and typos.
  2. Updated on the 14th of April, 2011: Added to #2 the note on keeping a copy of any code we find along with it's sourced web page and module documentation.
    Thanks to Anonymous_Monk for suggesting the addition.
  3. Updated on the 17th of April, 2011: Added to #3, list item #1 perldoc perl as an alternative to using perldoc perltoc as a guide to the perldocs.
  4. Updated on the 24th of April, 2011: Removed '' mail list as a dependable resource while it's going through a transition.

"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." ó Don Quixote

Replies are listed 'Best First'.
Re: RFC: Getting Better at Finding Answers
by sundialsvc4 (Abbot) on Apr 12, 2011 at 00:44 UTC

    An excellent resource!   Wow!

    The only small thing I would add is:   Watch out for the “XY Problem.”   (Google it...)

    When you are considering your problem, or your challenge, or your immediate task, be careful not to jump to premature conclusions ... be sure that you are exploring the problem and not “the first possible approach to that problem that just jumped into your head.”   The CPAN library is vast, and if you keep your imagination wide-open you will probably find “a better-for-you way to do it” that might be completely unlike your initial assumptions.

    You will be especially prone to this if your natural way of tackling a problem is to quickly latch-on to the first approach that you think of, and to then pursue that one approach with relentless vigor, not discarding it until you prove to yourself that it simply cannot be made to work.   (If you think that I am describing myself, I am, indeed.)

      Thank you, especially for pointing out the 'XY Problem'. I think I hinted at it but it's important to be clear: Asking about the solution to your problem rather than the problem you are having can lead to a lot of wasted time. The solution may be solved but the original purpose ó 'your actual problem' will remain unsolved. I do think there is value in learning and solving for Y as long as it's always paired with X from the beginning. Especially in the context of asking questions on PerlMonks and such.

      You will be especially prone to this if your natural way of tackling a problem is to quickly latch-on to the first approach that you think of, and to then pursue that one approach with relentless vigor, not discarding it until you prove to yourself that it simply cannot be made to work. (If you think that I am describing myself, I am, indeed.)

      I think I take this for granted coming from graphic design. I've been creating many many versions on an assignment since I was 19 so it's just a given to do that. It's probably not exactly practical to create 3 to 5 versions of a program to present to a client. (I've never been asked to present 3 -5 versions of my html ó most clients don't want to look under the hood). For a specific 'bullet point' I would definitely explore a few different possibilities. The trick is knowing when to stop and say "I've explored the problem enough now lets pick a couple and carry them through to see which will work best." Again, my experience in an IT department is limited so I wouldn't know if that's reasonable practice.

      "...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." ó Don Quixote

        /me nods...

        The crux of my suggestion, is, indeed, that one needs to explore the problem and then to pick a couple of them to carry forward.   It is easy, very easy, to walk (too...) confidently in a particular direction without really considering where you are going and ... suddenly you are having “a Wile E. Coyote moment.”   (You’re standing in mid-air, holding some very-heavy something made ... of course ... by Acme, and you are definitely not the Roadrunner!)   “Look before you leap” is sometimes easier said than done.

Re: RFC: Getting Better at Finding Answers
by Lady_Aleena (Deacon) on Apr 13, 2011 at 19:30 UTC

    For number 3, you could also suggest an alternative to the command lines docs. There is the Perl programming documentation online which is just as extensive as the perldocs that come with perl, however the website is clickable so a user can go from one item to a related item with relative ease. There is a plug-in for search boxes at Mycroft for Perldocs as well. I prefer the web docs over the command line docs. In my opinion, they are easier to read. The docs have many pretty colors. :)

    Have a cookie and a very nice day!
    Lady Aleena
Re: RFC: Getting Better at Finding Answers
by petecm99 (Pilgrim) on Apr 12, 2011 at 13:51 UTC
    You had me at "Give special preference to sites like PerlMonks..." :-)
Re: RFC: Getting Better at Finding Answers
by Anonymous Monk on Apr 12, 2011 at 15:19 UTC

      Thanks for catching that AM. I added the following note at the end of '2. Has Someone Done This Already?':

      *NOTE: We'll save a copy of any code we're going to use along with it's corresponding web page. We'll also keep the latest documentation of any modules we decide to try close at hand. (Also keep track of the module version you're using and any recent updates made to it.) When we loop through these steps again (See #4) we'll consult these source pages and documentation to walk us through any errors we've made.

      "...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." ó Don Quixote

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://898790]
Approved by ww
Front-paged by ww
[Your Mother]: Missiles would be an idiotís play. Putin is many things but he is not an idiot.
[erix]: I like the idea of the trumps troup of imbeciles growing slightly nervous now their incompetence will be tested
[erix]: you seem forget there is another idiot coming :)
[Your Mother]: The US government does not attract talent, but grafters and liars and it has been that way for the better part of a century. FEW exceptions.
[erix]: you think it only /looks/ worse this time?
[Your Mother]: HR Clinton was literally threatening Russia. She would have been MUCH more likely to start real trouble.
[Your Mother]: I think there is less decorum this time.
[Your Mother]: Weíve had rapists and thieves and unqualified government. They just had decorum.
[erix]: heh, understatement of the week :)
[erix]: well, I hope you're right

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2017-01-20 01:01 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (173 votes). Check out past polls.