If this is your first visit to my site, welcome. I've written a book called
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
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
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
- 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
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
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.