You misunderstand why I have that rule. If you have code on CPAN, that means I can read it. If you are vouched by someone who has code on CPAN, I can see the quality of the person doing the vouching. That gives me a standard by which to measure the work you will do on MY
code. Yes, you're right - there's a lot of dreck on CPAN. That means I know not
to hire that person.
Some background - I was a consultant for several years and in every interview I went to (often 2-3 every 6 months), I'd be asked for code samples. Well, I didn't have any because everything was owned by the employer. CPAN, for me, was a way of getting code that was mine that I could show a prospective employer. And, more importantly, it showcased my abilities to provide independent value, manage large projects, and work with clients.
Anyone I hire is going to fall into one of two categories - experienced or intern. If you're experienced, I want to see proof of that. In Perl, that probably is going to be CPAN. If you're junior, I'm hiring you cause I know your professor at school through another set of networking.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?