If those seven points work for you, great, but I don't think you can generalize them. I think I'm a fairly efficient coder as well, but I don't program in a team (I do work in a team, but while I program, I'm not a programmer), and a fair amount of the code I write (both for work, and privately written code) is designed to do one specific task. Let's see how your points work out for me.

Peer review

I don't have (Perl) peers to review with. I do peer review, but on a much higher level that reviewing code. I might review algorithms or strategies, but not code. My favourite reviewer absolutely hates Perl.

Code reuse

Most of the code I write are simple programs, doing a specific task. More often that not, there isn't much to factor out to modules. I sometimes, even write programs that don't have subroutines. If there's something that lends itself to be factored out to a module, I do so, but I'm not going the extra mile. I prefer delaying. If later I want to reuse something that I've done before, I can always make a module then.

Good design

Good design make *me* happy, but I also realize that my good design might not be someone elses. As for making the project owners happy, they usually want the result of the program, or the fact that there is a program doing "X"; as long as the result is there, good design is a bonus (or not relevant).

Continual Learning

No contest here.

Testing

It depends. For many of my programs, testing is like testing a baked cake: the proof is in the eating. It's the end result that counts.

Teaching

Again this assumption efficient coders work in a team.

Documentation

Documentation is good, but often inline comments are good enough. Hey, if I write a program that creates a boot floppy - once I have the boot floppy with all its necessary files, the program is likely to never be used again. So, the POD isn't necessary.

Abigail