OSCON 2014

Another year, another OSCON. Now that I’m approaching caught up, here’s a quick recap of that busy week.

It was a busy OSCON for me this time around. I had two talks to give, only one of which I’d finished writing before I arrived. Oops. Ah, well. They both went well and were well-received and -reviewed, so I’m a happy camper. The slides and my webcam videos of both talks are available on Internet Archive:

Because my current job is so variable, my session attendance was equally variable. I didn’t really focus on any specific things, instead giving preference to talks by people I know and respect.

And, of course, there was the evening of Perl goodness: rjbs with a whole hurricane of lightning talks (in lieu of the State of the Onion, since Larry’s recovering from eye surgery), then a dozen or so individual lightning talks. As usual, rgeoffrey ran a tight ship and kept the talks moving smoothly.

Really, though, most of my time was spent sitting or standing around and talking to people. So many people. So, so many people. I’m not even going to attempt to list them all, but it was all time well-spent. I’m grateful for the opportunity to meet and befriend so many amazing and inspiring people.

One thing that did not happen that week was productivity. Beyond talking (both on stage and off), I accomplished little of substance. Not only does that make this subsequent week more difficult, it’s also an opportunity missed. I could have done some excellent collaboration that week. So when I read rjbs’s OSCON trip report I was intrigued by his idea to set up shop at a table & just get shit done next year. I’d back that play. I have plenty of projects which need love and attention, so having a personal OSCON Hackathon wouldn’t go amiss. Thanks for the idea, Rik!

Overall it was a great trip but an exhausting. I’m honored that I was once again invited to speak and overjoyed to have spent so much time with so many great friends, both old & new. You’ve filled my head with knowledge and ideas and wowed me with your accomplishments. Now I just need to figure out how best to apply all my newfound inspiration.

San Francisco Perl Mongers: 12 months, 50% growth

A Timeline

On June 21st, 2013, Fred Moyer asked whether I’d like to discuss becoming a co-organizer for San Francisco Perl Mongers. On July 5th it was made official. Earlier this year I was promoted to primary organizer, Fred stepping aside to focus on some real life matters (though he still very much loves and is involved with SF.pm).

SF.pm: One Year In

Therefore this marks, more or less, my one year anniversary of SF.pm organizing. That seems as good as any reason for a recap. So, what’s happened in the past year?

  • We’ve held ten events.
  • We’ve been honored to host 16 different speakers (thank you, Lightning Talks, for bumping that number 😉 ).
  • We’ve added five new sponsors. (though we’re always on the lookout for more!)
  • We’ve started recording all events and making them available in our SF.pm collection on Internet Archive. (a post about how we do this is in the pipeline)
  • We’ve added 208 members, going from 394 members to 602.

That one bears repeating: San Francisco Perl Mongers has increased its membership by over 200 people in a single year.

What gives? How’d we do it?

First of all, let me be very clear: I don’t believe for a moment that these are 602 engaged members. Many are lurkers. But they’re lurkers who took the initiative to sign up and who receive our messages about Perl and its community. It’s 208 more people seeing those messages than were before, which—engaged or not—is a win in my book.

Also, another thing to get clear: I did not do this alone. While I am now the primary organizer of SF.pm I am by no means the only organizer. Fred, Joe Brenner, and Jeff Thalhammer deserve equal share in the credit.

Now, how’d we pull off this feat? As you’d expect, it was a multi-faceted approach:

  • Flexible scheduling. After Fred asked me to lend a hand, I started meeting with some local Mongers to get some feedback on where SF.pm has been and where they’d like to see it go. A lot of them said they were no longer attending because there were too many other meetups which landed on the usual SF.pm meeting night. So I scrapped the set “last Tuesday of the month” date in favor of a monthly event which would float to wherever it worked best that month. This allowed for a more diverse pool of potential attendees. Rather than just seeing the same faces each time, we now were seeing people who hadn’t been able to attend either ever or for several months at a time. As well, having a flexible meeting date made it easier to mesh our schedule with that of potential speakers.
  • Diverse content. How many of you work with Perl and only Perl, no other technology? No Javascript, no ops, no continuous integration framework, just Perl? Bloody well none of you, I’d wager. So why was our SF.pm content 100% focused on Perl? We’ve changed that. We still feature Perl in some way in almost every event but often the primary focus of an event has been expanded to “of interest to the SF.pm community.” Some of our most popular events in the past year have been about Data Science, MongoDB, and Docker.
  • Cooperation and collaboration with other communities. Our content is great, our community is amazing. Why should we keep these things to ourselves when others can benefit? Therefore in the past year we’ve been cross-posting many of our events with several other local tech community user groups. We’re Perl, so there’s more than one way to do it. That includes choice of language, so we’ve been thrilled to welcome new members coming in from the local Ruby and Python communities. The additional perspectives help enhance the experience for everyone and we’re very grateful for it. Special kudos go out to SF Ruby, who’ve been particularly welcoming of messages coming in from an external group. The SF Ruby gang really groks that we’re all stronger together than apart and that great learning opportunities can come from anywhere.

Someone else who groks this: John Anderson, aka genehack. I was really thrilled, when watching his YAPC::NA 2014 keynote, to hear him espousing many of the same steps which we at SF.pm were already taking. If you watched that talk and thought he was smoking mad crack, I’m here to tell ya: OK, maybe he was, but his suggestions work and we’re proof of it. Thank you, John. You’re my kind of crazy.

SF.pm: The Future

This post is already taking longer to write than I’d hoped, so I’ll try to wrap it up quickly. What’s next for SF.pm? What will the next year look like?

Right now there are no official plans, but here are some of the things I have rolling around in my head:

  • Update the website. The SF.pm website is…yeah. It’s dated. The only thing standing between us and a nice, clean, Bootstrap-y site on GitHub Pages is me carving out half a day to futz with the thing. It needs to happen, and it’s firmly on my radar. Perhaps I’ll stockpile a lot of round tuits at OSCON this year and use them for this purpose. 🙂
  • Engage more of the membership. We have 602 members, but they don’t really communicate that much. I’d love to get them talking a bit more, both among themselves as well as in front of the group. 602 people represents a vast amount of knowledge and I’d love to tap it so they can share their experiences with everyone.
  • Develop some sort of newbie program. Back in January 2013 I griped that SF.pm (and Perl in general) needs better outreach for newbies. I still stand by that statement. Another way I’d like to engage that burgeoning membership is to get their assistance to develop some sort of program to introduce more people to programming in general and Perl in specific. This is definitely a place where I won’t be able to go it alone.
  • Strengthen and increase collaboration with other communities. That assistance for knowledge sharing and new programmer development doesn’t necessarily have to come from our membership exclusively. When learning the fundamentals of programming (loops, functions, MVC, etc.), it doesn’t really matter which language you use. The concepts are easily applied anywhere. As well, other communities have a lot more experience organizing things like hackathons and workshops than I do. I’d love to collaborate with them to help the entire SF tech community expand their horizons.

Those are a few of the ideas I’m having. Maybe they’ll happen. Maybe they won’t but others will. Hey, that’s cool. All I know is that thanks to its amazing members SF.pm will continue to be a strong and growing community for years to come.

The Rising Costs of Aging Perlers: Part 3, The Suggestions

So, what can the Perl community do to avert this decline and potential extinction? Probably a great many things, but here are my three top suggestions:

  1. Make cool shit. Talk about it. Talk about it A LOT. What little positive image Perl retains in these modern times is primarily limited to making sysadmin/dev ops lives easier. While this is a worthy and admirable accomplishment, it’s not going to turn any heads. People will (and do) not want to learn a language with a stodgy reputation. The best way to shed that reputation is to use the language to develop cutting edge tools and services, then to shout it from the mountain tops. DuckDuckGo is written in Perl and is going toe to toe with Google. Lacuna Expanse has shattered the Perl gaming boundaries. Follow their lead. Show people what you think is possible and they’ll start proving you wrong by creating the seemingly impossible.
  2. Modernize our dilapidated online communities. As the enlightened humans we are, we like to say that looks don’t matter. Unfortunately that’s not the way our brains are wired Looks do matter, or at least they do in this case. Take, for instance, the venerable PerlMonks. The site contains a limitless source of knowledge, both historical and contemporary. But its user interface and experience are both stuck in the late 1990’s and have become punchlines for a programming language which is trying to claim relevance in the current world of technology. This perception, unfortunately, is transferred to the Perl language at large. If we want to attract new community members, we need to do it with a modern sensibility, language, and tools. Online services where you can try out Perl programming in your browser. The latest in forum and moderation technologies. An interface which uses current best practices for usability and design.

    While I was doing research for this article, I came across this quote about linguistic cultural extinction which is quite relevant to Perl’s current situation:

    On a larger, less methodical scale, linguists agree that the single most important step towards ensuring a language does not disappear is the fostering of favorable conditions for its speakers to employ the language and to ensure that it is taught to their children. Approaches to Conservation

    Perl, as it currently stands, is not fostering those favorable conditions. It needs to modernize its presentation and approach to make itself more approachable and appealing to a new generation of programmers.

  3. TPF should fund training, outreach and community building to the same level as language development (if not more). According to The Perl Foundation‘s own mission statement, it is “…dedicated to the advancement of the Perl programming language through open discussion, collaboration, design, and code.” At no point does it mention community or training as a part of its raison d’être and I find that to be a grave oversight in desperate need of correction. A language is only advanced so long as it thrives. A language cannot thrive without practitioners and a strong community to support them. TPF is dropping the ball here, allowing the language they’re sworn to advance to founder in a morass of indifference and insignificance. It does not matter how many grants they hand out for language improvements which no one is going to use. As the effective figurehead of the Perl community, I feel only TPF is in a position to make the sort of changes necessary to drag Perl back into relevance and to allow it to grow and thrive, and these changes are not predominantly technical in nature. TPF should take the reins it recently appears so reticent to accept and both guide and grow the community through outreach and grants based upon measurable milestones. TPF: Accept responsibility for increasing the ranks of Perl programmers and the overall perception of our language within the programming community. Advance our language in ways which matter (read: not solely technological) and do it now before there is nothing left to advance.

So, here’s the thing.

You don’t have to agree with much of what I say above. But agreement isn’t necessary in order to think about the issue. And that’s what I urge you to do: start thinking about this as a legitimate issue. Even this cursory look at the current landscape of Perl usage and the Perl community shows that its aging and dwindling numbers are worthy of concern. I repeat: We are becoming the Shakers of the programming world and if we do nothing to change this then we will end up the same way they did.


Postscript…
During the process of writing this article I did a lot of research into cultural extinction. The concepts there are disturbingly applicable to what the Perl community is facing now. To end, I’d like to share a particularly relevant quote from Francis X. Hezel:

The key to cultural survival, then, is not purely conservatism—hanging on tightly to all that we have received in the past—but a genuine sense of dynamism and a readiness to adapt to a changing world. Strategies for economic development that entail change, therefore, may be seen as ways of promoting survival, material and cultural. Some of what we have understood in the past as either-or dichotomies ought to be re-examined in the light of this new model of culture.

The Rising Costs of Aging Perlers: Part 2, The Business

At this point you’re entirely justified in asking, “So what?”

The fact of the matter is, the lack of junior programmers is a very big deal from a business point of view, both to companies which already use Perl and those who might otherwise consider it. This directly and strongly impacts the bottom line of any Perl-using development shop.

According to Payscale.com, in San Francisco the median pay for a junior software developer is $66,000. For a senior software developer it’s $111,000. To be honest, we’re in a boom here right now. It’s my experience as a software development manager that each of these numbers is at least $20-$30K too low, but let’s run with the Payscale numbers. It’s obvious that a senior software developer is going to cost a shop a minimum of nearly $50,000 more than a junior developer.

Now consider the structure and needs of your typical software development department. There are a number of tasks which absolutely require the skills and expertise only a senior developer can bring to bear, but the majority of the work most likely can be performed by more junior developers with appropriate supervision. You do not need every member of your team to be senior and, at an extra $50K a head, you can’t afford to do it anyway. That sort of staff expenditure is an irresponsible business practice. However, as unreasonable as it is to expect a company to pay so much more for experience they don’t need, it’s equally unreasonable to expect a senior developer to accept less pay than (s)he has earned through years of training and experience.

Companies in this position, in order to continue using Perl, will have few options available to them. One of those options is to start training all incoming developers to use the language. While this is possible (undoubtedly some companies already do this), it is itself a very expensive proposition, often costing tens of thousands of dollars in training costs, time and productivity. A number of companies may run the numbers on the investment they’d be required to make in training and decide that it provides a much lower return than undertaking the arduous task of rearchitecting the software to use a language where they are able to hire staff (and at a more reasonable rate of pay).

Alternatively, companies which do not yet use Perl may be turned away from the language for similar reasons. The harsh financial realities of running a business—rather than technological merit—will end up dictating which programming language a company will use for their product. Selecting a language for which you can only hire senior developers is a very bad business practice, which leaves Perl in a poor position from a business point of view.

From where I’m standing, it does not appear as though the Perl community is doing much to correct this issue. As I detailed in my earlier post, in many cases Perl’s new programmer outreach appears fairly crummy if not virtually non-existent. This needs to change before Perl starts to face a cultural extinction. Perl needs to start creating fledgling Perlers to help sustain and grow the language through it’s next twenty-five years. As well, this will add new blood to the community and help diversify the gene pool. The more diverse a community, the better it’s able to adapt to the changing conditions which might otherwise overwhelm it.

A diverse or deep gene pool gives a population a higher chance of surviving an adverse change in conditions. Effects that cause or reward a loss in genetic diversity can increase the chances of extinction of a species. Population bottlenecks can dramatically reduce genetic diversity by severely limiting the number of reproducing individuals and make inbreeding more frequent. Wikipedia page on Extinction

In the final post of this series, I’ll detail some suggestions for avoiding this cultural extinction. Read Part 3.

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

Announcing the Perl Companies project

A month or so ago Jeff Thalhammer and I were chatting Perl over burritos. We got to discussing how many companies were currently using Perl actively and wondered whether there were a list anywhere on the web. We checked. There wasn’t (well, not any comprehensive or modern ones).

Well, now there is. Announcing the Perl_Companies project.

The list was built using postings from the entire history of jobs.perl.org and on that front owes its existence to a prior project by brian d. foy.

There are currently two versions of the list: a CSV file for downloading and manipulation and a Markdown file for human readability. The original data whence the list was drawn is also available in the repo.

I believe this list is going to be incredibly useful to the Perl community. It can be used as a source for job hunts, sponsorship requests, market research for new products, or put to any number of other purposes. If nothing else, it’s fun to browse.

Admittedly, this list still has some problems (*cough* deduping *cough*). Sure, there’s room for improvement, but it’s still a damn sight better than the diddly squat we had before. Plus, thanks to the wonders of open source and Github, we can all collaborate to build upon this good start. So bring on those pull requests. Open some issues. Let’s make it better together.

Rename Perl 5? Marketing: UR DOIN IT WRONG

Earlier this month Ovid once again raised the question: Should we rename Perl?”

As usual, the question sparked a flurry of opinions on the matter. Most of the discussion occurred in the comments of Ovid’s original post.

I’m not here to chime in on that question. Whether the name should change or should not, what it should change to, when it would happen, these questions are all closed. RJBS has said there will be no change right now and that’s that. He is driving the Perl 5 bus right now. If he says the name is not changing then that’s good enough for me. Discussion closed.

No, I’m not here to discuss that matter. I’m here to point something out:

Damn, team. That was some dismal marketing I just witnessed.

Just what exactly is the problem you’re looking to solve here? Where are the metrics to support that? Whom are you looking to convince? How will the solution be rolled out? Who’s going to do the work? What’s it going to cost? How will you know when the work is done? How will you know whether it’s working?

None of the people participating in the conversation would ever consider releasing a small patch to a CPAN module without first having a complete set of tests for it. Yet the same people seem to have no problem changing something as fundamental as the name of the language without performing some sort of market research and testing.

Despite the reputation its earned, marketing is not a crap shoot. A successful marketing or branding campaign requires just as much forethought and carefully considered execution as a good piece of software. You don’t just throw it together, put it out there and hope it does what the target audience needs. It could be impossible to recover from the damage caused by rash branding decisions.

I would welcome nothing more than more discussions about whether Perl 5 should be renamed. But I would like them to be as well researched and considered as any other change which would be made to the language itself.

Improving Perl’s New Programmer Outreach

I don’t think I’ve ever seen so much demand for programmers or programming training. In an economy that’s still recovering from the recession, the remarkably low unemployment rate among programmers plus the relatively high rate of pay is drawing ever more people to the industry.

You hear it over and over again: “I want to learn to program but need help to start.” If you search on the web you can find an abundance of “learn to program” opportunities. Most of the offline/meatspace ones use Java, Ruby or Python as the language of choice. I found none that use Perl, which I see as an opportunity the Perl community should pursue.

The availability of more beginning programming training provided in Perl would be beneficial both to the trainees and to the Perl language and community. As languages go, Perl quite easy to learn (or at least no harder than the popular alternatives). The basic programming concepts are fairly straightforward in syntax, sigils can help a neophyte to keep her data structures straight, and CPAN can enable a beginner to produce remarkably functional code in a limited amount of time. This leads to higher student confidence, since (as we’ve all experienced), creating something that works makes you feel good and want to keep learning more.

Perl, for its part, could benefit by using this training as positive propaganda to help dispel the negative brand image it’s developed and been unable to shake for all these years. Pundits and wags on Stack Overflow, reddit and elsewhere enjoy repeating the chestnuts that Perl is dead or is good only for scripting and parsing text, not for “web scale” projects. An influx of new programmers—trained on Perl and in the best practices recommended and used by modern Perl developers—would help to dispel these misconceptions, even if afterward they went on to use other languages.

As an example of an organization I think really does training right, I direct you to the San Francisco Ruby community. SF Ruby puts on a training session at least once a month. At least one of these, admirably, is focused on teaching women to program. In addition to training sessions, SF Ruby also organizes several hack nights each month, providing ample opportunities for newbies to mingle with more experienced programmers and get personalized assistance.

Now, in comparison, I’m going to pick on my local Perl Mongers group. SF.pm. Before I start, please be clear that I use SF.pm here only because it’s convenient and—as you’ll see in a moment—provides a dramatic comparison. The SF Perl Mongers are a great group of people. This is not intended as a slight against them or the organization. I simply wish to show that the Perl community could increase its outreach to new programmers.

I’ve compiled data on the number of training and hacking sessions organized by SF Ruby and SF.pm in 2012. All data is drawn from the Meetup calendars for each organization. A ‘training’ event is defined as anything focused on helping people learn the language and includes beginners’ hack nights, study groups, API office hours and more formal training sessions. A ‘hacking’ event, simply enough, is anything with the word ‘hack’ in the title.

Month SF Ruby SF Perl Mongers
  Training Hacking Training Hacking
January 1 5 0 0
February 3 9 0 0
March 1 6 0 0
April 3 7 0 1
May 2 6 0 0
June 4 5 0 0
July 8 4 0 0
August 7 6 0 0
September 4 5 0 0
October 2 5 0 0
November 2 5 0 0
December 3 3 0 0
TOTAL 40 66 0 1

The numbers, as you can see, are staggeringly different. That said, there is also a huge difference in the size of each of these communities on Meetup.com. SF Perl Mongers has a membership of 380 people. SF Ruby has 5588. This naturally affords SF Ruby more resources to provide these events but does not, I believe, excuse SF.pm for providing almost none.

SF Ruby deserves everyone’s attention and commendation for all of their work in training and outreach. It’s a model which Perl should look to emulate. While the resources of my local Perl community may not allow it to scale to the level of the 44 training and 66 hacking events put on by SF Ruby in the last year (nor do I think they should attempt to do so), I would hope those resources could allow for at least one training session every month or so and a newbie-friendly hack session every few weeks[*].

If Perl wants to show people that it’s alive and well it needs to be more active in public ways like this. Outreach to help introduce novices (especially minorities) to programming would go a long way toward dispelling the out-of-date image the tech community has of the Perl language.


[*]: Full disclosure: I am guilty of not offering to help SF.pm in this effort. This is an oversight I hope to correct. This post is the first step in that process. Back to reading.