☑ Read a book on Perl
      or on-line manual pages, blogs, articles, ...

☑ Written a book on Perl
      or reviewed a book or contributed to a book

☑ Contributed to the Perl source code
      so you'll learn to find the edge cases and recognize vulnarabilities

☑ Debugged someone else's script
      Always a learning experience

☑ Played Perl Golf
      esp to learn about special variables

☑ Used regular expressions to save the day
      always helpful for quick results. No read the book again and start learning all the flags and markers :)

☑ Used Perl for a certain amount of time (please specify)
      Daily since 4.018

☑ Invested a certain amount of man-hours in learning Perl (please estimate)
      On the job

☑ Visited at least x Perl related events
      also to get new (sick) ideas for modules or module features

☑ (Co)maintain at least x active (up-river) CPAN modules
      to learn what the rest of the world expects of perl and the sick things they do with it. Also to write documentation that is actually read

☐ Forgotten you were not Larry Wall

☐ One can never truly know Perl
      One can not truly know *all* of Perl, but you can certainly learn enough of Perl in the area you want for your project. It is not required to know every tiny detail about floating points and internal behavior if you only use integers. You don't need to know about threading implications if you never use threads (unless you write XS code that might be used in threaded perls). You don't need to know anything about <c>format<c>s to have a decent Perl project. You don't need to know about locales and encoding if all you do is number crunching.