For the past couple of years I have wanted to codify what I actually do when I need to solve a Perl problem, even though I don't think I am naturally gifted or have any special insight into the matter. As one colleague told me, "An expert is somebody who has made every mistake." I have certainly made a lot of mistakes, and after I get tired of a certain mistake I look for a way to not make it. For Perl, I wrote my way of trying to not make mistakes in "brian's Guide To Solving Any Perl Problem".
I passed my guide around to my usual reality-checkers and I have let it sit for a month, so now it is your turn to see it, tell me where I went wrong, and add what you do right.
This is the first document I release for the new Perl Documentation Project which wants to create living Perl documentation that can flourish, change, expand, and adapt even if the original author abandons it (like much of the present documentation).
As a community we know quite a bit, but we have trouble passing it around. Other communities, such as FreeBSD or Linux, abound with HOW-TO documents. We can say "Read the docs" as often as we like, but something needs to connect the hundreds of pages of Perl reference documentation to practical, everyday experience.
If you are an expert in your area, share your mistakes too