Probably the most recent (of many) examples:

We use a queueing system to submit thousands of jobs in a Linux environment (LSF job arrays). It is necessary to periodically check the status of the jobs. However, I have been unable to coax the status command to provide meaningful names for the jobs, rather than just their job ID number (for example, if I submit 5000 jobs, I want to know if job "foo" and job "bar" are still running, instead of ID647 and ID4902).

To do this, I would have to sift through the vebose and poorly-formatted output of the status command to find the directories holding the output status files. Then I'd have to grep throught the output files to correlate ID's with job names. Bor-ing.

Within a few hours, I cranked out some decent Perl code to do the job. But, I must admit that hanging out at PerlMonks for the last couple years has given me the confidence and skills to rapidly converge on and implement a solution. A year and a half ago, I probably would have thrashed around for a few days or a week on that task, or perhaps I would have found the task too daunting.

Had I never joined, this...

• would have taken days to write, instead of hours
• would have been 5 times as many lines of code
• would have been more poorly laid out
• would certainly have more bugs

Instead, what I have...

• formats a multi-line command output to simplify parsing
• uses a compact regex to extract just the info I need
• performs input checking
• cleanly opens and parses the needed files
• stores the relevant info in a data structure which facilitates displaying
• uses POD for standard-looking documentation
• uses Pod::Usage for standardized help

I guess this is as much a PerlMonks testimonial as it is a Perl testimonial. Without Perl, I'd be in a world of hurt. Without the Monks, I'd have a really embarrassing heap of unmaintainable, unreadable, undocumented, buggy code!