Programmers often have difficulty going back to older code bases because they don’t reflect the latest, greatest idioms. It can be hard to work with constructs that you know could be better, written with less code, stripped of even more duplication, beautified. But it’s important to realize that all code will eventually feel like this.
Even if you take that project from three years ago and scrub it clean as can be today, it’s still going to drift from the best practices of two years from now. That’s normal, it’s natural. You continue to get better, to learn, and the technology you’re using is hopefully progressing as well. Yet it can still seem like a hard hill to climb to get back in to yesterday.
Suck It Up
Here’s something I don’t say often: Suck It Up. If you work on more than a few projects, they can’t all smell like today’s fresh linens. It doesn’t mean you’re a bad programmer. It simply means that you’re prioritizing.
Yes, yes, you should clean up around you when you dive in to those older applications, but beware the lure of a full Spring cleaning. You’ll get pulled in and before you know it you’ve broken half the application and won’t know how to get back out with your ego or tests intact. Add your feature, fix your bug, and leave everything you touch in better condition than you found it, but that’s it. Move on from there.
This is not a license to be a slob. Whenever you’re starting something new, you should always try your best to infuse it with the top of your game. That way you can hopefully drown the feelings of disappointment with at least a dash of nostalgia: “Hey, when I worked on this I did the very best I could. How great to see the progress of my skills and sensibilities since then. Good job, me!”