Dealing with a legacy codebase it's, at the same time, frustrating and challenging. Tightly coupled code, poor or completely absent tests, big methods and ugly variable naming... usually finding that subtle bug or try to add a new feature it's quite difficult. But, in my experience, being successful while working on such projects is even more rewarding!
I started my current job not very long ago, and one of the first stories I was pairing on involved some small changes on a JavaScript file. The file itself was massive: unused variables, long methods, even some completely unrelated functions that clearly should be elsewhere.
I was driving, and the first thing I did was getting rid of couple of unused variables, and create a file where to store the unrelated functions (we use JAWR to bundle together JavaScript files). My peer asked me why I was doing this, before even typing new lines of code for adding the feature - my answer was that "whenever we see a mess, we should leave the code cleaner for who's going to maintain it next". This is often referred as the Boy Scout Rule.
Always leave the campground cleaner than you found it.
This also applies to code. Whether you work on your own or part of a wide team, your code will be read by developers (it may be also you, after a few months you haven't touched it), which possibly will spot a better way of implementing what you've done (from renaming one variable to a more efficient way of doing some tasks). If everybody takes the time to tidy up a bit, the code will look and perform better and better as the days go by, becoming gradually easier to maintain (and consequentially, to add new features) and without allocating specifically extra time for cleaning tasks. You're showing that you care about what you do, which is one of the pillars of being a Software Craftsman.