Why?
To paraphrase someone else: I wrote sufficient code because I didn't have the time to write good code.
There's always a better abstraction I could have teased out, a more complete refactor to make that one line hack never have to exist, and better documentation which would read more like English and less like shorthand.
(I'm saying this as someone who's been coding in C++ for over two decades, while still finding lots of room for improvement in my older code.)
The analogy I'm experimenting with now is stage performers for Opera or Musical productions. If you see them up close, such as video recording, they clearly 'overact'. They use exaggerated facial and arm expressions to project their performance far enough so the people in the middle or even the back can see what's going on. They are expanding the audience greatly, but admittedly at the expense of those closest to the action. But on the whole it's a better performance.
When I find bugs in my code, introduced by me or added by someone else, I think about how it looked before and try to determine if it was just a dumb mistake or whether I tricked them into it. Maybe I grouped the code oddly, or chose an unfortunate variable name that implied something else was going on. If it's the latter I think about whether I really want to use that pattern anymore. What's tricky is that everyone tries to make their code look like the existing code, so people may be copying the pattern thinking it'll get them a clean code review. If I think the problem is bad enough I may stop and refactor all the places it's used (it only works if you're really, really practiced at refactoring), otherwise I'll just make a note so stop doing that in the future. I might mention it in a team retro.
I want my code to be as plain as it can be and still get the job done. Indeed at this point I positively fume when a 'senior' developer writes clever code, because they should know by now this isn't about them and they're hurting the entire team trying to fluff up their own ego. Look how important I am that you need me to fix all the really hard bugs. Fuck that, and fuck your dazzling bullshit. The only thing that pisses me off more is a manager that thinks 'blame allocation' is a viable management style.
That's a young mans game, after you've been doing this stuff long enough the things you learn are in terms of systems design, maintenance, etc. I regularly go back to code I wrote 2 and 3 years ago and think to myself "knowing what I know now, that code is mostly alright".
I can't understand how someone can go back and look at some authentication code, for example, and think the way they did it was horrible. Just how many different ways can you write auth code?
It's one thing if you're a young developer, but at some point the improvements to your code are negligible and have nothing to do with the value you bring to a project.
The thing is, if you're going back to the first time you've ever "programmed time", then what you're assessing is design, not code, which falls in line with what I said.
[edited to remove typo]