2.3. Behavior

Talking about resources for improving your expertise leads us to our last touchy-feely concept: behaviors. If you have the right attitude and a good set of beliefs, you need to follow up with right behaviors, or, if you prefer, “good habits.” Check these out.

2.3.1. Neatness

Sloppy organization leads to a sloppy mindset, which leads to sloppy code. Never mind how tidy your office is; do you have a bunch of files called foo, tmp, fred, latest, latest2, and so on lying around? Get rid of them or archive them somewhere with meaningful labels. Do you follow a consistent indentation style? If not, copy the style of a good programmer whose code you like until you feel like tweaking it for personal taste. Just be consistent!

2.3.2. Communication

How sure are you of the requirements for the program you're writing? Have you checked with the customer what they mean by the various terms they used? Have you explained to them what assumptions you made in interpreting their requirements?

2.3.3. Experimentation

Time and time again, people ask, “What would happen if I did X?” when they could actually try it in less time than it would take to get the answer (which might be wrong). Don't spend ages trying to second-guess the machine; find out. If there were a fourth virtue in the Perl canon, it would be curiosity. If you're not eager to find out what would happen in some odd situation cooked up by your fertile mind, then cultivate the attitude of curiosity, because people who have it will move along the learning curve much faster than those who don't.

The way to feel comfortable experimenting is to know your boundaries. Many people are afraid of breaking the machine or destroying data. So learn which sorts of actions could do that, and which are safe. Find the safest playground you can. If you have a PC with some spare disk space, you can create extra partitions just for a special version of your favorite operating system if you're afraid of hurting something important. A tool like Partition Magic will make this process easy. Then take something that works, and intentionally break it. Explore all the ways it can go wrong. If you've created a “throwaway” Linux on its own partitions, find out just how hard it is to damage it. After enough of this kind of play, you'll have a good idea of what you can get away with and be much less anxious when you're debugging in a real environment.

Curiosity is an essential quality of the people who develop Perl and who spend inordinate amounts of time trying out the strangest pieces of code you've ever seen, all in an attempt to explore the boundaries of Perl, and maybe to break it.

2.3.4. Precision

Perl works hard to accommodate different ways of thinking and different styles of programming. This laissez faire acceptance does not mean there aren't rigorous definitions of the terminology of Perl itself, though. To communicate accurately with others and keep things straight in your own mind, learn the proper terms for everything you use and be ruthless about keeping them straight. For instance, there is a huge difference between lists and arrays in Perl: make sure you know what it is.^[1]When you say “system call,” do you mean a call that uses the operating system or a system() call? When you say “local variables,” are you referring to private variables declared with my or temporary copies of package variables declared with our or local?

^[1] See “What is the difference between a list and an array?” in perlfaq4.