I won't say yes or no, but here is my experience:
Once you know a few programming languages, learning an extra is really easy. And COBOL is among the more easy.
It is good to start with a reasonably designed mainstream language like Python, Java, C#, Go,... and learn to think like a programmer. Then pick a few weirdos like lisp, prolog, haskell, and learn what languages can provide if stretched. COBOL, Basic, PHP,... are today less well designed language that will teach you bad habits. As a first language, you'll have to unlearn things to grow.
Cobol programmers tend to be less paid and work slowly with gnarly code bases. By definition, you work for businesses that are bureaucratic and slow in changing anything. Your colleagues will be near pension age. Do you want this company culture?
You will have work forca long time, of course.
Users already know you'll answer that lots of their questions are impossible. It's easy to say no to them when they e.g. request a strange UI change.
Being a (human) translator between cobol and the rest of the company is a nice path to architect. It's rare to find a programmer talking to both sides of the IT world.
Cobol itself isn't the biggest problem. Even the mainframe isn't. But everything else will be bespoke to the company, underdocumented, hard to learn. That may include the text editor you use.
Once you know a few programming languages, learning an extra is really easy. And COBOL is among the more easy.
It is good to start with a reasonably designed mainstream language like Python, Java, C#, Go,... and learn to think like a programmer. Then pick a few weirdos like lisp, prolog, haskell, and learn what languages can provide if stretched. COBOL, Basic, PHP,... are today less well designed language that will teach you bad habits. As a first language, you'll have to unlearn things to grow.
Cobol programmers tend to be less paid and work slowly with gnarly code bases. By definition, you work for businesses that are bureaucratic and slow in changing anything. Your colleagues will be near pension age. Do you want this company culture?
You will have work forca long time, of course.
Users already know you'll answer that lots of their questions are impossible. It's easy to say no to them when they e.g. request a strange UI change.
Being a (human) translator between cobol and the rest of the company is a nice path to architect. It's rare to find a programmer talking to both sides of the IT world.
Cobol itself isn't the biggest problem. Even the mainframe isn't. But everything else will be bespoke to the company, underdocumented, hard to learn. That may include the text editor you use.