I've never thought maintenance programmers should be the least experienced ones. It's not so much experience but temperment that divides people into which phase they work in, I think, although no one seems to think about that when making the assignments.

I've been at a few places that get nervous when they look at my code and see a lot of map statements. I don't tend to write dense code, so it's not that they can't pick out the flow. They just don't map yet. However, I'm not going to give it up. For the money I get paid, they should use all my skills. Otherwise they could hire at the same price three guys who don't know map.

There are things that I just don't use for client work: source filters, Spiffy, typeglob magic, odd B hacking, and so on. That stuff is a little much to ask of the typical Perl programmer who's just doing his day job (instead of someone like me who writes about Perl, publishes a magazine about it, and works with Randal).

In all of this, people need to develop good reading habits in themselves and the people they have to work around. Some places I've worked even have a "team library" with all the right books (with several copies in some places). If you run into something you don't know, pull out the Camel book and learn about it. Write a couple of dinky scripts to play with that feature without worrying about making it work in a big program that has sorts of other (broken) things going on. Don't get turned off because it seems weird at first. Everything seems weird at first.

Along with that, we encourage people to develop a style guide, and talk about hwo they are going to code. This can include the features they are not going to use along with a justification for it (since they'll have to explain it to every new person anyway). Often, there isn't any good reason other than FUD, and the exercise of writing it out usually makes them realize that.

In the end, if we are going to code to the lowest common demoninator, we can get rid of strict, lexicals, and subroutines. :)