I think the problem is that, while most people agree that badly factored code that drags down productivity is a problem, people can't agree on how to make it better. So, discussions about code quality get mired in subjectivity, often people can't agree and if anything changes at all, you agree to some half-baked compromise that doesn't really address any of the issues.
I don't think how you can avoid that unless you find people that have similar ideas to you about how to write code.
having done this, I generally think my old code is fine.
When people say things like I this I always point out that this may be true for the first 2-5 years of you developing but if it's true 15 years in you're not actually improving you're just being mercurial.
At some point your growth as a developer moves outside of code and you recognize that there's beautiful code, devilish code, and then a huge grey area where things are just fine even if they aren't how you would have personally implemented them.
Having been in the industry for 10 years, I would agree that after a certain point, your personal opinions about code style tend to change less and become more consistent, but I still run into enough other people that also have a lot of experience, yet seem to have entirely different views.
Out of interest, what kinds of things would you consider "beautiful" or "devilish"?
I read through the CLANG code back in the early days of its existence and found it to be quite elegant in its structure.
devilish, I once came across where someone had accidentally written a FSM that used http redirects as the transitions between nodes. All to animate a progress bar for a job queue. It was so ridiculous it honestly took me longer than I care to admit to understand what I was seeing, who the hell expects to see that?
OTOH, we have a codebase at my current employer that opens up a TCP socket to a service and passes pipe delimited strings. And you know what? I give the thumbs up to that. Why? The service it's communicating with is an old C++ service that was written around the time that XML started coming onto the scene. That's how you did things back then and it works perfectly fine, albeit it's probably not the most familiar to younger developers.
Oh yes, I totally agree. Some things that I used to write, I would find insane now.
But it doesn't make the problem any less real. At my current job, I think our tests are really bad because they mostly don't test what really matters (also due to too many things being spread out across several services) and instead are coupled excessively to implementation details. That makes development slow and also means I can never be sure that my changes don't break something important.
I don't think how you can avoid that unless you find people that have similar ideas to you about how to write code.