3 ms·

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

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).

apohn 7y ago
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.

apohn 7y ago

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.