Good points. I think I haven't expressed myself very well. As I mentioned before, among the problems with our existing codebase is the fact that most of the data is stored and passed around via (undeclared) globals. This obviously makes the code very hard to understand and maintain. When I try to refactor a chunk of this, the way I start is a search and replace, driven by slapping a "use strict" at the top of one sub at a time, then on the top of the file, and I watch the compiler barf. Getting a clean compile after that doesn't mean the program is now perfect, but at that point at least I can get a better sense of the flow of data, which makes it possible to do more interesting refactorings.

"use strict" is an aid but it's neither necessary nor sufficient to write good programs.

In general, yes. Although there is a back-burner project to move a big chunk of the system into mod_perl, and IIRC from the last time I did that, any program that won't compile strict will have some problems when it is moved to a persistent environment.

I'd be hestitant to work for anyone who focusses on details, forgetting the overall picture.

Fair enough. In reality, there has to be a major subjective (Is it subjective? It's holistic, at least -- how much do my teeth itch when I read the code? How happy would I be if I had to maintain it? Would I want to rewrite or seriously refactor it first?) component to the evaluation of any hiring candidate. I don't see myself rejecting anyone because of any single, specific thing they wrote, or failed to write.

Thanks for your comments. You're helping clarify my thoughts on this.