That doesn't look work-related...

Tired of being a Perl script-kiddie? There are three things you must start doing with your code.

• Use version control
• Write tests
• Create distributions

You say, "No need to waste my time, only people who work in teams need that."

• Guess what, if anyone besides you will ever use your software OR its output, you're working on a software team.
• In 3 months when the boss says, "Hey, can you run that analysis again on the new data?", you will look at the code and say "Who wrote this?". Once again, you're working on a software team, and wondering who hired that one guy anyway.

Version control

The pro devs here will say, why is he even talking about this? I'm addressing those of us who have a 500 line script in a directory called 'stuff/myscript/myscript2'. There's no excuse anymore, for individuals, not just teams, not to version control their software. Use Google Code, Github or any free service and start learning the drill. You've experienced the blessing of version control if you've ever pushed the up-arrow at the command line; why not apply that to your entire personal codebase? I will discuss this more in an upcoming post.

Write tests

You already write tests. You give your script some file and see if it borks. You set some variable in the debugger (Perl has a built-in debugger, some other post...), and see if you get the right answer. What if you could capture those in code and run them whenever you want - say, when you add some new function or option, and make sure that the answers are still right? What if you could do this without retyping from your lab notebook? This is what writing software tests is about. Modern Perl provides excellent support for creating and running automated tests in Test::More and related modules. More on this upcoming.

Create distributions

Let's revisit the 500 line script, and your boss asking you rerun it on the new data. If the 30 subs were organized into modules, you would have better luck identifying what you need to modify. Put those in a directory always called 'lib', and you don't have to remember stuff/myscript/myscript2. Write a script that's a true script-- that glues together the functional components in the modules. Put it in a directory always called 'bin' or 'scripts'. Already you can maintain your code better = save yourself time and stress. Now, the best part is that Perl (in the form of ExtUtils::MakeMaker or Module::Build, e.g.) understands, enforces, and even can automatically set up this structure for you. Built in are facilities for running those tests you've written, installing your script and its modules in Perl-standard places, and packaging the whole thing. You're not only organized, but you can share your work instantly, and set it up anywhere. More upcoming.

There is a learning curve here, no question. But you will obtain immediate benefits. Better than this, however, is that the change in perspective you get will allow you to see and realize more potential in your work. You will be able to collaborate more ('Oh, I've got a module that does that.'), and have more to offer ("I'll send you the distro; type make, make test and make install and you're all set"), and gain more glory ('Thanks, you rock!'). You'll also be held accountable ('But dude, it crashes on binary files'), you can easily make it good ('Quick fix and a new test; here's the distro'), and your future quality will improve ('Oh, I've got an improved module that does that...').

Even better than this, you will start to see yourself as part of the community of developers and get the itch to get involved in it, to everyone's benefit.