I'm currently filling the role of quasi-lead for a Perl-powered web application. Due to the nature of our customers this web application is frequently in heavy development and we often find ourselves developing faster than we would like.

It is my _preference_ that our team be explicit and as clear as possible about the way they are accomplishing tasks. This practice extends beyond the way we solve problems in our Perl-codebase. I typically encourage the guys to solve as they see fit but I am constantly reminding them to "keep it simple."

$_, map and grep are among some of the cool features of Perl. They have their place and are often useful in reducing the number of lines of code required to complete a particular task (among other things). The problem with them is that they are _not_, in my experience, easy to understand. There are often much more simple ways of expressing concepts and those that are clearer are less likely to cause confusion.

And productivity, in my current job (and frankly, in most of my previous jobs), is closely linked with effective communication. When I code I am more concerned with readability from the perspective of others than I am about how quickly I can express myself or how Perlish I can be. I have managed to learn that viewing a problem from the perspective of another person can often grant me a better understanding of the problem domain and solution.

Cheers,

Matt