This is fundamentally a cultural issue. First of all, be careful of thinking you can "prove" that a different methodology is better. With time and experience, you'll get better about "persuading" your colleagues about better practices.
The problem is that the people in a shop develop certain habits, and come to certain shared understandings, and become quite comfortable in that. They experience "confirmation bias", in which their experiences confirm their bad practices ("I wrote that really quick and dirty, and we still shipped on time!") and discount evidence that contradicts their beliefs ("I spent three weeks on that bug, but I'm moving on to new code now.")
My experience is that the shops with bad practices are particularly resistant to good practices. The reason the shop settled on bad practices in the first place is that they weren't interested in alternatives.
On the other extreme, I've worked in shops that were so smart, and so open to new ideas, that it got kind of crazy because the infrastructure was so dynamic even from week to week, it was hard to tell how to write code and get it released (I'm currently in a situation where I've been waiting a month for a QA box, but they just re-engineered their code check-in workflow, so I'm back to square one, with no QA box. Or maybe square -1.)
As you stay with a shop, and as you gain responsibility, you'll have more and more influence on the culture. After all, the guy sitting at the keyboard ultimately makes a lot of the decisions. But it will be a long process of identifying specific things that could be improved, and either changing them individually yourself, or educating and persuading others to follow a better way.
...or, I should add, moving to a different shop. In this industry, sometimes the grass really is markedly greener on the other side.