[benjaminpv]

COBOL was actually in the CS curriculum for my university, a fact that several of my friends brought up when the 'COVID is prompting a real need for COBOL programmers in light of the need to change benefits rules and unemployment!' stories were a regular feature on the nightly news.

'You should do it, man!' Yeah, sure. I'd already suffered through the liquidation of my entire department in 2018, the prospect of the heat around COBOL dying down and facing that once again with the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV during my next round of interviews didn't seem at all appealing.

That mentality should set the expectation for anyone looking into a COBOL job. It's not just this job, it's the next one.

[avgDev]

If you know COBOL and know other languages and are fluent in "current" tech, then I see nothing wrong with consulting for $300 an hour doing some COBOL.

Company I work for still uses AS400, which has been released in 1988 just after I was born. We have a dev who supports it. This isn't a small company either.

COSTCO is still using and a lot of huge organizations.

I'm focused on newer tech C#, .NET, Blazor but I do interact with DB2 database which is the backbone of that old system.

At one of my interviews somewhere I mentioned that a lot of apps I'm writing are just extending AS400 and the dude interviewing me was really hyped up. He has spent a lot of time with the green screen in his younger years. The job had nothing to do with AS400, but that conversation got me an easy offer.

[bluGill]

Most consultants cannot get $300/hour for COBOL though. It is those who have specific other knowledge - like experience in the system before they retired who can get that much.

[JohnFen]

> the additional stain of 'oh, what've you been doing? Cool, popular JS frameworks? No, COBOL? Pass.' on my CV

That's pretty much the last thing that I'd worry about. A company that evaluates potential hires that way is not a company that's worth working for, in my opinion. And most companies I've encountered wouldn't think that way.

[SamuelAdams]

You would be surprised. Don’t get me wrong I would love for companies to not show prejudice based on a candidate’s current tech stack.

However once you are outside of the SV bubble you will notice a lot of companies dismiss candidates based on their tech stack. The only time I’ve ever seen an inexperienced tech stack hire is from personal referrals from someone already working at said company.

[JohnFen]

> once you are outside of the SV bubble you will notice a lot of companies dismiss candidates based on their tech stack.

My experience is entirely outside the SV crowd.

[7thaccount]

It's the same reason why I opted to spend only minimum time with the dying tech in my old role and find something more broadly applicable. You're super important until you're not, so general tech that is useful in many areas is a lot safer.

Cobol ain't going away anytime soon, but it certainly might limit what jobs you can get other places depending on the hiring algorithm.

[guestbest]

Even important people aren’t compensated based on their importance but their marketability. Also, pay is usually just enough to prevent employees from leaving to a competing jobs. Too much institutional knowledge can ironically leave an employee uncompetitive in the market.

[7thaccount]

Agree. Institutional knowledge is vastly underrated. A lot of jobs exist where the knowledge IS the employee value and not just some crank-turning process that can be taught to someone in a few months. It can take years to adequately understand an organization's tools, software architecture, customers, what works and what doesn't...etc.

[haskellandchill]

You don't really want to work with those people anyway. Some hiring managers will see it as a cool thing. As long as you do a project in whatever you want to target next to stay fresh you shouldn't have any problems except from those who hire superficially.

[sillybov3456]

This is all based on a myth though, primarily the myth that "only COBOL" developers are a common thing (people believe this for COBOL even though it's never really been a thing for other languages, wasn't even ever really a thing on mainframes, increasingly they are majority Java).

What I'm getting at is that you aren't going to find a ton of jobs where you are working on COBOL but somehow avoiding Java when the two are connected at the hip on the platforms they are used on.

[skissane]

> This is all based on a myth though, primarily the myth that "only COBOL" developers are a common thing

Anyone who knows anything about COBOL knows that there’s rarely such a thing as “only COBOL”. The majority of the remaining COBOL shops are IBM mainframe, which means it isn’t just COBOL-CICS, JCL, VSAM, IMS, DB2, TSO, ISPF are all in the mix as well (maybe not all of them at the one site). And if you aren’t doing it on an IBM mainframe, it is probably deeply integrated into some other platform - e.g. PeopleSoft still uses COBOL for some of its batch jobs (especially payroll), and while I’ve never looked at its COBOL code, I’m sure it isn’t vanilla COBOL either, it has some PeopleSoft specific calls in it. Or maybe you are doing Oracle Pro*COBOL (SQL precompiler for the Oracle RDBMS). It’s really no different than Java - who does “just Java”, as opposed to J2EE or Spring or whatever?