Not my experience. I despise maintenance programming. I dread the thought that I may have to inherit some maintenance programming as part of a gig.
The only thing I ever learned from maintenance programming was what not to do.
Over the years, I have maintained the work of hundreds, maybe even thousands of programmers on everything from clearly rushed fixes to large scale commercial software packages. And almost everything I ever encountered sucked. I bet I've seen the work of less the a dozen really good programmers.
Maybe it's selction bias...perhaps the work of the best programmers needs less maintenance, so it's much less likely that I'll ever get to see it. But thanks to the bell curve and the infancy of our industry, 99% of all programmers I've ever followed have significant shortcomings in the work...
I hate not instantly knowing what a variable stands for.
I hate 4 different variables for the same thing.
I hate program variables that don't match the file variable.
I hate the same line of code twice.
I hate 100 lines of code when 5 lines would have sufficed if the programmer only had a clue.
I hate steady violations of pre-agreed upon standards (whatever they are).
I hate spaghetti code. Especially where touching one little thing breaks everything because no previous programmer anticipated any of the 42 likely things that would happen in the life of this program.
I know that the rewrite debate comes up often, but once I reach a certain subjective tolerance threshold, a rewrite is a certainty. I like to think that:
a. This horrible shit will be banished forever.
b. This will finally work the way I think was originally intended.
c. This will finally look like it should have in the first place.
d. I'll be the last one who ever suffered maintaining this module.
Don't believe me? Just hit "View Source" on any random web page to reveal the mountain of shit that's about to fall out upon you.
All of the things you hate drive me crazy too. I sometimes want to bang my head against the wall when I see copy-and-paste code written by someone who didn't know how to program. But I enjoy the challenge of fixing the problems, one by one, refactoring incrementally.
I've also learned that what I think is the right way to solve a problem isn't the only way. Most often I am rewriting bits of crap code, but I also learn new techniques and approaches.
I love green fields programmers who know the best way to do everything. Their projects frequently flame out, leaving a desperate client and an almost-working code base that fell short of someone's idea of perfection, but is fairly close to working after some practical compromises are made.
The best thing about maintenance programming is working on real code with real users. I don't miss spending three-fourths of the project schedule arguing data structures with three other programmers and a nervous client.
Another thing I hate with pure maintenance programming is that you're generally told to touch as little code as possible. If it 'works', don't change it.
Sometimes you'd love to refactor a bit of 10 year old C code to be more readable, or less bug-prone. But you can't because it's not a bug.
In some cases it's even worse and you can't even fix bugs that you find. Only bugs reported by customers count as bugs. Of course, a customer will eventually stumble on it, but heh.
I don't mind maintaining code as long as it's focused on structural improvement, not on manouvring through the code very carefully hoping the whole thing won't collapse.
There is code that really needs to be rewritten. If it's so creaky that you can't make any change without breaking other things, and you aren't allowed to refactor, that's trouble. I don't take on projects like that. But in my experience it's more common with web applications to find code that has lots of room for improvement, but isn't really falling apart. Most freelance developers/consultants immediately go to "we have to rewrite it," which the business can't afford right now, and therefore deprive themselves of the maintenance business.
The only thing I ever learned from maintenance programming was what not to do.
Over the years, I have maintained the work of hundreds, maybe even thousands of programmers on everything from clearly rushed fixes to large scale commercial software packages. And almost everything I ever encountered sucked. I bet I've seen the work of less the a dozen really good programmers.
Maybe it's selction bias...perhaps the work of the best programmers needs less maintenance, so it's much less likely that I'll ever get to see it. But thanks to the bell curve and the infancy of our industry, 99% of all programmers I've ever followed have significant shortcomings in the work...
I hate not instantly knowing what a variable stands for.
I hate 4 different variables for the same thing.
I hate program variables that don't match the file variable.
I hate the same line of code twice.
I hate 100 lines of code when 5 lines would have sufficed if the programmer only had a clue.
I hate steady violations of pre-agreed upon standards (whatever they are).
I hate spaghetti code. Especially where touching one little thing breaks everything because no previous programmer anticipated any of the 42 likely things that would happen in the life of this program.
I know that the rewrite debate comes up often, but once I reach a certain subjective tolerance threshold, a rewrite is a certainty. I like to think that:
a. This horrible shit will be banished forever.
b. This will finally work the way I think was originally intended.
c. This will finally look like it should have in the first place.
d. I'll be the last one who ever suffered maintaining this module.
Don't believe me? Just hit "View Source" on any random web page to reveal the mountain of shit that's about to fall out upon you.
Joy? I'd rather chew razor blades.