The Rising Costs of Aging Perlers: Part 1, The Data

Hello, Friendly Perl Community! You may not want to hear this, but you’re not getting any younger. This is having a dramatic effect on the bottom line of companies which do or would use Perl.

A few months ago I started helping a friend recruit Perl developers for the company where he works. Aside from talking to the many people I know in the community I also put out several open calls for developers interested in switching jobs. I’ve now met and spoken with many great people—most of whom I’d never have had the chance to meet otherwise—and I’m very grateful for that opportunity. It’s helped remind me why Perl is my open source community of choice.

However, after only a few weeks I started to notice something odd: I had yet to speak with anyone who wasn’t Senior Developer. The overwhelming majority of persons with whom I spoke had well over ten years of experience with Perl. I believe the lowest number of years of Perl experience I saw was around eight. In my town of San Francisco it’s reasonable to see Senior Developers with five or fewer years of experience with a language. You can quibble with that definition, but there’s no denying that it’s the way we do things here. And since I was recruiting for a San Francisco office, all of these candidates qualified as Senior.

When I recognized that I was only speaking with (or even hearing of) senior developers some gears started turning in my mind. To verify my suspicion that Perl is a language of aging practitioners with few people available to replenish the ranks, I gathered some data…

Exhibits A and B. Since 2009, YAPC::NA and YAPC::EU have asked the following question on their respective post-conference surveys:

How do you rate your Perl knowledge?

  • Beginner
  • Intermediate
  • Advanced

All YAPC survey data is available online. I compiled the data from the past four years of responses to that question. The result was the following graphs. The Y-axis is the number of respondents in that year.

YAPC::EU Perl Experience by Year, 2009-2012
YAPC::NA Perl Experience by Year, 2009-2012

As the definitions of “Beginner,” “Intermediate,” and “Advanced” are left as exercises for the respondent, it’s impossible to make a direct correlation between these results and my soft definition of “senior developer” as one with five or more years of experience. Regardless, it’s very obvious from these graphs that there are remarkably few junior Perl programmers available and that issue is not being resolved as the years pass.

Because the best kind of data is MOAR DATA, I ran a very informal poll on the Linkedin Perl group. The question and results:

How many years have you been programming Perl?

70% of the respondents have more than five years of experience programming Perl. A mere 13% are new to the language. (If you tilt your head to the right you can see a graphic summary of what this might mean for the Perl community.)

Granted, there is no small amount of selection bias going on here. People who attend YAPC or participate in the Linkedin Perl group are more likely to be more experienced and comfortable in the community than more junior developers.

Regardless, after seeing these numbers I’m convinced that the practitioners of Perl are aging and not enough junior developers are being created to sustain the language as a going concern in the development world. What’s worse, Perl does not appear to have any sort of succession plan. It’s turning into the Shakers of the software development world: attempting to rely on conversion for proliferation rather than on reproduction.

In the next post, I’ll tell you why you should care about this. Read Part 2

21 Replies to “The Rising Costs of Aging Perlers: Part 1, The Data”

  1. I’m planning on reorganising some of the questions, as some are no longer as informative as they once were. I’ll look to include the years programming Perl question. If you have any other suggestions, please let me know.

  2. I see this problem caused by two components:

    1. Companies are notoriously bad at training new developers. Most companies i’ve interacted with wanted fully trained developers. Training them is seen as a last resort measure.

    2. Perl is not taught as school as it is described as “Hard to Learn” by python people. (Which is historically partly correct, since the camel, lama, etc. books were never updated to modern development and teaching practices.)


      Someone on the mailing list asked me why this URL would even matter. Well, it’s Hixie for one thing, and people listen to him. Lots of people.

      Ovid’s Beginning Perl seems to be a nice substitute for (or companion to) the Llama.

  3. Great posts! I’m commenting here on part 1 because your notes about YAPC are especially relevant to what I have to say.

    I’m going to be giving a talk at this year’s YAPC::EU about hiring non-Perl people and training them up in Perl. ( The theme of this year’s YAPC::EU is “Future Perl” and I hope I’m not the only speaker who reads that theme and immediately thinks training, junior developers, and marketing.

    Also good news for your charts is that I’m going to be bringing my current development team along with me, two of which have around 2 years of Perl experience 🙂

    Here’s to the future of Perl!

  4. I was at Europython this year. There was a keynote by someone from the Python foundation, where he worried (among other things) about getting new people and the future of Python the language. I looked around at the 30-ish kids (the greybeards were few, far between and noticeable) and laughed, thinking of when this exact same concern is expressed in Perl. I also thought of Ada and the average age I saw in the Ada dev room at FOSDEM. Older whiteheads who remembered Algol-68, if only a little.

    If the “hipper” languages with a younger dev base are worried about their own futures, then I guess Perl should pay attention to whatever solutions they come up with for themselves. Having Perl people show up at other tech events and discussing pros and cons of working with particular languages would really help I think, since most people, when asked if they’ve ever done Perl and the answer is “yes”, it’s almost always followed by a description of hacky old CGI scripts back in the 90’s. Spreading Modern Perl at events like Europython and hacker/tech events could help that image a bit.

    Oh lord a CAPTCHA. They’re evil. That’ll be a few negative karma points.

    1. If the perl community wants to get new people and new ideas in to keep the language alive and flourishing, they would do very well to have a think about how they as a community collectively treat new comers who have big ideas but lack the experience to implement them.

      A few years ago I was such a person. I had invented something called aXML, which at the time as far as I knew was the fastest CGI system going. I didn’t know anything about catalyst or PSGI etc and I was raving about my solution and got shot down in flames by various folks at PerlMonks, one of whom even went so far as to tell em that he personally was going to make sure that I never got a job in Perl, for my terrible crime of being young naive and excited about something I’d made.

      Well anyway, aXML evolved, it’s now called Diamond and I’ve spent several years making sure that it’s performance is nothing short of stunning. I haven’t released it yet because after my first experiences with this “helpful” community, I am reticent to do a release until I’m 110% sure that any and all criticisms made of it are down to personal bias rather than any actual technical flaws or issues.

  5. In my local Perl Mongers group we’ve been trying a format where one presentation would be in the “advanced” category, and another one would be in a “beginner” to “early-intermediate” category.

    The advanced presentation is going to keep the old people coming back. The beginner presentation serves two purposes; first, it makes us friendly to newcomers. Second, it allows, say, intermediate Perlers to also give presentations.

    We also have been doing our best to reach out to other communities, as well as to the .edu people. So far it seems to be working; our meetings have been growing. Admittedly, we’re fairly new, but the growth has exceeded my expectations. And there seems to be a sort of excitement within the group — we’re actually really pleased to see people just starting out with Perl show up.

  6. As a grey beard, business owner and employer, I found it essential to hack my way through Perl and Linux for survival. My younger employees, though skilled and smart, want nothing to do with Perl for fear of failure or…? I now have many things working the way needed, but who will maintain things?

  7. There are several interesting things here. First, how you recruit and who you are is going to impact who you find for developers. If you’re “asking your friends”, that may not be a representative sample. Since my wife and I are now doing international IT recruiting, I promise you that we’re hitting *plenty* of applicants who know Perl, who are younger and who are not experts at it. That being said, I wouldn’t generalize from my experiences, either. I did, however, note a very interesting thing: those of our candidates who pay attention to the community are more likely to produce higher quality code (in terms of functionality and fewer bugs).

    That last point brings me to conferences: I suspect we’d find the same issue there. Someone who is not involved at all in the community may be less likely to go to a conference due to lack of knowledge of them. Someone who is heavily involved is more likely to know about conferences and thus more likely to go to them. Thus, we may find a built-in bias towards skilled individuals producing your graphs above.

    Or, given my experience with many developers, your graphs above could very well be plotting the Dunning-Kruger effect (

    If you compile similar graphs for other “single language” conferences, then I’d find this more useful.

  8. out of curiosity, what sort of age/proficiency profiles do you see with other languages?

  9. We’ve been interviewing for junior perl positions where I work, and we can find applicants with some perl exposure, but they’re unlikely to describe themselves as Perl Programmers (when not applying for a perl job). They also are (mostly) not very good (e.g. they don’t know how to deal with an array of hashes). There may be something of a catch-22 here: the people hiring really want people with Senior Programmer skills who are willing to work at Junior rates.

    Myself, I’ve suggested that we just start training them. For example, what if I started training them during the job interview, and we see how fast they can pick up on what I’m telling them? We haven’t gone in that direction yet.

    1. I’m a a college grad, a perl hacker because I was lucky enough to meet a great teacher, and have been looking for a junior position. I rarely see listings for perl, and junior positions in perl in the SF bay area are basically non existent. The closest I’ve come was a job where they listed perl, but really want python. And I found out about that from a recruiter.

      Jobs drive interest. You want people who know perl? Contact people who teach perl at universities, and tell them there are internships and jobs, and give them your contact info. Have the people who teach perl be the ones who can get you a job or summer internship, and they will never lack for students.

  10. Pingback: binäre optionen
  11. Pingback: binaere optionen

Comments are closed.