The act of programming naturally raises dust and creates entropy. The fundamental limit to programming is in the human ability to keep track of what is going on. If possible the goal should be to maintain acceptable performance and development speed while laying the ground to lessen how much has to be kept track of to redesign the code or add new functionality to it. There is a trade-off here since the internal code-quality is not visible. But long-term consistently doing this will result in faster overall development, fewer bugs, and better performance.

What does this mean in practice?

It means that you avoid having to synchronize code. Similar functions should both be wrappers around one if possible. Use hashes to avoid maintaining logic where multiple arrays have to be kept in parallel. So on and so forth.

It means that you write in terms of lots of small functions that can easily be moved around. It means that you design code in chunks with simple external interfaces so you can overhaul each chunk. It means that you choose meaningful variable names. It means that you don't try to comment too verbosely - rather make the code stand as a comment. (If you comment too much you now have two documents, one in the code and one in the comments. Both start out equally likely to be buggy. Which gets maintained?)

What else? Well choose the right tool for the job. Note that tools are constantly changing. Budget regular effort for keeping up because things change. OTOH don't throw away lessons learned. For instance there are a ton of Perlish constructs. Many can be carried over to other languages if you try. Do so. The principles of good programming don't change just because the language did!

There is a lot more, but I am going to just start repeating classics like Code Complete and The Pragmatic Programmer. So let me just summarize that by saying that there are classic books out there on how to program well. They are classic for a reason. Go try to learn from them...