"This will sound silly, but it only recently dawned on me that a code library isn't just for finished, polished code..." Hmmm...the thing to remember about putting code in modules is that once you start to rely upon that code you will become afraid to change it unless there are tests to somewhere to support changes.

package Foo;

sub returnANumber {
    return 66; 
}

package FooUser;

use Foo;

if (Foo::returnANumber() < 82) {
  # do something
} else {
  # do something entirely dependent upon returnANumber being an intege
+r > 0 && <= 100...
}
[download]

Recommendation #1 is to write tests and package them alongside your scripts to ensure that one travels with the other. Or you could just store them inside a DATA segment at the end of a script...

#!/usr/bin/perl -w
use strict;
use Getopt::Long;

my ($aa, $bb, $diagnostic) = (undef, undef, 0);

if (@ARGV){
    GetOptions('aa=s'=>\$aa,
           'bb=s'=>\$bb,
           'diagnostic'=>\$diagnostic);
}

if ($diagnostic){
    my $test = '';
    while(<DATA>){
    $test .= $_;
    }
    eval($test);
    die 'Ran tests. Done.';
}


1;


__DATA__

use Test::More qq~no_plan~;

ok(1==1,'basic');

1;
[download]

"Then get right back to work. I no longer have to worry about whether my tests are including the right path to my modules..."

Unfortunately this is the problem I run into all to often. Developers and support people do all of the right things...they write tests, they modularize their code; they store things in separate libraries on a hard drive. All good. Problem: what happens if you take another job?

I get it. People say, 'well...I wrote that stuff to facilitate my work; the next person is just gonna have to figure out my stuff or cook up their own...' Yep. And the next person shows up on Perlmonks with 30 questions about how X, Y, and Z works.

You specified your workflow and even enumerated the points. Here is where I think it falls short:

1. Stop writing code and start writing down what you want code to do (use psedocode/perldoc, whatever). Then look in CPAN for modules that do what you want. Ask if they are recently modified or easy enough for you to understand that you can modify them yourself it they break. Then actually use the modules.
2. Add your own tests. You are on the right track there.
3. Everything, everything, everything must go into some form of version control that is backed up on some redundant data storage away from your machine. No exceptions whatsoever. That includes scripts and utilities. When you are away from work you are likely learning. When you learn you get some code. When you return to work you'll try to remember that code. Guess what...you lost it. That is why even your personal stuff must follow this rule. The company's stuff is company property. If you didn't back that up you misappropriated company resources.
4. Always periodically rethink our workflow. I check my history file all the time kind of like how a Russian submarine does a 'crazy Ivan' to see what I am doing repeatedly. It is odd how we don't realize that we do something that could be scripted saving us cumulatively hours per month and weeks per year.

The last one is a bit tricky because it depends a lot on the industry you are working in. If you are in some engineering firm you might find that there are numerous conditions that no one has thought about that will force you to refactor code a lot. In that case you might find you have to keep your code in some smaller pieces that can be mashed together at some later point.