Do You Know Cobol? If So, There Might Be a Job for You
wsj.com
wsj.com
Enough with the COBOL shortage myth. Don't be fooled, not being popular is not the problem. The problem is COBOL jobs aren't competitive, they often even pay worse than other tech jobs. That's why they are either being outsourced or offered to 60 year olds in their spare time. (So arguably they're not that mission-critical, either.)
But then who is writing articles with a false premise and why? Why would a news outlet (and I use that term loosely) even feature an article that ostensibly is to get more programmers to do COBOL cheaper? I don't even understand the agenda here - is there some kind of meta-game? The best I can think of is they're hedging their bets for when a bank fucks up, but even that seems pathetic. Maybe it's just COBOL turns out to be great clickbait for programmers.
Usually you see more of this on non-mainstream topics or stories that don't get much traction because there will be no backlash.
In this case it's almost too obvious whom the press release was sent out on behalf of ("Cobol Cowboys").
Max Colchester is a U.K. banking correspondent for the WSJ in London. Previously WSJ correspondent in Paris covering fashion, nuclear energy and politics. He is @MaximColch on Twitter.
So the main thing is, the author - because of his background - likely has no idea that this is a recurring theme over decades, that the world nevertheless hasn't run out of COBOL programmers, and that it's an IT job companies today are as likely to outsource to the lowest bidder as any other job (whether that's a good idea or not).
* Putting my career on a trajectory where I am using a dying technology. Unless it paid 3x-5x what I could make using a JVM language (my current career path), the risk/reward isn't there. So market forces will need to drive the cost of salaries up even farther before I consider a jump.
* Outdated development methodologies. My experience with COBOL so far is a lot of entrenched practices that we later learned are inefficient. Both tools and management have been extraordinarily reluctant to improvement and change. I'm not willing to undertake the additional stress to deal with PITA, so until the management over these ares is forced into retirement, companies will endure a shortage of fresh talent.
I don’t blame the college. But it was a choice and for me it was a good one.
In a age when most things come with snazzy oneliners and docker images trying to learn COBOL is an esoteric endevour. The language has its warts and quirks, but it's nothing too crazy. Same with TSO and learning JCL, it's orthogonal to the current landscape.
(Not saying I wouldn't love to be doing in here in Canada)
Fun fact: The current version of IBM Cobol has JSON GENERATE and JSON PARSE, so you can whip up endpoints that interact directly with a mainframe (as long as your convert the code page at the network boundary). Never thought I'd be able to use React and Cobol backed by DB2 in 2018.
It's the business knowledge that really matters. I think this is true no matter what languages and toolsets are used-- in the end, it turns out to be the surrounding information that's of value.
How about salaries?
COBOL in Indian offshore companies is often a shorthand for Mainframe experience. And many people do Java on Mainframes along with COBOL.
>>These days, most of the SAP related jobs are outsourced to India.
Been happening since more than a decade. You could point to any random tech, and some one in an big IT offshore firm will be working on it.
>>How can one expect that the same fate won't befall those who want to master COBOL now?
What fate? Until a while ago, mainframe skills were one of the most important ones in the industry.
>>How about salaries?
If you work for somebody through a third party contracting firm, your salary is going to be low. Not just if you do COBOL, but any tech.
FTFY.
No programming language requires proximity. The only jobs you can expect to never be offshored are in (literal) plumbing.
This said, anything involved with Very Big Companies is probably more at risk, because it makes more sense for them to move entire departments offshore just to save a few percentage points on aggregate costs (actual productivity be damned). So I expect this will soon happen to the likes of Salesforce, if it's not already. AWS is definitely already happening.
Also anything getting too mainstream, because then it makes sense for outsourcers to invest in training high numbers of people. I expect the market to soon be flooded by Python outsourcers, now that it's making real inroads in the enterprise space (with bigdata etc).
Can confirm, I live in the capital city of an Eastern European country and I've been approached by a AWS recruiter a couple of months ago, she told me they were about to open a big new office in here. I think they were quite desperate to get their share of hirings because they had approached me even though there was no mention on my LinkedIn profile of C++ or Java, which was a major part of the job requirements.
> I expect the market to soon be flooded by Python outsourcers,
Fortunately or not there aren't that many Python programmers out here to speak of (I'm talking about Eastern Europe, maybe things in India and South-East Asia are different). I should know, because I've been programming Python for a living for 13 years now and the market for Python programmers isn't a large one. Yeah, I did ok, as in there are small shops that pay decent money for Python programmers, and from time to time there's even a big outsourcing company desperate to hire Python programmers because a new foreign client has arrived with a Python project on their doorsteps, but more often than not Python is still looked as a "scripting language" and as a "programming language for non-important and non-enterprisey stuff".
Just recently a friend of mine that used to work for a major outsourcer based in this area (they have big Western clients, you probably interact with some of their code each day) told me that their company puts people like Python programmers that they intend to hire on a special list (and probably Ruby programmers, too), as in they're not seen as long-term employees, more like project-based (see the part above about Python projects coming from foreign clients), as the focus is mostly on Java and probably some C# and C++, but mostly Java.
Tips : Oracle feels the same, we're moving to Posgtresql wherever possible. So my career path is basically set : Java will stay on top because there's no language that is better in my segment (batch processing, long lived code, just a hell of a business logic, thousands of rules) and Oracle will be pushed out by in place replacement like postgres. I'm gonna die in an open source world :-)
I'm not saying you're wrong, but I feel like there's a piece there that's missing.
The mechanics of the language will be a very minor speed hump compared to changing problem domains. You can signal for that with specific programming languages, but realistically a hiring manager should be most interested in finding someone who understands the core concepts of the problems at hand rather than any specific language.
If solving a problem implies directly accessing a CPU register then realistically that part of the problem is going to get solved using Assembly. If twiddling bits on the CPU isn't needed then other languages will just be faster to move from nothing -> problem solved -> solution in maintenance mode so Assembly should be avoided. This decision doesn't really hinge on the programmers preferences.
I'd also presume that more companies would ask them to do so than those who have legitimate business reasons to write something in assembly. We are long past the age of resource-constrained architecture hacks. The closest most people should be getting to metal is ANSI/ISO C, and the others are all writing compilers or doing extreme optimization stunts.
Can I write in assembly? Yes. Should I write in assembly? Hell no.
Those companies that still require COBOL/mainframe programmers have had literally decades to watch the center of mass of the software industry move away from that, and then still make a conscious decision to pursue a dead-end path to obsolescence.
Assembly isn't Linear A.
COBOL? :)
That pays just over minimum wage.
The conversion/adapter tools exists. It's not a technical issue.
The problem is that cobol applications are normally monolithic, and a migration to another system represents an huge risk because: 1) you migrate like a Big Bang migration, or; 2) you migrate step by step.
Imagine a bank with applications running at 30 or 40 years without problems... Nobody in his perfect judgment will accept to have a Big Bang migration. The risk is too high.
For migrating step by step, you must have a good bussiness case (it must compensate the risk), opportunity (you must be able to keep working in the Bussiness As Usual) and you must have the right people (people that have the knowledge in organization). If you don't have this three things it will be very hard to migrate Cobol to another language/platform.
Usually Cobol is used in mainframe, so the right aproach (with less risk) IMHO is to migrate first COBOL from z/os to a Cobol in another platform (windows/*nux whatever), and then migrate Cobol gradually to another language.
> Hi! First post on here.
Welcome, and very nice post. :)
There was a post on here not too long ago about COBOL's decimal arithmetic -- if you're not careful, your Java / Python / Ocaml is going to give you different numbers. So on the "core data model" front, there's more than meets the eye. Add to that the barrier to entry of working on mainframes: even if you install an emulator and play around with COBOL, you don't have a big COBOL codebase to work with, so you have no idea what you're going to see in a production system that was written 45 years ago.
https://news.ycombinator.com/item?id=17636029
Not that I really believe we're headed for a COBOL crisis. COBOL systems will no doubt continue to rust in place and eventually reach irrelevance as they're decommissioned one by one during horribly mismanaged bank mergers. The exception is the federal government of the U.S., which will surely continue operating its COBOL systems until the end of time.
Check the COBOL job postings, and you'll see desired skills in TSO, JCL, CICS, Natural/Adabase, VSAM, etc. Or equivalents of those for OS/400, MPE, or VMS mid-range platforms.
I started with COBOL. If the freelance gigs continue on, maybe I'll wind down my career with a little part-time, once-in-a-while COBOL work.
It might just be nostalgia, but I miss that environment a little bit.
In the UK, £20k is below average for a junior programmer straight out of university. For example, we've just employed such a person for £25k, in a PHP role.
However, the jump to £40k, provided that the qualifying period wasn't too long, would shortcut several years of career development for a recent graduate. I'd say that's a good deal, except that I'd be concerned about the long term prospects for a COBOL programmer in the UK.
(Being paid to learn a skill from scratch does sound pretty objectively good, though.)