[kevinmchugh]

There are organizations that generate forgotten apps that are basically used but unmaintained. These are tarpits for developers. You don't want to be the person they fling at every forgotten codebase. They tend to be sideshows - if they really brought in the money, or the users, the business would invest in them and have people who know the language.

There's value in being able to go in, fix a little problem, and make things better for your customers. But you have to balance that against becoming the guy who works on the unimportant projects. That's real bad. If there's growth potential for the forgotten app, you have to get buy-in from the business and not just sideline yourself away from the things people care about.

Often these tarpits were contractually mandated. One customer wants a particular integration, so a developer builds it, and it works for the customer and everything is fine until another customer comes along wanting a similar integration and now the original dev is gone.

[sdoering]

I know from quite a few traditional corporations, especially banks that have very central old systems that they pay people enormous day rates to maintain.

But the question would be if one wants to be the go to guy for keeping old cobol things running.

[szundi]

The value of any other stuff you learn other than solving problems has half life. If you can be paid extra for Cobol stuff for a decade or two, then why not use this opportunity and get up to speed in 2-3 years after that.

If you have just a bit of bad luck, you may have a carreer with no real deep involvement with anything, not even talking about the fact that the language is just one aspect of your productivity.

[HPsquared]

You could call the general skill "software archaeology".

[edgyquant]

Refactoring old codebases into something nice to work on is comfy though. It’s basically what I do in the startup world I just use less niche languages.

Although I’d suspect there isn’t a lot of refactoring going on in some of those code bases you describe.

[kevinmchugh]

I think this is a healthy and productive career path. If you can identify when a dead codebase is about to become fertile, and how to clear the debris to support new development, you can make a lot of money, have a lot of fun, gain a lot of respect, receive a lot of autonomy.

You just don't want to be the person tasked with work that's only done because some contact got signed. Identifying the difference is hard.