4 ms·
This project made the rounds a couple of years (months?) ago. Always accompanied by mentions of companies having a hard time hiring engineers to work on COBOL c
by vmsp 4y ago
This project made the rounds a couple of years (months?) ago. Always accompanied by mentions of companies having a hard time hiring engineers to work on COBOL codebases. I've never had the luck of stumbling on one of these. Maybe because I'm not based in the US or just didn't look hard enough. It'd certainly be cool to take a peek at that code.
- bryanrasmussen 4y agoAbout 20+ years ago a friend of mine and I had just started a company in Denmark, and we got a call from a bank that wanted to know if we had any experts in 'protocol' design, and if we had anyone that knew COBOL. These were not our specialties but at least have had one contact.
- throwawayboise 4y agoBanks, 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 agoMy friend is a manager at a big insurance company. They have a bunch of legacy stuff in COBOL.
- the_af 4y agoAgreed 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 agoI 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 agoInteresting. That wasn't my experience working at a bank, or my dad's, but it was the same bank ;)
- the_af 4y agoNah, your intuition is right: there are not that many jobs for COBOL (not outside boring legacy maintenance jobs for banking systems). Unlike what recurring posts on HN would have you believe, it's also not the way to a high paying job, either.
- christophilus 4y agoI worked with a guy who had the systems manual for a US nuclear missile facility. (I have no idea how he got his hands on it.) It had a bunch of COBOL in it.