> Every company should have at least one guy who enjoys maintaining legacy systems and that should be his sole job.

That's a career death sentence. I suppose if I was retired and wanted a part-time gig for extra money/amusement, I'd do it. But one thing I learned from working maintenance early in my career was... don't do maintenance work.

I wouldnt entirely agree with that.

I think it depends on the KIND of maintenance work. In my case, I have a few languages under my belt (both OOP and FP). But this means I have a reputation in the area as a "Mikey for Maintenance: He'll fix anything"

Which actually wound up giving me the opportunity to study a lot of both good and bad designs.

I still maintain things, but now people ask me for design advice and help with POCs too.

Which, trust me, is less stressful and more socially rewarding than being a technical lead on a project (done that too).

But that's not a common thing. I do agree with GPs assessment that there are good maintenance devs. But they aren't common, and it can be tough to tell if someone with 20 years of maintenance actually enjoys it... or just could never be good enough at it to get a chance at a different role.

if by maintenance work, you mean "patch up the system so it keep trudging a long" then sure. it sucks.

And I feel that when people refer to maintenance work that is what they end up doing.

I like improving systems (I think it is a much a bigger challenge than making a new system from scratch). I suppose this is a kind of maintenance work.

But I am still trying to figure out how to get the green flag to do this. I often want to re-architecture big parts of the system; but at the same time, I don't want get overworked (neither does anybody really).

I find that I don't really have an incentive to refactor a semi-large part of the code into a better design (how do I even know if it's better? seems subjective). My incentives (deliver the story, complete the sprint's points) push me to just change as little as I can (patch it up) and then forget about it instead of refactoring a lot of it.

And every time I have done that I keep thinking as I do it: "this is exactly how this code got to this point. A few generations of developers with no incentive to refactor this from a slightly bigger picture, just carefully hack in what the story requires and move on". aah the joy of software engineering in real life :/

It is. Also, people don't want to do it for any amount of money.

I quit a previous job and took less money because I got moved to maintain the crumbling Forte4GL core system - I did get a handsome raise for that, but the writing was also on the wall as they were also working to replace it. Migration project has been ongoing for 8 years and is nowhere near done, I might have been able to retire before it's completed though. It was also soul-sucking.

> It is. Also, people don't want to do it for any amount of money.

Like many things, there are people who actually are interested in doing this kind of thing. But since it isn't rewarded in any way, hell, because it's actively punished by many organizations (often by the time you need to look for a new job and you lack the right bullet points to hire you), you're not going to find anybody willing to do it, who actually would like to do it.

But there are people that love doing it. My wife is an example of one. To her is it a great mystery novel where she gets to tease out all of the details and try to understand why things were built the way they were. Then try to make them 'better'.

Of course, she was a government employee (mil) and her career path was set regardless of what she actually did and the pay level was set in stone regardless of what she did as well. So there is that.

> Of course, she was a government employee (mil) and her career path was set regardless of what she actually did and the pay level was set in stone regardless of what she did as well. So there is that.

I mean, this is only relevant insofar as that this position allowed her to pursue her interest in what kind of programming she wanted to do. In any private company, the incentives are so perverse that she wouldn't have been able to do any of it, but that wouldn't change her preferences. It's just further indication that, given the right environment, there are people willing to do this kind of thing.

> Then try to make them 'better'.

this. I like this too. but then, in practice, I very rarely get a green flag to actully make it better. Not until is do or die. And by that point necessity forces a rush job, so it's not actually made better, just patched up to live another 'day'

People don’t want to do it for any amount of money that is offered for that work.

There is an amount of money that will clear that market, though.

Only if you optimize for your current salary instead of optimizing for your future career prospects.

There isn't a reasonable amount of money (it would have to be twice my current salary) for me to accept a job doing VB6 or any other job that would endanger my future employment prospects.

If I can retire one my savings after the job is done I don't care about future prospects. I'd rather work on [insert any hobby with no commercial value] at home than go to work.

$10MM/yr with a one-year notice and severance period gets you as many maintenance programmers as you’ll ever need...

Exactly, that’s why I said any “reasonable” amount. It usually takes me less than a month to find a job as a bog standard “enterprise developer” when I need the “right now” job or contract. It would take me a lot longer if my resume showed that I’ve been maintaining legacy software for two years and wasn’t doing Resume Driven Development.

I would have to spend a few months doing some work I could post on Github using new technology (something I never do).

The other take away is this; for many situations, investments made toward cultivating the existing system can save the company more money in personnel and run time costs than can be gained from developing new functionality for the same system.