I spent the whole of Wednesday at an excellent Perl course organised by UKUUG. I’ve always maintained that a significant benefit of any training course is simply being forced to take the time out of the normal day-to-day work and focus on one thing; having expert guidance on exactly where to focus during that time is a bonus. A big bonus in this case, as tutor Dave Cross‘s lucid and engaging presentations showed me lots of things that I’d been doing really badly and inefficiently for years (and how to fix them!). I said as much to him, and he seemed quite taken aback: he hadn’t meant to make people feel bad, he protested. I meant it in a wholly positive sense, though; it was as if I’d spent years trying to tighten screws with the point of my Swiss army knife or the edge of a coin and then someone had finally given me an electric screwdriver. That’s a good thing.
The thing is, often it’s obvious when you’re doing things inefficiently (if you’re putting in a lot of effort for little gain, or finding yourself doing the same things again and again) but much less obvious how to fix this. There are lots of tutorials that teach you how to learn things properly from scratch; and if you’re actually getting errors, it’s easy to search for them and find out how to fix them (or at least make them go away, which isn’t always the same thing). But, assuming you don’t have time to start again from scratch (and, in a particularly frustrating vicious circle, if things aren’t actually broken then it’s hard to justify taking the time to fix them, particularly since if you’re doing things inefficiently you probably don’t have lots of spare time in which to sit down and learn how to do them properly…) it can be incredibly difficult to see how to get from where you are to where you want to be: a classic case of “I wouldn’t start from here”. It’s as if you’d learned a natural language in fragments from a dictionary and never had a chance to talk to a fluent speaker: you’d feel sure that “By what sequence of steps in what sequence of directions can I walk in a short amount of time from the place where I am now to the place where I can catch a train?” wasn’t the best way to ask your question, but no amount of looking up “direction” or “place” or “what” or “where” in a dictionary would be likely to get you to “What’s the quickest way to the station from here?”
I won’t try to recap everything that was taught in the course (the slides should be available online soon, and I’ll add the link here when they are) but the DBI, Template::Toolkit and DateTime sections covered about 80% of the Perl I write (and could probably reduce the number of lines of code by half!), and the Testing section (writing unit tests with Test::More) covered about 80% of the Perl I should be writing, hem hem. I thought the Object Oriented Perl section would be the hard bit (I’ve never really done any object-oriented programming — cutting and pasting bits of other people’s Perl without understanding it doesn’t count!) but one of Dave’s slides made more sense of OOP than anything else I’d tried to read about it so far. By the time we got to a quick overview of Moose, I was itching to go and rewrite every bit of code I’d ever touched (there never seems to be time because of the day-to-day bug-fixing, firefighting, and the million-and-one other things that always need doing, but I was seriously considering taking two weeks’ holiday to rewrite it all in my so-called ‘spare time’).
And as if all the geeky joy of learning how to do things more efficiently and elegantly wasn’t enough, the course also included a short digression about badgers! As some of my readers may know, I have a bit of a thing about badgers, so I’m delighted to learn that it was specially requested by the author as the cover animal for the Template::Toolkit book (which I do own, and no, the badger wasn’t the only reason I bought it). Maybe not everything in black and white makes sense, but a hell of a lot of things in Perl seem a lot clearer than they did before.