For the last 18 months I've been working almost exclusively on our Storyboarding web-app, Boords. Prior to that, most of my development work was on projects which would last anywhere from a few days to a few weeks. For the first time in my life, I'm working on the same codebase I was over a year ago. All being well, I hope to be able to say the same a year from now.
Without doubt, this experience has made me a better developer. Being constantly confronted with poor decisions and cut corners is a brutal but effective way to ensure I follow best practices. Things like writing documentation and tests, which used to seem like a good idea "if only I had the time", have now become an essential part of being able to do my job and maintain my sanity.
I've come to learn that the hallmark of good product code is how easy it is to change. And the best way I've found to write code that is easy to change is to make sure each piece of code has only one reason to change. In object oriented design circles this is known as the Single Responsibility Principle (SRP).
A necessary by-product of SRP is that you end up creating, renaming and generally shuffling around a lot more files. Initially, I found this alarming. In my head at least, more files equalled more places to have to look for something, and more opportunities for confusion.
In practice however, SRP works so well precisely because there are so many files. If all your functionality is isolated into small, testable classes your app can scale without it descending into a nightmarish jungle of interdependence requiring a Heart of Darkness-esque voyage every time you want to change something.