in reply to Perl Certification revisited

You are working in the field that changes the fastest in world history. Seriously - there has never been a field in human endeavor whose tools have morphed so quickly and so completely as computer programming. What do I mean? Well, let's take a look at my first three Perl jobs: Whoa! What kind of cert should I get there? Do I get three certs?

Let's take a look at MySQL certs. I've been a MySQL DBA for over 2 years. I toyed with the idea for a while of getting the DBA certs and realized that it was a complete waste of my time. Why? Two reasons:

  1. The certs are someone else's idea of what I should know. Frankly, I need to know whatever it takes to get the person paying me what they need.
  2. The certs are so behind the times that it hurts. If I had certified when I first started being a DBA (back when 4.1 had just come out), I would know nothing about views, stored procedures, cluster, and everything else released since then. In fact, I'd be emphasizing my lack of suitability for a job with an up-to-date MySQL install.
The best certification is still the same - your reputation as spread by word of mouth. And, Perl is the best language within which to get that because the community craves new people working on CPAN modules. You want my recommendation? Take over PDF::Template and PDF::Writer and show me what you can do with it. I have gotten my last six (seven?) fulltime jobs, several on-the-side contracting gigs, and at least two fulltime offers I chose to not take primarily due to my CPAN work and the reputation I've gained as a result of it. It's to the point where I will only hire Perl developers who either have stuff on CPAN or are vouched for by someone who does. And, I'm not alone in that. Show me how a certification (or even ten certs!) can match that.
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?

Replies are listed 'Best First'.
Re^2: Perl Certification revisited
by CountZero (Bishop) on Oct 02, 2007 at 07:29 UTC
    It's to the point where I will only hire Perl developers who either have stuff on CPAN or are vouched for by someone who does.

    Actually that is one of the best criteria for checking someone's Perl-fu I heard in a long time.

    But sadly one must also admit it will only work for those who know about CPAN and for many PHB a shiny certificate with stamps and seals is "easier" to accept: if anything goes wrong you can always point to the certificate and say "I know he trashed our database, but he was certified for the job!"

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]

      I will only hire Perl developers who either have stuff on CPAN or are vouched for by someone who does

      I disagree with this because CPAN is about common useful utilities to the community, not to pad someone's job credentials.

      I also don't like the exclusivity of saying "I created a module on CPAN therefore I must be an expert". How many Perl programmers are there in the world? 50,000? They should be vetted by the 1,000 authors on CPAN? It is unrealistic and being a CPAN author does not necessarily indicate their ability to determine another persons skill set.

      I would love for Perl to be treated (by PHB's) as a true PROFESSIONAL language that is on the same level with .NET or Java rather than just a scripting language like BASH. If that means that is a Perl certification would bring this level of recognition then I am all for it.

      While I agree that a certification is not necessarily a good way of determining a persons skills. It does provide something to make a decision on besides a gut feeling This is especially so for a non-technical manager..

[reply]
        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:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      But sadly one must also admit it will only work for those who know about CPAN and for many PHB a shiny certificate with stamps and seals is "easier" to accept: if anything goes wrong you can always point to the certificate and say "I know he trashed our database, but he was certified for the job!"

      I heartily agree.

      I've started my contribution to CPAN, albeit small at this time I plan for it to grow. It's something I'll mention with great pride when I put forward a proposal to companies, but sadly unless they are Perl people I'll be getting a blank expression on their face. Most of them only understand certification.

      Lyle
[reply]

In Section Seekers of Perl Wisdom