Most of the code that I encounter was written by other people, many other people, over a long period of time.   Long enough that both the framework technologies and even [Perl | whatever] itself have evolved.   When you look at a code-base like that, you can watch the influence of various fads and fashions, as they come and go.   There have been just three things that I have most wanted to ask / beg of the coders who are writing “the crappy code of tomorrow” ;-), today:

(1) Write for the future, and be consistent with the past.   Sometimes it is much better to keep one way of doing something, in a large application, than to introduce another way of doing the same thing that (a) is no better, and (b) burdens other parts of the system ... especially, exception-handling code ... with decision-making therefore complexity that doesn’t bring added value.   For instance, use eval or Try::Tiny, but not both.   Don’t launch on a big project (especially an unauthorized one) to save the application from itself.   Some of the directives in Perl exercise a surprise influence upon how the language itself behaves, and this can be hugely disruptive, especially if their introduction by you into the project is, itself, a surprise.   Yes, we have the use languageversion; pragma, but there needs to be universal consensus before introducing any new code anywhere that would oblige one to use it.   An application consists not only of itself, but the entire and total context which surrounds it.   Undetected instability can come from anywhere.

(2) Don’t commit an “off-topic” change, or one that is any larger than it truly is required to be.   If, for example, you get annoyed that a piece of code is being Perl::Criticized, and you decide to Perl::Tidy it up to make it “–er,” you have just cut-off that entire piece of code from its history ... affecting every thread of changes in the version-control system that ever passed through that region of code.   (In every version-control system that has ever in the past been used ...)   It can even be very-disruptive for a piece of code to be visually different from the prevailing norm, even if some tool/pundit things that the new appearance is “–er.”   New ideas, which might be fantastic in a brand-new application (and how long has it been since you actually saw one of those ...?) can just be de-stabilizing.   There are no absolutes.   “There’s More Than One Way To Do It™” doesn’t mean that it is a good idea to introduce another way.   (In fact, please don’t.)

(3) Write for simplicity, and write tests for everything that you write.   Perl is not a strongly-typed language; the mere fact that a piece of source-code compiles does not tell you much of anything at all.   Many coders coming into the labor market today do not seem to be well-versed on this idea.   They are very dependent upon “compile-time” errors and warnings which Perl often simply does not have ... and, they are unaccustomed to seeing some of the very dynamic behaviors that are routinely used when writing (especially, legacy ...) Perl source-code.   If you do not have “test-driven development” in a Perl shop, maintaining stable releases can be very difficult ... especially among the work of the “new hands from foreign lands.”   The only way to know that something works, and that it did not break something else, is to continually prove it.

“Compatibility,” then, is not entirely a language feature:   it is a process feature.   It is an attribute, not so much of the language (whatever it is), but of the team’s own internal disciplines – and your own.