My job breaks down to something like 25% tech support, 65% fixing other people's bugs, 10% developing new features. Maybe I'm just bad at managing my career or something.
Sadly, that's about the norm in this industry.
There's a reason why the average software engineer burns out after 5 years. The legacy/maintenance burden is a real problem, and it ends a lot of careers.
There's a lot to be learned in maintaining one's own projects, and I think everyone should maintain their own stuff, instead of being "promoted away" from maintenance, but I think maintaining other peoples' code is only a strong learning experience when the code is of very high quality. In that case, it doesn't feel like maintenance.
What happens is that poor maintenance practices lead to more maintenance work in the future, and the norm in the software industry is for maintenance to consume 70-90% of developer time. Sloppy maintenance practices self-perpetuate. With proper practices in place, it should be 30-40% at the worst.
The biggest fuckup in the software industry is that maintenance jobs usually get passed to junior programmers who (a) don't know enough to do them properly, and (b) more relevantly, don't have the power to do maintenance properly. Actually improving the code would require clout in the form of (a) asking people to drop what they're doing and document code they wrote years ago, (b) removing bad functionality from APIs, and (c) having the option of saying, "we need to rewrite this entirely" without risking one's job. The junior developers who get the maintenance projects never have that kind of political power, so the result is that the "maintenance" doesn't achieve lasting code health improvement.
The trick, and very few companies have figured this out, is to create a "maintenance engineer" career track, pay it 30% more so that it's desirable and people have to be turned away from it, and delegate legacy maintenance tasks to people who actually have the relevant skills and can actually (imagine this) improve these legacy modules instead of "maintaining" them indefinitely. The most important thing is to make sure these engineers actually have enough power/clout to do their jobs properly. Which means the maintenance work should go to people who actually have proven skill and can be trusted, not those who draw last.
> The biggest fuckup in the software industry is that maintenance jobs usually get passed to junior programmers ...
Agreed. Moreover, maintenance isn't great at teaching anything but maintenance.
> The trick, and very few companies have figured this out, is to create a "maintenance engineer" career track...
That might be a good idea. I think it should be something you're promoted into, rather than out of, after having spent a while writing and maintaining your own code.
Sadly, that's about the norm in this industry.
There's a reason why the average software engineer burns out after 5 years. The legacy/maintenance burden is a real problem, and it ends a lot of careers.
There's a lot to be learned in maintaining one's own projects, and I think everyone should maintain their own stuff, instead of being "promoted away" from maintenance, but I think maintaining other peoples' code is only a strong learning experience when the code is of very high quality. In that case, it doesn't feel like maintenance.
What happens is that poor maintenance practices lead to more maintenance work in the future, and the norm in the software industry is for maintenance to consume 70-90% of developer time. Sloppy maintenance practices self-perpetuate. With proper practices in place, it should be 30-40% at the worst.
The biggest fuckup in the software industry is that maintenance jobs usually get passed to junior programmers who (a) don't know enough to do them properly, and (b) more relevantly, don't have the power to do maintenance properly. Actually improving the code would require clout in the form of (a) asking people to drop what they're doing and document code they wrote years ago, (b) removing bad functionality from APIs, and (c) having the option of saying, "we need to rewrite this entirely" without risking one's job. The junior developers who get the maintenance projects never have that kind of political power, so the result is that the "maintenance" doesn't achieve lasting code health improvement.
The trick, and very few companies have figured this out, is to create a "maintenance engineer" career track, pay it 30% more so that it's desirable and people have to be turned away from it, and delegate legacy maintenance tasks to people who actually have the relevant skills and can actually (imagine this) improve these legacy modules instead of "maintaining" them indefinitely. The most important thing is to make sure these engineers actually have enough power/clout to do their jobs properly. Which means the maintenance work should go to people who actually have proven skill and can be trusted, not those who draw last.