Testing is another tool you should be using more than you already do. Your test suite is your preventative maintenance. This is what keeps you from screwing up. A friend of mine helped me change my brake pads recently. When we took the tire off to get to the pads, he put it right under the car. When I asked him why, he countered with "Is it cheaper to get a new rim or a new axle?" That's a test case for mechanics.

CPAN is another tool. Recently, someone like japhy wrote a module to fulfill a request (Techniques On Saving Memory). Turns out that not one, but two modules were already on CPAN that did what japhy wrote (though the APIs for each were different). Granted, it was only 30 minutes and japhy probably enjoyed them. But, what if you write your own connection to a database (DBI) or templating module (Template) or web application framework (CGI::Application)? That's not 30 minutes. In some cases, that's 30 weeks and you still won't get it right. And you have to maintain it on your employer's dime.

Keeping with the CPAN idea - learn how to use the modules you do use. Did you know that you can pass in a reference to a subroutine as a <TMPL_VAR> to HTML::Template and it will behave as a callback, even within a <TMPL_LOOP>? That was a feature someone was asking for recently and was considering junking H::T because "it wasn't there". Yet, it was there (just documented in a confusing way). That's huge!

Three things:

• Version Control
• Version Control
• Version Control

Seriously. It doesn't matter whether you use cvs, subversion, or even something else. It's not only useful for going back to see edits, I find it has an unintended consequence: It enforces discipline and makes me *think* about what goes into that treasure-box and get marked with my name, my work, and my comments. (Versus just some random file laying in a directory somewhere...

It's so funny you mention this. I literally just finished going back through a clearcase repository to do some forensic analysis on a change. The history goes back to before 2000. The changes I was looking for happened as early as November, 2001.

Since there is very little developer documentation and nearly every person on the product back then has moved on, the source control and being able to diff various versions is the only way I can come up with a reason behind why certain changes were made.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Which leads to another suggestion: Document your code; and don't be afraid to leverage whatever tools you can find to make it easier and thus encourage you to do it. (You'll thank yourself later!) For starters: learn POD; learn Doxygen (or similar); learn what Literate Programming is.

Seconded. 14-ish years later and there's still gobs of stuff in Emacs that I still don't know that it could do. Just the other day I found Skeleton mode. C-h i and just browsing can be fruitful.

One of my tools is my brain, so I make sure to "sharpen the saw" from time to time.

Sharpening a saw by hand is a difficult, slow, and risk-prone activity. If you mis-align the teeth, you may end up with a duller saw than when you started. If you apply force in the wrong place, you may break the blade altogether.

Sometimes it's just cheaper and easier to buy another saw blade, or even another saw. In the context of programming, that would be consultation or collaboration with a co-worker, or perhaps hiring someone new...

Sharpening a saw by hand is a difficult, slow, and risk-prone activity. If you mis-align the teeth, you may end up with a duller saw than when you started. If you apply force in the wrong place, you may break the blade altogether.

Just to stretch the metaphor, I wonder what sort of activity might be comparable to "breaking the blade". Probably the closest thing in my life is burn-out from a rotten job environment. Had me seriously considering an occupation change.

Rats... beaten to it again! :-D That's a good link!

Seconded. While I heartily agree with all the comments on editors and HDD backups, my mind is my most important tool. Whenever I'm hung up, I back off and examine the attitudes that frame the context of my attention.

Be it the way I'm iterating over a file, the tool I choose to approach a task, my attitude towards that task, or how I see myself in relation to a programming team, I constantly have a background thread in my mind looking for stressed nodes that indicate improper framing.

In programming, things are just taking too long, either to run or to code. In attitude, either heat or 'tiredness' are present when there's a mental bugaboo present. In relationships with others, I look at what I call my teammates subconsciously. Are they partners or are they problems?

If your mind is clear, your code will be clear.

If your mind is clear, your code will be clear.

A minor nit - If your mind is clear, your code can be clear. I'm pretty sure Damian Conway's mind is very clear, but I'll be damned if his code is! :-)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

1. Use Emacs, look for easier methods:Currently looking for integration of CPAN, perldoc etc ..
   
2. Read Perlmonks regularly, contribute where possible.
3. Browse CPAN modules directory
4. Read c.p.l.m sometimes
5. Browse the web for the novelty of technology and try to replicate that to the extent possible.
6. Keep up with hotest trend in tech to the extent possible. (Now, not easily possible when you gain proficiency in some skillset).
7. Use version control mechnism.

Want to work with more techniques such as..

1. Do code in terms of algorithms.
2. Testing
3. Project design and planning.
4. Read opensource projects

At risk of descending into the traditional backup rant, it's not just if the hard drive goes. Many of us use laptops, which are (as I know only too well, see below) a magnet for scumbags, ne-er do wells, and thieves of all sorts.

Irritatingly, so are CDs, so don't store your only data backups on the CD rack next to the collected works of Britney! For my part, I keep a 'core' of absolutely vital stuff in a particular directory, ruthlessly keep it below 256MB, and back it up onto a pen drive on my keyring 1ce a week, as well as other backups. When working on something important I periodically email it to an offsite location (home if at work, work if at home).

Two weeks ago that habit saved me from disaster. My laptop was stolen at the end of a weeks holiday, taken specifically to work on my dissertation. 4 days later I had replaced it and retrieved the copy of the document I had mailed to work - without a single word lost.

g0n, backpropagated monk