I've worked with companies that provide COBOL contractors and no, it does not pay well. The vast amount of fees collected from clients go to consultancies that train-up interns in South Asia (have huge staff turnover) and these interns-cum-employees A: Stick with it in the hopes of being directly employed by their client (which happens, a F500 job in South Asia remains a big deal for many), or B: See those that did other technologies get paid much better after only a couple of years but get locked-in to their vendor through wider skills.

Niche technology skills can become suddenly in-demand, and in Y2k COBOL certainly was. Is there another Y2k event hitting COBOL? The higher paying jobs are only in architecture roles which means intimately knowing a vast code-base (product-specific) rather than COBOL itself.

This is my anecdotal observation having worked with COBOL/CICS/DB2 teams over a few years.

I also agree with the comments from smt88. Haskell would take a tad longer to get proficient in but once so you could sneeze in the direction of a large company that uses it like, I don't know, StanChart, and probably get a good offer. COBOL's not like that. Unless you're particularly experienced on a particular code base, it's easy to cycle-in a replacement (for any large employer).

To support this, some anecdotal data. Back in 1997 somebody I knew with no programming experience who joined a big Indian Consultancy. They trained him on COBOL and some other technologies that were in high demand for Y2K stuff in the US. He got placed in a lot of small towns where IT back-offices were located (not sure why, maybe because the servers were there?). His US salary was good, but not anything special compared to other developer salaries at the time.

There were a lot of articles back then about how knowing COBOL was a ticket to a great job and salary, but it wasn't all that true back then even with Y2K getting closer.

So you are basically learning a niche language that may or may not last and you may have to move to a less desirable (in terms of availability of tech jobs) place.

The point is that even back then you could scour resumes from US based people or you could contract with a large Indian company and they would make contractual promises about a certain number of trained employees always being on site.

Somebody is going to crib about the quality of these employees, but that isn't the point. The point is that it's easier to hire them than it is to hire you.

I have one anecdote. It may not be enlightening for you at all.

My high school CS teacher made ~$50k per year doing quick contract jobs working on COBOL, mostly for factories in the Ohio area.

These jobs were never posted online. Once the companies found a contractor to fix the systems, they just kept using the same one, not unlike a homeowner who has a favorite plumber.

It's very likely that the majority of the COBOL community is hidden from online searches because churn is low and/or they don't use reddit, StackOverflow, etc.

The things I've read about Haskell remind me of what people are saying about COBOL now. Very few companies use Haskell, but the ones that are using it can sometimes be desperate to find a Haskell expert and will pay a lot for one.

COBOL doesn't have a lot of jobs; the systems that are still running are old, stable, and get rare and mostly minor changes.

There is little and shrinking steady-state demand and that's mostly met by the a dwindling pool of old-timers and internal staff that get trained by their workplace to assist or replace the old-timers.

On the other hand, occasionally one of those big enterprises (public or private) encounters an urgent, immediate need for some new work on one of those systems, and it's those moments where there is an intense premium for COBOL programmers because there's little idle capacity to take up a temporary demand surge. (E.g., right now with some state unemployment systems suddenly needing substantial rules changes and modifications to handle order-of-magnitude volume increases over baseline capacity.)

If you look at the articles about NJ's unemployment systems, the governor is asking for volunteers, not offering jobs with high pay. Read into that whatever you want.

Banking software developer here. Cobol is specialized and mainly for maintenance. In banks. Has been mainly phased out, if it can be.

It is an investment in a dead/dying language. Why is that worth your time and effort? Have you tried Cobol programming? Do you like it? I dropped out of my Cobol class in college. Was mind-numbingly boring and archaic to work with.

Are you trying to find a viable alternative to JavaScript? That pays 6 figures? You could pivot your javascript skills into something like react-native... mobile app development.

> Are you trying to find a viable alternative to JavaScript? That pays 6 figures? You could pivot your javascript skills into something like react-native... mobile app development.

I’m trying to find a slower alternative to JS. Il getting a bit tired of having to constantly learn this week’s JS fashion just to stay relevant. I was hoping to find something more niche and not as glamorous that would give me more time to do things I enjoy instead of work.

I was considering cobol because the spec probably is rather stable, and if it paid well and was in demand then it was a winning combination.

But from your comment and others, it doesn’t seem to be it because overseas sweatshops are already filling the demand.

I wonder where do these people who say cobol pays well and is in demand get their information from. There is no other evidence than “people say”

AFAICT there are lots of viable programming languages that has a more stable ecosystem than JavaScript. Python, C#, Java, maybe Go, are a few that comes to mind.

If you want a stable language that matches with lower stress jobs try Java and work for an established B2B company. Lots of established B2B companies have Java based products they built a few years ago and they need people to work on those products. Assuming they have a healthy revenue stream, they are going to be focused on keeping the system stable and keeping their customers happy. They aren't going to be chasing the latest fad or the updating their Java version as quickly as possible.

One benefit is that if you dislike your job, there are plenty of places looking for Java programmers. Compare that to COBOL, where the market is tiny.

I understand core banking is (was) going towards APIs for JSON output due to regulatory reasons (PSD2 - to clarify, PSD2 doesn't specify JSON, just, it seemed the easiest option where I was) and just letting the rest of the code base sit there / be maintained. Layer upon layer, not great but who wants to re-write a general ledger. Consistent with your comment. OP might be in a sweet spot with this given JS experience and a switch to finance.