Most people assume that maintenace begins when an application is released, that maintenance means fixing bugs and enhancing features. We think these people are wrong. Programmers are constantly in maintenance mode. Our understanding changes day by day. New requirements arrive as we're designing or coding. perhaps the environment changes. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process. - The Pragmatic Programmer, pg. 26
However, I am armed with new information, and a new way of thinking about software and it's development. I am fairly confident in my ability to write code - as in, it compiles/runs, it doesn't throw any (serious) exceptions, and does it's function. Pumping out a program that does mostly what I want isn't something I worry about anymore. I know that most problems I can think of or come across, someone, somewhere has solved it at this point; the important part is the implementation.
I am currently working on a mobile application to track routes, stops and arrivals for the Portland Trimet system. I have probably rewritten each piece of the app at least once, and near the top of my to do list is "Refactor factories into one 'transitFactory' that divides controller from model better." I have accepted the fact that, at least on my personal projects, rewriting large amounts of code is not only going to happen but is absolutely a good thing. As I rewrite, I will learn how I can plan things better for my next project, as well as understand how to create code that can be rewritten - another thing The Pragmatic Programmer, by Andrew Hunt and David Thomas, talks about.
And that's what I think about now when I sit down to code. Not how I'm going to make my code run, but how I'm going to structure the code so that it's easily maintenable, easily reused, and easily read. I want to stop hating me-from-3-months ago, and to do that I'm going to do me-in-3-months a solid by planning, and then refactoring, refactoring, refactoring.