The quality you perceive your code to be 6 months after writing it is inversely proportional to the quality you perceived it to be when you wrote it.

When using git blame to resolve the person who wrote it, it's awesome while the source is very bad or even when the source very good.

I do git blame on code that's written well too. Just to see who wrote it

@retoor when it's really bad and the git blame points at you... 😬

@atheist that's why I often don't want to format source code. The bad stuff others wrote gets your name on it

No. But maybe if you’re a far-too-clever junior.

@retoor That’s why I don’t unless I must. I’m not allowed to refactor, so.

(Why? “It clutters git history” and “it makes code reviews confusing” and “if it isn’t specifically spelled out in the ticket, it’s off limits”. Uh-huh.)

Sometimes I say wtf to old code. Sometimes I saw htf to old code. Sometimes I say holyf to some code. Both in the good and bad sense.

my mind is a maximizer, and a really good one at that. It doesn't matter what principle I operate under, my output is guaranteed to implement that principle to its absurd, morally distorted logical extreme.

I learned how to write proc macros (compiler-integrated code generators) because Rust's type system couldn't enforce the rules I wanted to enforce, and my principle at the time was making invalid state unrepresentable.

My only hope is that with enough exposure I'll learn to maximize for pace, because although that's a shitty practice, at least it doesn't annoy stakeholders.

LOL, yeah you might be on to something.

The rudimentary simple code that you don't think much about is usually not something you vomit after seeing 6 months later.

It's often the "clever" and "innovative" stuff that you find revolting in hindsight.