If this is your first visit to my site, welcome. I've written a book called Modern Perl which explains how Perl 5 works and how to program Perl effectively. Electronic versions are free to download and redistribute, and print versions are for sale. I hope the book is useful to you; please tell other people about it.

If you're an employer or recruiter looking for good Perl developers, the whitepaper Where to find a programmer who knows modern Perl may help you. See also How to Identify a Good Perl Programmer.

If you're a programmer yourself, I recommend The Lemon Market of Programming Language Adoption, which explores the economics of why programmer salaries get pushed down in popular fields.

Hiring Great Programmers is Difficult

One of the persistent rationalizations for not creating new software in Perl is that it's difficult to find great Perl developers.

That's half true.

It's difficult to find great developers in almost any language, unless your language community is so small that it's self-selecting against people just in it for a paycheck. (Even in that case, the truly great developers who know Haskell or Smalltalk or Common Lisp tend not to be in want of work for long.)

In another sense, it's difficult to hire great Perl developers because it's so very easy to become a mediocre Perl developer. Despite the repeated myth that Perl is difficult to learn, it's not. It's shockingly easy to learn just enough Perl to build a working system. If you remember the mid to late '90s at all, think back to all of the tiny little form scripts that you could FTP into a cgi-bin directory. Most weren't worth using, due to various limitations, but real people learned just enough Perl to write them.

It's more true to say that Perl programming is easy to learn but not simple to learn well. (This is not unique to Perl; you can explain Smalltalk's syntax to a class of rapt sixth graders armed with only a 3x5 notecard, but said students won't approach Ward Cunningham in ability any time soon.) Perl, like PHP, suffers somewhat from the ease at which you can learn just enough to be productive. In terms of language design, there's no initial turnstile which keeps people out who aren't yet smart or experienced or stubborn enough to figure out how to wrestle with a compiler, or type errors, or the precise alignment of invisible characters, or configuring a web server, or setting up authentication with a database.

There's also nothing in the language which forces people to stop every hundred lines or ten programs or two weeks to push them up the learning curve a little bit more.

The result is a language that lots of people know a little bit. Many people know it well, but the group of people with a little bit of knowledge (likely due to ad hoc experimentation and intuition based on previous familiarity with another programming language or Unix culture or just copy and paste osmosis from a barely-working heap of sticks left by the previous maintainer) dwarfs that smaller group of experienced programmers.

Hiring from this pool of experienced programmers would be easier if the people hiring Perl programmers knew to hire from this pool of experienced programmers—but this problem exacerbates itself. Without a cultural or financial incentive to encourage novices to become adepts, only the most stubborn, the most motivated, the most curious, and the most fortunate realize that tools such as Perl::Critic and Test::More and Moose exist. It's one thing to know about the CPAN and use it when it helps you—that's what a mature programmer will do—but it's far too easy to get by without realizing how many great tools are available. This is a failure of Perl culture and documentation, that the CPAN isn't better publicized.

Then again, too few novices even know how to take advantage of all of the Perl documentation that comes with every complete Perl installation.

One solution, as I see it, has two parts.

Perl Programming Skills

First, if you want to hire great Perl developers, look for people who:

Know how to use modern Perl tools

Have used CPAN modules

Participate in groups such as Perl Mongers, PerlMonks, and YAPCs

Subscribe to mailing lists for projects of interest

Own, or have read, great books like Perl Best Practices, Effective Perl Programming, or my own Modern Perl

Perl Programming Promotion

Second, the existing community of Perl developers can expand itself by finding novices and dabblers and encouraging them to continue their education in the ways of Perl. Part of that is evangelism, such as How to turn mediocre Perl code into elegant Perl code or How to take advantage of improvements in Perl. Part of that is spreading the message that discipline and education are the solutions to unmaintainable code. Part of that is expanding the boundaries of the existing Perl community to include the silent majority of people who've programmed Perl to demonstrate how their lives can be easier when their code is shorter, simpler, more robust, safer, more secure, more powerful, and easier to understand and to maintain.

One important step is to promote all of the wonderful language extensions available on the CPAN—not that you must use Moose or Moo or whatever to be a good Perl programmer, but that the tools are available for you to use when they help you.

As with almost every other programming language, Perl is only as difficult as we allow ourselves to make it. I believe the Perl community has done a great job in the past few years helping the world's best Perl programmers become more productive. Now we have the opportunity to spread that outside of that community.

A Word about Programmer Salaries

Of course, if you are trying to hire someone to write software that's essential to your business and you're not willing to compensate developers effectively, you're going to have trouble attracting good developers. You don't necessarily have to break the bank on salary; benefits such as working remotely, profit sharing, contributing to free software, allowing time for refactoring, et cetera may all make your business more attractive to good programmers.

If, on the other hand, you treat programming as if it were assembly line work (as if programming were merely the act of transcribing business requirements into code by rote), you're going to get what you deserve: mediocre software written by low bidders.