Jason Lutterloh tells a story every programmer recognizes instantly: a coworker messaged him saying "look whose name is on this changelog," and it was his own, in a file he'd written during his first year on the job. He opened it up and found `<br/>` tags scattered through the HTML just to fake spacing. The painful part wasn't the mistake itself — it was remembering how, at the time, he'd spent hours obsessing over tab spacing before committing, fully convinced it was perfect. One of his first mentors used to say that if you go six months without looking back at your old code and finding something to improve, you're not growing as a developer. It's a nice line until it happens to you. There's an old Hacker News thread, over a decade old now, where someone sums this up in two sentences that look identical but aren't: "I can't believe I wrote this code," said in horror, and "I can't believe I wrote this code," said in genuine amazement. The person who wrote the original comment had both experiences in the same week — they went back to a small module they'd shelved for a month and couldn't remember why they'd named the variables that way, then dug up some old VB code to adapt into JavaScript and walked away impressed with themselves, like "was I really that good back then?" A reply further down the thread says something that sticks with you: looking back and feeling disgust is healthy, it means you're evolving; it's looking back and feeling unreserved pride that should worry you, because it probably means you've stagnated. Over on r/ProgrammerHumor, there's a comment thread under an image about old-school programmers that captures the more practical side of this, no philosophy attached. Someone wrote that they were spending half their current project replacing a 10,000-plus-line monolithic file, full of global variables with two or three character names, dead code scattered everywhere leading nowhere — and the other half of their time was spent trying to explain why it needed rewriting without insulting the senior engineer sitting right there, who happened to be the one who wrote it. That captures something jokes about ugly code tend to hide: code from five years ago is rarely abstract shame, it usually has an identifiable author sitting three desks over, or worse, it's you staring back at yourself. It's worth adding a longer Hacker News discussion about rewriting versus refactoring legacy systems. One comment pointed out something most "never rewrite your software" articles conveniently skip: you only ever hear the horror stories from people who rewrote and regretted it, never the stories of companies that refused to rewrite and got crushed because every new feature took months to ship, or lost talent because nobody wanted to work in that codebase. The truth, as usual, sits somewhere in between — and that gray zone is usually exactly where your five-year-old code lives: not all bad, just outgrown by what you learned afterward. There's one more detail that keeps coming up in these threads and rarely gets taken seriously: some of the most upvoted comments about rewriting old code aren't about shame at all, they're about the physical pleasure of deleting lines. Someone recalled an old commit of minus sixty thousand lines as the best commit of their career, and another reply said they hadn't felt anything that algorithmically satisfying since. Maybe that's the real point — the shame of old code isn't just about what you got wrong, it's about realizing, with slightly uncomfortable clarity, how much you've changed since then. And if you go back to the code you're writing today five years from now and feel none of that shame, that's probably the version of this problem you should be worried about.