I don't know about fun, but maybe you can cosplay a1970's/1980's developer. The press (and many managers, directors, and even developers) treat COBOL knowledge

I don't know about fun, but maybe you can cosplay a1970's/1980's developer. The press (and many managers, directors, and even developers) treat COBOL knowledge as something that was doled out between 1965 and 1985 and then the world just ran out of it. Policy and decisions are made around COBOL as if it's impossible to understand and all knowledge has been lost. That leads to some pretty crazy situations. It's a language that's built for one purpose, business style applications like CRMs or accounting systems. It's not mystically bad or so undecipherable. It's actually a pretty simple language. If you're consulting/contracting developer, or an in-house developer at a bank, insurance company, etc., you should learn it. Even if you don't do anything with it, you can pick up a used book on COBOL and get most of the regular patterns and practices. Learning the basics of the language itself, if you've already a competent programmer, won't take you long. Maybe a half dozen weekends. But COBOL exists in an environment (normally IBM mainframes) that does a lot of the other lifting. CICS is an application server for COBOL (essentially). JCL manages what job to run and when. VSAM for indexed files or DB2 are the most common databases. And WebSphere for messaging. Becoming a 'real' COBOL developer on a mainframe is maybe 33% COBOL and the rest a miasma of mainframe-isms. And unlike Linux, there's no 'free' equivalent to a mainframe. (Although you can spend about $40 a day accessing a mainframe on IBM's cloud). A few weekends won't turn you into a COBOL migration expert, but you can at least join the rest of us, rolling our collective eyes, when the governor of New Jersey asks for volunteer cobalt [sic] programmers because some key system is breaking down.