3 ms·

Banks, insurance companies, in-house IT at large corps and govs is where you will still find COBOL. By the way if you are already a reasonably good programmer

Banks, insurance companies, in-house IT at large corps and govs is where you will still find COBOL. By the way if you are already a reasonably good programmer you can pick up COBOL in a few weeks. It's a very straightforward language. Getting familiar with how things are done on a mainframe will take longer.

joshocar 4y ago
My friend is a manager at a big insurance company. They have a bunch of legacy stuff in COBOL.
the_af 4y ago
Agreed on everything you say, except I still find it curious why these seasonal "let's learn COBOL" posts find a place here on HN. I mean, yes, there's a challenge in navigating boring legacy COBOL banking systems, which follow no conventions, were created before code versioning was a thing, or best practices for that matter. Yes, it's challenging and therefore of interest to hackers, but still... ... striking my fingers with a hammer is similarly interesting and challenging, but why would I want to do it?
- throwawayboise 4y ago
  I would not be so sure on the "follow no conventions, created before code versioning was a thing" COBOL shops in my (admittedly limited experience in the early 1990s) had conventions, standard skeleton code for various things (referred to as copybooks) and source code control of a sort (very centralized of course, since everything was centralized). They definitely had separated "regions" for dev, test, and production where I worked, and a process for moving code changes to production. In my experience (as a staff consultant with a major firm), if they had consultants building systems, they certainly had a defined methodology, as consulting firms love that. I'll grant that there may have been a wide range of variance on this sort of thing. Just as there is today in many shops. I'm also not trying to sell anyone on the idea. Going back to COBOL would be about the last thing I'd want to do personally, even if there were good money in it.
  - the_af 4y ago
    Interesting. That wasn't my experience working at a bank, or my dad's, but it was the same bank ;)

joshocar 4y ago

My friend is a manager at a big insurance company. They have a bunch of legacy stuff in COBOL.

the_af 4y ago

Agreed on everything you say, except I still find it curious why these seasonal "let's learn COBOL" posts find a place here on HN. I mean, yes, there's a challenge in navigating boring legacy COBOL banking systems, which follow no conventions, were created before code versioning was a thing, or best practices for that matter. Yes, it's challenging and therefore of interest to hackers, but still... ... striking my fingers with a hammer is similarly interesting and challenging, but why would I want to do it?

throwawayboise 4y ago
I would not be so sure on the "follow no conventions, created before code versioning was a thing" COBOL shops in my (admittedly limited experience in the early 1990s) had conventions, standard skeleton code for various things (referred to as copybooks) and source code control of a sort (very centralized of course, since everything was centralized). They definitely had separated "regions" for dev, test, and production where I worked, and a process for moving code changes to production. In my experience (as a staff consultant with a major firm), if they had consultants building systems, they certainly had a defined methodology, as consulting firms love that. I'll grant that there may have been a wide range of variance on this sort of thing. Just as there is today in many shops. I'm also not trying to sell anyone on the idea. Going back to COBOL would be about the last thing I'd want to do personally, even if there were good money in it.
- the_af 4y ago
  Interesting. That wasn't my experience working at a bank, or my dad's, but it was the same bank ;)