For most of last week I was out of London running three days of Perl training for… well, I probably shouldn’t name them, so let’s just call them a well-known British educational establishment. The photo above is a big clue.
The people I was training were IT support staff; the people who keep many of the organisation’s IT systems running. They were a mixture of sysadmins, DBAs and developers. What they had in common was that at least part of their working life is spent looking after systems that are written in Perl and they had never before taken any formal training in the language.
In my experience, this is a pretty common situation. Because Perl is “just a scripting language”, I often come across people who are responsible for Perl programs but who have never been taught how the language works. Managers often seem to believe that people will absorb Perl knowledge just by being exposed to the code. And, of course, that’s partly true. On the face of it, Perl isn’t particularly hard to understand. If you have a grounding in other programming languages in the C/Algol family or you know a bit about Unix tools like awk, sed or Bash scripts you can certainly be productive in Perl.
But not as productive as you could be if you actually took the time to learn about the language.
In many ways, this is one of my favourite kinds of training. The course ran for three days and was adapted from my Introduction to Perl and Intermediate Perl courses. It’s a lot of fun taking the attendees right back to basic Perl and slowly building up their knowledge. The three days is an almost constant stream of “light-bulb moments” as students connect the concepts that I’m talking to code that they’ve seen in the systems they maintain. While it’s true that you can maintain a Perl program just using knowledge that you’ve worked out from reading the code, you become a lot more effective when you understand more of the underlying concepts.
On the other hand, it can be a slightly frustrating kind of course to run. In many cases, they code that these people are maintaining was originally written by people who had never really understood Perl and it has been maintained for years by people with even less knowledge of the language. So the code is a long way from the modern Perl that we’d all like to spend our days working on. This is often going to be monolithic code bases with no sign of a “use strict” or “use warnings”. Maintenance of this code is often seen as a low priority task that is only undertaken when changes are vital and it’s unlikely that anyone could ever take the time that would be required to raise the standards of this code.
But, nevertheless, I feel that over the last few days I have increased the average level of Perl knowledge in the world. There are eight more people who know how Perl references work (and why you might use them). That has to be a net win. And the fact that the organisation was happy to pay me to run the course must be seen as a positive. It means that they value the effectiveness of their developers.
I often hear people worried about the lack of people starting to use Perl. I’ve lost count of the number of developer managers or CTOs who have cited the lack of available Perl talent as the reason they are moving their development to other technologies. But there is another option. Employ people with good general Programming skills and run training courses that give them the more specific Perl skills that they mean.
I know a good trainer who would be happy to help!
