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.

Moving On From The Errors of GitHub and The Ada Initiative

The Story So Far

  • On March 15th of this year, Julie Horvath–a well-known and -respected advocate for gender equality in technology–left her job at GitHub. It caused a bit of an uproar among technologists on the internet.
  • On March 16th, GitHub issued a statement that they were investigating the allegations and that the accused parties were placed on leave or banned from the company’s offices.
  • On April 21st, GitHub issued a statement of findings. This one declared that the investigation was complete, that it had found no evidence of wrong-doing (but did of mistakes & error in judgment), but that the accused parties had left the company regardless.
  • On that same day, Julie Horvath responded to the announcement.
  • On April 23rd, The Ada Initiative issued a statement that they were severing all ties with GitHub as a result of the situation.

Before I dive into the rest of this post, there is one fact which I would like to make crystal clear:

A hostile environment–work or otherwise–is NEVER OK. If you are in an environment which makes you uncomfortable, please immediately do whatever is necessary and legal to get yourself to a safe place. If you witness a hostile environment, speak up. This is everyone’s problem and we all have a responsibility to make sure our friends, families, colleagues, and fellow humans are safe.

Therefore I fully support Julie’s decision to quit GitHub. She states that–for many reasons–it was a hostile environment for her. Staying was not an option. She had the awareness to recognize this and the courage to walk away.

This is not an article about Julie. This is an article about what happened after she left.

Shit Happens: GitHub Edition

When GitHub released its statement of findings on April 21st, the internet lost its shit (as it is wont to do), embroiling itself in its usual under-informed tea leaf reading. Some people expressed a desire to forsake the company’s services. Many more decried the company for it’s “non-answer.”

I confess that I, myself, am dissatisfied with GitHub’s statement of “findings.” In my opinion, it is a legalistic and opaque answer to the questions its community has wanted and needs resolved in order to mend damaged trust. This is counter to the culture of openness which GitHub has fostered. It has shared none of the details of the investigation, instead asking an already skittish and suspicious community to just take it at its word. This was a clumsy (but perhaps necessary) move on their part. GitHub either did not know or entirely disregarded how this sort of a statement was going to further damage their reputation.

Shit Happens: The Ada Initiative Edition

One of the most visible and potential damaging reactions to GitHub’s statement of findings came from The Ada Initiative, when they publicly denounced GitHub and dissolved their partnership with the company.

While I respect the mission of The Ada Initiative and believe they have nothing but the best interests at heart, if GitHub’s statement of findings was clumsy then Ada Initiative’s reaction to it was a pratfall. Rather than taking this opportunity to further its mission by assisting a company struggling with turmoil induced by alleged gender-insensitivity, Ada Initiative instead chose an emotional and reactionary path which removes repository access for underserved and at-risk individuals.

The Ada Initiative statement declares that “The sum of these events make it impossible for Ada Initiative to partner with GitHub at this time,” but it does not actually detail the umbrage which it takes against “these events.” The entire judgment call is left as an exercise for the reader, under, one must imagine, the false assumption that everyone who reads the statement both now and in the future will grok the wrongs performed here.

As well, Ada Initiative canceled their partnership with GitHub but did not tell us either what steps they took to correct the offenses prior to the cancellation, nor what they request of GitHub to mend the wounds. All we are told is “We will not accept future sponsorships from or partnerships with GitHub unless the situation changes significantly.” This is hardly a constructive or actionable statement.

While The Ada Initiative is definitely taking a strong stance here, it is doing so by causing harm to the community it is sworn to protect and uplift. Rather than assisting a company to learn how to make a safe workplace, it has turned its back on it. The Ada Initiative is willfully ignoring an opportunity to make a positive difference.

Moving Forward

There are two things which ought to happen for everyone to move forward and make something good and productive out of this otherwise ugly situation:

GitHub needs to be more open.

I suspect that the GitHub statement of findings was as legalistic and opaque as it was because there may be some potential pending legal proceedings. This would tie their hands as far as what they are allowed/or advised to say by their counsel.

However, if they wish to mend their growing poor reputation, they still should make an effort to be more open about what has and is going on over this issue. They should say as much as possible, and then also tell their community what they cannot discuss and why. Stop the weaseling, start the openness.

Part of this openness must be a discussion of what they are doing to make GitHub into a safe environment for all members of the company, acknowledging that past efforts–however well-intentioned–may have failed and detailing how they hope to change the process and the culture.

The Ada Initiative needs to work WITH GitHub, not against it.

I recognize that Ada Initiative is trying to protect the community and I respect that. However, they should consider making a statement of concern but holding off on their cancellation of partnership with GitHub. Instead, they should consider reaching out to GitHub with a cooperative plan to help improve gender/minority sensitivity in the company. That would be much more in line with the mission of the organization and more productive than walking away in a huff without, from the available evidence, trying to work things out with GitHub first.

I leave on this brilliant and insightful tweet from Nicole Sullivan:

Let’s all please keep that in mind rather than immediately jumping to the worst possible reactions. These organizations are trying to do the right thing. They’re just making mistakes along the way. It happens. Let’s make those mistakes productive rather than cut them down for making them.

A CEO is a Leader: The Recent Mozilla CEO Kerfuffle

Experience comes for free. Learning takes effort.

On March 24th, Mozilla announced that they had named Brendan Eich as CEO.

On April 3rd, Brendan Eich, after much internet uproar over his $1000 donation to disallow same-sex marriage, stepped down as CEO of Mozilla.

So.

WTF happened here?

First of all, some facts…

  • FACT: Brendan Eich is well within his rights to support his personal beliefs through financial donations. Furthermore, that he did not back down from his position shows a strong sense of integrity. He was correct to do what he did. (ed. note: I very strongly disagree with Eich’s position on this matter and share Rarebit’s disappointment, but defend to the death Eich’s right to express his opinion.)
  • FACT: Team Rarebit and others were well within their rights to express outrage at the appointment. They were correct to say what they did.
  • FACT: Yet others were well within their rights to defend the appointment. They were correct to say what they did.
  • FACT: The Mozilla board of directors appointed Eich because they truly believed they were doing what was best for the organization. They, however, erred.

What appears to have happened is that the Mozilla board of directors misunderstood the role of CEO in an organization, particularly in a non-profit and mission-driven organization.

A CEO isn’t merely a leader; a CEO is a Leader. In a non-profit and mission-driven organization, a CEO is a LEADER. LEADERship extends far beyond merely setting technical and strategic direction for an organization. It includes becoming the very public face of everything for which the organization stands.

As an organization with a brilliant track record for supporting diversity and freedom of all sorts, Mozilla could not have a CEO who was on public record as opposing what a great many people see as a civil right.

Undoubtedly, as CEO, Eich would have continued his admirable track record of not allowing his personal political and religious beliefs to impact his professional performance. He had, after all, been CTO of Mozilla almost since the beginning and from all appearances his personal beliefs did not affect that performance. But being CTO is not being CEO. A CTO is responsible for setting and delivering the technical vision for an organization. One’s opinion on social issues is unlikely to come up in such a role.

A CEO, on the other hand, is responsible for setting and delivering the overall vision for an organization. This vision includes not only business strategy but also culture and mission. As such, a CEO’s beliefs must completely track with those of the organization which they lead. This is part of what makes the hunt for a new CEO so challenging. While a CEO’s personal beliefs may not affect the easily quantifiable parts of their job, (as we have now seen) they can have untold effects on responsibilities which, while more fungible, are no less important.

If there is any blame to be placed here, it is with the Mozilla board for not realizing this fact. They were aware that Eich had taken a public stance on an issue which could be seen as contrary to the Mozilla culture, yet they apparently did not see this as a potential problem for acceptance of him as a CEO. It was this ignorance and lack of awareness which led to the recent drama. Thankfully ignorance is curable. And undoubtedly Mozilla has had an effective dose of its medicine for this ailment.

There is no doubt in my mind that Brendan Eich has the experience, the vision, and the competence to lead Mozilla for years to come. He has proved that with his many years of experience as CTO. But from a cultural point of view he was, unfortunately, damaged goods. As such, the Mozilla board of directors should have refused delivery of the CEO package. If they had, they could have retained him, his passion for the open web, and his talents to help further the Mozilla mission.

Instead they are left with a learning opportunity and without the contributions of a founding father. Thankfully, the organization is populated by thousands of brilliant and insightful human beings. Mozilla will recover from this mistake, and even while recovering it will continue its work toward the open web. Those of us who agree with and believe in this mission should, now more than ever, support Mozilla. Let’s turn this experience into learning and continue to move forward.

Dear Mister Independent Recruiter,

Hello.

I saw your resume on the web and am writing to see if you or anyone that you know who may be interested in the following position in $city. It is with a top $industry startup, located in a gorgeous location of $region, pays top dollar, great benefits, options and bonuses.

You will be working on top tier financial technology with a great team! If there is any interest, please email resume to $email_addr.

Best Regards,

$name
Independent Recruiter

Oh. How…common. My response:

Dear Mister Independent Recruiter,

I manage software engineering departments. I also do technical management consulting. I also do independent recruiting. What I do NOT do is DBA. Which you’d have known if you’d even glanced at the resume you claim that you saw.

You are not an independent recruiter. You are little better than a spammer. Your email is the sort of ignorant and blind outreach which gives legitimate recruiters a bad name.

Please stop harvesting resumes and then sending emails based on little more than the simplest of keyword searches. Take just a moment to look over a resume before mailing someone. Qualify your damn candidates. Stop spamming tech professionals. Start recruiting them.

Five Tips for Better Cover Letters

A question from a friend for whom I consult on occasional career coaching matters:

What’s your take on cover letters: make ‘em short ‘n sweet, or go to town and try to sell yourself there rather than in the resume?

To answer my friend’s question: You should always be trying to sell yourself, both in your resume and in your cover letter. I’ve already had a brief discussion on how to improve your resume. Now here’s the companion piece: some tips to improve your cover letter.

Cover letters are a surprisingly polarizing topic among those who do hiring in technology. Some people find them to be a waste of time and will never read them, instead relying purely on a candidate’s resume. Some companies don’t even make provision for submitting a cover letter in their online application processes.

Naturally, your resume is an important document in the job hunt process. It tells your prospective employer what you’ve done and what you know. Similarly, your portfolio (Github, etc.) shows the hiring manager the how of your career: how do you implement the code or the design or the document?

As for myself, I require cover letters from all applicants and here’s why: I hire people; I don’t hire shopping lists of tech skills. While, yes, your skill set is important to me and I will be scouring your resume for every possible nugget of gold, I’m far more interested in who you are, what you can do for me, and how you interact with others. I can teach anyone how to use our technology. I can’t teach someone how not to be an asshole. Your cover letter is going to tell me who you are and, importantly, why I should care. What problems are you going to help me solve? Without that cover letter I have no insight behind the resume or code sample and little motivation to learn more. You’re just another faceless resume in the stack.

Now for those tips I promised…

Customize!

If your cover letter arrives on my desk and is obviously a cut and pasted template, I’m less likely to follow up on your application. To me, it doesn’t feel like you want this job; you’re just looking for any job.

Which isn’t to say you should necessarily rewrite a cover letter from scratch for every job to which you apply. It’s OK to have some sort of scaffold as a foundation around which you build individual letters.

Each of those letters must be customized for the position to which you’re applying. Do your research about the company and position and incorporate that into the letter. Some examples of what you could include:

  • What problem are they trying to solve? They wouldn’t be hiring if they didn’t have problems to solve, so how can you help them?
  • Who is the hiring manager? Address them directly in the salutation of the letter. Decades of direct marketing research show that personalized messages are more likely to be received favorably. Plus, going this extra mile to address your potential manager reflects well on you.
  • What are the company’s values and mission? If you agree with these things, incorporate them into your letter. Naturally, if you don’t agree with the values and mission you should not apply for the position.

It’s not about you; it’s about me

I, as the hiring manager, have needs. I have deadlines to meet and bugs to fix and code to refactor and rearchitect and people to hire and mentor and meetings upon meetings to attend. How are you, $applicant, going to make my life easier?

What many applicants forget is that as a manager I really want to hire you. I need to get the right person in the door and productive so my team can keep moving forward and hitting deadlines. If your cover letter tells me how you will help us do that? I’m already predisposed to like you.

But, really, it’s about you

Your cover letter is your opportunity to show the hiring manager that you’re going to be an asset to the team. You’re skilled, sure, but you also work well with others. You’re well-spoken. You’re witty. You support the mission of the company. You’re going to join the team and make things better for me and here’s how. Tell me who you are and why I should care.

Predict and elucidate

Sometimes when writing your cover letter you must channel your inner Carnac, answering questions before they’ve even been asked. After reviewing your cover letter and resume, the hiring committee may be left scratching their heads over some subjects. This head scratching implies effort on their part to discover the answers. These people are quite busy. If there are other candidates who initially appear as qualified as you but whose applications do not leave so many question marks hanging in the air, your resume will not be put in the short pile. However, if you predict the most pressing questions of the hiring committee and provide the answers up front in your cover letter, it can make all the difference. Some examples of questions which your new team might have when reviewing your application:

  • You haven’t been working for a while. What have you been doing in the meantime?
  • This job is based in Austin, TX but you’re in Portland, ME. Are you looking to relocate or work remotely?
  • You’ve spent the last ten years as a software engineer. Why are you applying for a position as a tech writer?

Form follows function

Coco Chanel once said, “In order to be irreplaceable one must always be different.” Don’t pay attention to those job hunt books you get from the library. They’re wrong: there is no rulebook for the format for your letter.

Your cover letter should reflect your personal style as well as the style and culture of the organization to which you’re applying. Most often, that will be a basic letter in which the content speaks for itself. However sometimes it may make more sense to stand out more. Perhaps a “letter” written in the form of a stack of calls to the company’s public API. Maybe a link to a website you designed solely for this purpose. Animated cat GIF? Um…OK, but only if that’s what makes sense.

Always remember: Don’t be clever purely for the sake of cleverness. The goal of your cover letter is to show the hiring manager who you are, what you can do for them, and turn heads in the most appropriate way. No one likes a cocky show-off.

Announcing Documentation for the Internet Archive S3 API

Back in 2011 I was hired at Internet Archive to develop a digital archive service for memory institutions. Unfortunately, after six months the project was scrapped (along with my position).

In the last month of the project, while waiting for the go-ahead to keep moving forward, I undertook documenting the Archive’s S3-like API. The project was going to need this API and, to be entirely frank, the existing documentation is laughable (sorry, IA team, but it’s a spade). My API doc was nearing completion about the same time the project was axed, but it was never published and ended up collecting dust in my Dropbox.

Fast forward a couple of years. Now, as a co-organizer for San Francisco Perl Mongers, I stream and record as many of our events as possible. Afterward, I upload them to our SF.pm Collection on Internet Archive because I believe in their mission of “Universal access to all knowledge.”

In the process of that uploading, I found myself referring frequently to that old in-progress API doc. Finally it dawned on me that I should probably share the damn thing so others could benefit as well.

It took a lot of cleanup and editing, but now I present to you:

The Internet Archive S3 API Documentation.

This API will allows for the creation and maintenance of items on Internet Archive. It also allows uploading of files to the item and, if the item has the appropriate metadata values, Internet Archive provides online viewers for this item content. For more information, have a look at the API Summary & FAQ.

It’s my hope that this documentation will allow many more user groups, individuals, and institutions to preserve and share their content via Internet Archive (for free, might I add, but donations are always welcome). I think of it as a grassroots continuation of the stillborn Digital Archive Service I once worked to produce.

NOTA BENE #1: If you have a lot of content to upload to the Archive, please be a good citizen and contact Internet Archive to coordinate with them. The crack IA Collections department will help the process be as smooth as possible.

NOTA BENE #2: This is not an Internet Archive document. They are not responsible for any shortcomings it may have. Please see the support page for more information about that.

If you use this document (and I do hope you will) and do find any shortcomings, please let me know! This doc is in Github specifically because it makes it so easy to collaborate on this sort of thing.

I’m in the Market for a New Job

After over a year working on my own projects, I find I really miss leading and working with a team of good people. Working alone has its advantages but isn’t as fulfilling for me.

Therefore I’m once again throwing my hat into the ring. I’m looking for a full time job and would love to hear about great opportunities and teams which could use my help.

For those who don’t know, here’s little guidance about what I do:

  • I used to program but no longer do so and would prefer to keep it that way. While I can program I do not enjoy it much. I have always found it much easier/more pleasant to read code than to write it.
  • My strengths lie in the realm of management of technical people and projects. I thrive on building and helping incredible teams of geeks to accomplish amazing things.
  • I understand business, marketing, and technology and enjoy exploring the intersections between them.

What I am looking for:

  • I would enjoy performing any of the following roles (most of which I have done previously in my career):
    • VP/Director/Manager of a software engineering team or department
    • Technical Project Manager
    • Community Manager
    • Developer Evangelist
  • While I currently live in San Francisco, after five years of saying, “Imma gonna move to Portland!” I’ve finally decided to follow through on the statement. Therefore it’s required that the job either is based in Portland, Oregon or will allow me to work remotely.
  • I would be beside myself with professional glee if I am able to find a position with a company or organization which is friendly to open source/data/access/etc.

For more information, have a look at my resume.

Need to know even more? There’s always my website.

Know of a position or have more questions? Feel free to send me email at `resume` at the $domain.$tld of this webpage.

I look forward to seeing what sort of amazing opportunities are lying in wait. Allons y!

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.