Learn from the wisdom (and lack thereof too) of those around you who have more experience programming in Perl.

Notice that I did not say those who are older than you, have more seniority or hold a supervisory position over you. In some cultures this is a hard concept to grasp. Give that "kid" a chance, she might teach you a thing or two about proper programming.

As for the "lack thereof", you will find out eventually that some people just do not get it even after programming in Perl (or any other profession for that matter) for many years. Learn from their mistakes as well as your own.

There is a time and place for trying out your recent Perl discoveries.

Learning is a good thing especially when you are learning more about Perl. You should practice what you have learned as often as you can so that you retain the knowledge.

That said, code that is destined to be released into production is not the place to practice your new found knowledge of hash slices.

Perl idioms are our friends.

Why say

# take the values in @array and use them as a hash slice to make all o
+f the values 1
@hash{@array} = (1) x @array;
[download]

when

# take the values in @array and use them as keys in %hash, incrementin
+g the values associated with said keys by one
for (@array) { $hash{$_}++; }
[download]

and

$hash{$_}++ for (@array); # same as above only with the for at the end
[download]

are more widely understood? (See foreach loops.)

Whitespace is too.

This (shamelessly stolen and slightly modified) line of code

print+map{sprintf'&#%d;',$_}unpack'C*',$_;
[download]

is just dying for some whitespace (unless of course you really are Writing highly obfuscated code in Perl).

print map { sprintf '&#%d;', $_ } unpack 'C*', $string;
[download]

or even

print map {
  sprintf '&#%d;', $_
} unpack 'C*', $string;
[download]

Double (or even triple) check your data.

I cannot tell you how many times some new code was added that introduced a bug or that I have received a bug fix that was not needed simply because the person was using invalid data.

Remember what I said about idioms earlier? A programmer had introduced a bug when they tried to use the hash slice instead of the idiom. The data (as output by Data::Dumper) looked something like this:

$VAR1 = {
          'YZ0' => undef,
          'MNO' => undef,
          'ABC' => '111111111',
          'DEF' => undef,
          'STU' => undef,
          'VWX' => undef,
          'JKL' => undef,
          'PQR' => undef,
          'GHI' => undef
        };
[download]

When it should have looked like this:

$VAR1 = {
          'YZ0' => 1,
          'MNO' => 1,
          'ABC' => 1,
          'DEF' => 1,
          'STU' => 1,
          'VWX' => 1,
          'JKL' => 1,
          'PQR' => 1,
          'GHI' => 1
        };
[download]

What bug caused it?

@hash{@array} = (1 x @array);
[download]

Note that the closing parenthesis doesn't follow the 1 but @array. The programmer did not check the data that was created. He simply assumed it was correct (which leads me to my next point).

Do not assume anything.

Throughout our lives we make assumptions about all sorts of things like the weather ("I better take the umbrella. Based on the look of those clouds it's going to rain."), traffic patterns ("It's Friday. I better not take the highway or I'll be late for work!"), et cetera. Sometimes we are right and sometimes we are wrong.

When dealing with code and data, assumptions usually mean mistakes. You have the code and the data so why assume anything? (Because most people tend to be lazy and not the virtuous kind either!)

Be lazy but do not take shortcuts.

Do not take the easy way out by assuming your data or code is correct. Do not skip testing things because you would rather be doing some thing else. Shortcuts lead to mistakes which lead to more time spent debugging.

Be lazy in a good way. Make use of the tools at hand (like CPAN) to save coding time and effort. Do it right the first time even if it takes a little longer now. You will save more time in the long run.

Get a "code bear".

I am not sure where I first heard about this technique but it seems to work for everyone. Pick something other than a real person and thoroughly explain the problem at hand. Your "code bear" can be a stuffed animal, a mirror, your pet gerbil or even a picture of Nikki Cox. (You know who you are! ;-) For example, my "code bear" is a stuffed animal that my wife gave me for Valentine's day this year.

The idea is a simple one: completely express your thoughts out loud. Explain the problem with as much detail as you would when speaking with a peer. In most cases, the act of putting the problem into words will get your brain cranking enough to solve the problem without wasting the time of an already overworked (and usually underpaid) co-worker. If you have not figured it out by this point then by all means discuss it with someone who can help.

Use every available resource.

By now some of you are probably saying to yourself, "This guy has put way too many links in this node. He must be nuts!" Normally I would agree with you but not this time. I put them in here to make a point.

How many times have you heard someone say something like this? "I checked my Perl pocket guide but I couldn't find what I was looking for." or "I thought that you could do X with Perl but I can't get it to work. Can you help?"

There is a wealth of information that is only a few clicks and keystrokes away. You do not have to limit yourself to just PerlMonks either. Check out http://search.cpan.org, http://www.perldoc.com, http://www.perl.org (this last one has links to just about every Perl resource you could possibly need), et cetera.

No need to limit yourself to online resources either! Go out and buy some books. Go to the library and check out some books too.