The Perl Review is another publication that I recommend.

Perl.com often publishes interesting articles, and it's free.

A good way of honing your CPAN skills is to watch the recent uploads, read the documentation for modules that sound interesting, and play with them.

I find it amusing that the Google adwords system thinks that one of the two relevant ad's to place on The Perl Review home page is "What is COBOL?" :)

The Perl Review does look good - reminds me of the old paper issues of TPJ.

I notice an article on Logic programming by Ovid

I like to ward off my natural dull stale bluntitude by poking around in the odd corners of perl to see what slithers out. Trying experimental features is one easy source of that. I think most programmers agree that the best way to learn Perl - or any language - is to write some and see what breaks.

That was how I stumbled into writing Tie::Constrained. I was playing with the experimental :lvalue subs, and noticed claims that validation was impossible with them. Taking that as a challenge, a little thought persuaded me that validation needed to be wedged into assignment. The only way I found to do that was with a tie'd variable. The demonstration I wrote had a simple tied class module that proved to be a really versatile way of handling dynamic typing, among other things. It has nothing to do with lvalue subs anymore, but I would have never written it without my pushing at the edges of perl.

For CPAN module info, I do frequent i /foo/ queries in the CPAN shell for any term, library, or acronym which has caught my attention. The CPAN shell readme is a good first indicator of quality, and if it looks interesting I'll get the module and check the source.

Sometimes I "reinvent the wheel" - write something that already exists. The idea isn't to make a better wheel, but simply to learn how to make one - and in so doing, learn some new tools.

Good answer!  I completely agree that a lot can be said for "reinventing the wheel"!

In addition to "learning how to make one" and "learning some new tools":

1. Often, you need a special wheel that best fits your particular needs.
2. There's the possibility that you'll stumble onto a better/faster way to make "one"
3. You'll learn the tradeoffs involved in making "one"
4. There may be common mistakes associated with the particular "wheel" you're (re)inventing, so overcoming these mistakes will make you a better programmer
5. If you've reinvented it several times (or several dozen times), it may take you only a moment to create it in a future program.
6. You get just as much experience writing something that already exists as you do writing something new.
7. After you write it yourself, you can go evaluate the one that already exists (probably at cpan), and see how you did!
Think what the consequences would have been back in 1987 if Larry Wall hadn't "reinvented the wheel" when he wanted something more powerful than sed, awk and sh to program in!

I haven't thought of focussing on this - when I have tried, I inevitably end up realising why the module author took so many lines of code to do it when I thought it was simple! In that way it can also teach respect :)

I find discussion with team members, and members outside my direct team, can provide valuable insight to the way I do things; code reviews are excellent for this, as one cannot learn without the humility of being subject to criticism.

Just this week I've learnt some excellent techniques for greatly speeding up raw text processing and this has been through listening to others; and to them I give the credit of the speed increases..

"very few of us appreciate all the productive uses of all of Perl's features, especially outside the problem domains in which we are comfortable."

The fact is that nobody will really wonder into every corner of Perl, or any other language. For languages like Perl, Java or Ruby, which tend to have specific modules to cover lots of specific function areas, you never have the need to cover all of them, although you might occassionally open up couple of modules to see how other people do things.

Not only those specific modules, even with the basic functionalities, there is never a need to use all of them. Not only that you don't need them, you actually should intentionally avoid some of them. Almost all languages, more or less, have some functionalities that do more harm than good. It is more important to learn best practices and stick to them, than to utilize the full language.

"What do other people do to hone their Perl skills"

Lots of practice with the best practice in your mind.

* Find a local Perl Mongers Group and drop by for a few meetings. You can even offer to give a presentation on some new module--there is no better way to learn something than to teach it.

* Automate some things in your digital life. Look at anything you do repeatedly and try to write a Perl script to do it for you. Then use all the free time you've found to repeat this with something more complicated.

In the specifically Perl camp, I like reading TheDamian's code. His style stretches my understanding, whcih is the point, right?

So, for the TLA challenged among us, what is TDD?

--
Random Synapse Firing

Test-Driven Development. It's a practice that was made popular by XP (eXtreme Programming). The theory goes something like this:
1. Start with no code and no tests.
2. Write a test.
3. Run that test and see it fail. (Remember, you have no code, yet.)
4. Write the absolute minimum amount of code to pass the test.
5. Run that test and see it pass.
6. Check it into source control
7. Goto #2

At all times, your entire test suite should always pass, except for the one test that you're currently failing because that's the one specific piece of the spec that you're currently implementing. Whatever is in source control should always pass all the tests. Theoretically, you have 100% code coverage (as reported by Devel::Cover) because you never wrote a piece of code without having written the test for it first.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

One thing that works well for me is to hit http://search.cpan.org/recent at least a few times each week.

If I see an interesting new module or an update to an old module I go read up on it.

This is also a great way to keep an "ear to the ground" for new ideas moving through the Perl community - since so much of Perl's best ends up on CPAN anyway.