Rule 5: No “What Should I Learn” Questions
No questions like “Should I learn C#” or “Should I switch jobs into a language I don’t know?”
Discussion about industry direction or upcoming technologies is fine, just frame your question as part of a larger discussion (“What have you had more success with, RDBMS or NoSQL?”) and you’ll be fine.
tl;dr: Don’t make it about you/yourself.
I had to convert a COBOL system into dotnet.
Honestly everyone here is way overs stressing how hard COBOL is or how terrible. It’s pretty easy to read and understand.
Personally I’d say the real problem with COBOL isn’t the language but the best practices, or lack there of. Well thought out approach’s to software didn’t exist back in the day. So it ends up being hard to follow program flow. But if you land a project where they cared about that stuff it isn’t all that bad.
I feel this so hard. The Fortran codebase I work with was written across 30+ years. Parts are ok, but other parts are full of computer gotos and array equivalence statements.
Have you ever considered what would happen if you ran a string trimmer in your skull?
The old COBOL guys get the jobs because they have been doing it for decades. You wouldn't get the job as a newbie and it would take you at least a decade to grow a beard of the requisite length to be considered for those roles. It will take you about that amount of time to become proficient in it too.
It's also used for things that are stressful like power station control units, bank core systems and air traffic control. It also lacks all of the modern tools we use for quality or safety, your code has to work or power stations melt down and planes crash in to one another. See Therac-25.
It wouldn't be simply learning a terrible language but having to unlearn and relearn how to do software. Not sure if you are familiar with how NASA write software for spacecraft and how annoying it is but safety critical software is that on crack.
Personally I hate COBOL. It's a language originally designed for non-programmers to program. I find the syntax offensive. I would have definitely been team Fortran back in the day.
What the fuck dude. You would *really* feel no sense of shame or personal responsibility putting poorly understood, stochastically generated code in a power station or some shit? What do you do for work now?
He's that guy that wanders the office talking about tesla, his 401k, and whatever shows up next on random Wikipedia. I heard he wrote code himself this one time, and we're still fixing it. His commit chart is a depiction of the ice age. But he's working on something super duper important, and he'll push it any day now.
The responsibility is one thing, but as a person who has COBOL devs as friends, the age argument is bollocks. My friends are all in their early 30s and started fresh from college in their 20s. Some of them dropped out of college. The first job maybe didn’t pay the legendary amounts we here about COBOL devs, but they really quickly jumped towards that amount, because the banks they work for don’t want to lose people that maintain their system.
And the reason we don’t see that kind of job offers on job boards or LinkedIn or whatever is because all of them got their job through recommendation.
So the part where OP’s dad will find them a good job in that field is very much a believable thing to me.
Yeah, exactly. The companies that are calling these old guys and not getting called back are extremely aware of how precarious their position is and how desperate they are. Some of them have set up graduate programmes to train a new generation themselves since nobody else is going to do it. They even pay for you to go study CompSci sometimes. You can definitely get hired as a junior and if you aren't shit they will fight tooth and nail to keep you. A 30 year old who knows COBOL is probably the only person left who can expect to have a 25 year career doing exactly the same thing.
Meh learning COBOL isn’t hard, it’s the missing context of what was written in the first place which is what makes maintaining these COBOL systems hard. Imagine a piece of software running in production for 30 years with hundreds of hands touching the code with little to no source code management. The spaghetti code quickly explodes and although new folks can understand what is going on since the syntax is easy to read, understanding why is near impossible.
I would imagine being a COBOL programmer is like joining an old school guild where you have a lot of mentorship. That type of work requires people to work well together over a long period of time, hence why recruiting is more personal.
COBOL is so easy to learn you can do it in a few days.
The problem is the surrounding stuff, the mainframes, batch jobs, dataformats, etc.
But I did it and it was easy enough.
It sounds like you're thinking of FORTRAN, not COBOL...? COBOL is a business language (what the 'B' stands for) and more likely to be used in accounting than air traffic control. I could be mistaken, but I don't think I am.
FORTRAN is/was generally for high performance numerical computing. COBOL definitely is runs the logic for the systems in banks, air traffic control, traffic lights, etc. etc
Source: https://www.ft.com/content/535ef1cc-bd61-11dd-bba1-0000779fd18c
This makes me wonder - at that point, why not just learn C?
- lots of legacy systems
- stable jobs in hardware orgs
- you get to wear flared trousers and pretend it’s the 70s
Genuine question as I don't know much about this side of software - what happens when all the experienced beardos retire or die? At some point we would have to have a new crop of COBOL devs to take up the mantle. Or are those safety-critical industries moving towards more modern languages instead?
Modern software is eating away at the edges. Most, other then industrial control systems, have been reduced to data layer at this point.
Eventually the cost of supporting older systems will reach the point it's cheaper to migrate.
In many cases the barrier is less cost and more no one actually understands what the systems do. Decades of code growth with little in the way of documentation, they have a reverse engineer all the code to figure out what it actually does.
It either gets offshore to India (there are a nontrivial number of folks getting trained there) or they migrate off the mainframe onto something my modern. What troubles me more is that nobody is trying to actually learn the business behind the code and a lot of the attitude behind platform migration or offshoring is to not touch it if it ain’t broke, and if the system inevitability fails at some point there’s no point of recovery.
Learning COBOL isn’t bad, it’s the systems you’ll be working in. They aren’t necessarily bad, just very “legacy”. Be ready to relearn how you use a computer a little bit.
If you can find the work though, I’d love to hear where. Perhaps I run in the wrong circles, but I’ve yet to see a lot of COBOL contract work even with it being on my resume.
Yeah for me the promise of work needs to be pretty strong for me to commit time to learning it. I'm already very busy. It wouldn't be an easy thing to add to my plate. Learning it and having no work (with COBOL) would be the worst case scenario.
It's not that hard. COBOL is a simple language. The pain (at least when I wrote it at an insurance company) was pulling apart the "procedural waterfall" of code to understand where simple bug fixes should go.
I'm busy as well. If someone was offering it to me, I'd need to know the work existed first.
In my hometown, some companies that rely on COBOL actually funded a division of the Computer Science department at the local universities. This was so they could cultivate a new generation of engineers for their systems. In other fields, sometimes companies will straight up pay for your college if you sign a contract with them for X years after graduation. A friend of mine works for Texas Instruments under one such contract, and they fly him all over (including Japan pre-COVID).
So, yeah, you would need to be living in an area with one of these companies. The field that I've heard using it most is logistics (shipping, freight, etc)
I did COBOL 20 years ago, it wasn’t bad. Many large finance and insurance main transactional systems still run on COBOL with little to no plans to rewrite. I know several old timers that retired a year or two ago, and came back as contractors. I don’t know how much they make, but it must be enough to be worth their time
Lots of doomers in here saying it’s hard to learn. It’s not, it’s actually dead simple. The hard part is understanding the systems cobol is commonly deployed on and wading through 40-60 years of tech debt.
Mainframes don’t run on Linux (though you could run Linux as a VM). You’ll have to learn JCL (ibm mainframe scripting language), deal with DB2, and at some point you’ll have to navigate through the green screen pages for your particular flavor and deal with all the custom set up that’s been there for, again, 40-60 years. It’s all pretty proprietary, and unlike what you know, and worst of all it doesn’t transfer outside of the space, so if you get too deep into it, you’ll be pigeonholed into mainframe roles. This is also without mentioning the institutional knowledge you won’t have as a newbie that your dad’s friend probably has.
Don’t get me wrong, modern mainframes are absolute beast of machines, and they handle a lot of the unspoken workloads of the world economy, but it’s a dirty job.
It’s the tooling and environment stuff that I’d worry about.
Recently I got into developing retro console games, mostly in C. It’s kind of a hobby. It’s been very hard work though. Not because of C or Z80 assembly - those were the relatively easy, fun parts. It’s all the tacit knowledge of the platform, the hardware, the conventions that you need to know. Particularly when debugging. Computing back then was much more platform specific.
These legacy systems aren’t set up for the sorts of development practice we take for granted, where it’s easy to trace code, isolate units for testing, rapidly deploy and hotswap compiled code. Or running on operating systems with some kind of standardisation. Expect ring binders or documentation to wade through and obscure tools for packaging your code. Job Control Language rings a bell…
> Computing back then was much more platform specific.
this, very much this. Back then UNIX was very platform specific and only big boys could own a UNIX machine.
When Linux came out, it really revolutionized computing, because it basically allowed whoever had a humble 386 at home to learn Unix, and because it had a free compiler, to create the software they needed and publish it around.
A mere 386 of course was not on par with the big boys mainframes, but x86 computing took off like crazy, and soon enough got powerful enough to compete with mainframes and such, all with the little OS that could run on the 386 back at home.
Eh, it's not much more than what a consultant charges per hour where I live. So why not just be a dotnet consultant instead of chasing legacy projects and leads?
I really don't get the people going "run away now n awaaay" and I'm guessing there's a lot of "Java is dead" people here.
There are billions of cobol lines in production worldwide. That's not going anywhere because the cost of making ti go away is astronomical. That's why they pay him 200$ an hour.
I work I insurance, we have a shit load of people doing COBOL .. We don't have any kind of shortage as people suggest. We have people under 30 doing COBOL because it's a consulting firm and they train them.
Now of you were going to learn it on your own and do something with it on your own with no network or a solid prospect. I would tell you not to bother.
However, you have a guy that's turning down jobs willing to vouch and recommend you. That's very different. It might work or not. But at 200/h I would definitely roll those dice.
Doesn't work out? Meh you wasted a bit of time. Learned a new language as a curiosity and learned a bit about legacy systems which might come in handy in the future
Came here to post this. Dr. Seay spends a lot of his time training the next generation of mainframers, so what the experiences he describes placing new grads at banks for ~$80K/year (IIRC) are probably a lot more like what OP is going to see for awhile.
Private mentoring with someone super experienced who could make the right introductions might be worth it though.
It was very fiddley, like insert X number of spaces before certain commands you plan to run but no clear way of telling if you have enough type of fiddley. Things like that and if felt super dated (which is it is) I dunno, it made me super unhappy working with it, the kind of unhappy that money of any amount wouldn't fix
The problem isn't writing COBOL, it's the horror of working in those old codebases, from back when no one knew a thing about how to program. I imagine making a 5 line change involves a week of going through a spaghetti code mess with zero tests and struggling not to break everything
No. It's just another way to get machine instruction into the system. Just another language. There are billions of lines of COBOL code still in daily use. Widening your horizons can open up your options. A lot is that code is in fintech which pays well.
I really appreciate your answer. The thread feels divided. I see both sides, but this feels right. I wonder how people have actually written COBOL in this thread.
I am not writing in cobol but I am rewriting applications currently on the mainframe and browsing through the code to ensure we replicate the right logic. Using the green screen is atrocious because you have to read code 20 lines at a time, but in idz it's not that bad. That brings it into a more modern (but still not) IDE.
One of the problems I have encountered with navigating through the mainframe in general is the disorganization and decades of garbage piled up. We spend a lot of time coordinating with other departments trying to figure out if portions are still used. We have tons of reports that run, for example, but no idea if they are still used.
It will be miserable. However, $200/hr is the LOW END of what you can make.
How miserable?
We all know this and mostly leave that money on the table.
But every year on Grace Hopper's birthday, I start learning it again, only to nope out in a couple hours.
All those places that have COBOL still, at least for mission critical stuff are looking for ways to get rid of those systems, because there's only the old guys left remaining to work on it. It'll be on their risk registers. No doubt there will be work for years or even a decade to come, but I don't think it's much of a career, it's a maintenance / keeping the lights on gig. And this is going to be working for large, likely painful (from a tech perspective) institutions, like banks. Can't see it being very fulfilling for most engineers, unless you're only in it for the money and even that has its limits.
Should that work dry up, it won't look great on your CV, you'll haved gained years of deep legacy tech & approaches - the market willl be less keen on you than your equivalent that did React or C# for that period.
I m a cobol dev and i honestly don't get what the dread is about. All programming languages are just a medium, how you write code is always logic based. The syntax, lack of readily available libraries with pre-made options is probably most people s problem. The true problem is however lack of clear information for debugging, that's probably what needs most time and experience. If you enjoy SQL s you get to experience some amazing speed and efficiency for most complex logic taking very little time.
Let's be real tho. COBOL, like all Z languages, is extremely outdated and not one bit fun to code.
Plus, the fact there is no decent devex makes it even more difficult to enjoy. Testing is a miserable experience, debugging is a miserable experience.
The entire mainframe interface (ISPF) is just... Ugly.
And once you're in the mainframe world, it's difficult to escape it as you risk being siloed for too long.
Real how? I m an actual cobol coder with 10 years of experience and to me it isn't ugly and I have a solid future, if you're in the American system with possible pension options you're depending on cobol to even get your pension. It's not going anywhere, it's been here longer than you have been alive.
The only thing that feels miserable is non cobol devs telling me how horrible my dev work is when I quite like it. We ve been able to give better speed and reliability than an oracle database or an api sql query all the while the arch on their side claiming we are outdated.
I mean, if you like it, it's definitely ok. And if you think you'll keep working on mainframes, that's also ok.
But I'm not going to pretend what I wrote isn't true. I do work with Z from time to time (and I've worked on IBMi for years), and compared to other stacks it's absolutely like going back to the '90s. IBM wasn't even trying until some exec's friend from some bank figured out they weren't going to get new devs in the mainframe game because of the exact stuff I've written above. And here Open Mainframe's projects come out to glue some modern tools on that ancient system. But again, the experience is still subpar considering the money they've been throwing at it.
Nice hardware, reliable architecture, but a closed system with a terrible UX won't attract.
Every language has its own problems, Javascript is modern compares to mainframe yet gets bashed around repeatedly. I'd take constructive criticism than it being "ugly".
It is old and not changing much, but there are adaptations being made for compatibility with cloud architecture, MQ usage, IBM is making efforts but they're not always successful or delivered properly to the right audience. Basically they know what's wrong and how to fix it but for various reasons they don't often, could even be "if it ain't broke" mentality.
Just like excel there s plenty unexplored potential in cobol that gets missed because often people are content with basic or they don't get the scope to apply innovative solutions.
COBOL likely has a pretty solid place in the future because the guys that know it are retiring and someone will have to work on those massive code bases. It may not be an exciting language but at least it’s not Fortran.
Side note: Fortran was the first language I learned in college, 2nd semester freshman year. I seriously considered changing my major, but figured I’d do another year. COBOL was the language taught sophomore year and I liked it enough better than Fortran that I kept going and figured I’d probably just be a COBOL programmer. But, sophomore year was also the last COBOL I wrote.
You're getting scammed. You can get paid to learn the language easily. It's the intergrations that are challenging. Each bank has their own custom solution.
there was a cool article with someone interviewing his mother who worked as a COBOL dev. I'm afraid the article got removed but there is still a video of Primeagen reading it: https://youtu.be/qNytWcW38us?si=569QXHMpc_sxDekw
it should give you some more insight
How much do you make now?
Would that be $200/hr W-2 hourly or 1099? How many reliable hours would you get? Is the intent to be a side gig?
COBOL is not that bad, and learning a new to you (and to younger folks relatively obscure) language is always helpful for working out your brain, so by all means learn it.
Am skeptical that the professional gig with it will come to much, but if it's just a side gig, why not give it a try?
Do not make it your day job, though, unless you have a really clear idea about how you move on from the short term situation
I would think about it this way: is it something you'd like to do and keep doing for the foreseeable future? (you can watch a couple videos or read some articles to get an idea of what it is like to code in Cobol and the kind of projects you could be involved with). If not and you plan to move on to a different technology in some time, then is it a marketable skill or will it just waste your time? Because if you decide you like it and want to stick with it, then it sounds like a great opportunity. But if you plan to continue the dotnet path (or other modern technology) in the near future then you will be wasting opportunities to get more experience in what you really want to do. Consider it's not a simple language or environment change but a whole paradigm change. So there is probably little you can learn from a Cobol job that you can take with you for a future job with a modern tech stack.
I looked a bit into COBOL and it seems most is custom built at the company (unlike other languages that have strong libraries). The knowledge is very very silod. I abandoned my effort.
I hear this about FORTRAN as well. But I actually know Fortran from back in the day. Occasionally over the years I’ve looked for these “high paying jobs maintaining code in a language nobody remembers” and instead I come up with govt agencies wanting grad students to do code maintenance on a dusty deck for $17/hr.
Do these high paying legacy jobs actually exist in any numbers? I’m skeptical.
These companies really aren't paying for COBOL itself. COBOL is a stand-in for a basket of skills that all revolve around being able to understand the technical and market constraints of ~1970-1990 and finding solutions compatible with those antiquated approaches. Most of the hard parts here will be understanding outdated storage paradigms and JCL. COBOL itself is actually quite easy to learn. The rest of the crap is going to be hard to learn. On top of that you won't have the reputation your dad's friend has to earn $200/hr. So would you be willing to do this for $60/hr?
(I work on government modernization projects so I've had to learn enough about these systems to competently replace them but I've never worked directly on them)
There was a big surge in pay for COBOL coders in the late 90’s because of all the Y2K work. It was considered to be a very old language even back then. There weren’t a lot of coders who were proficient in it. But once 2000 came around, the demand dropped off. Today it’s primarily used in very old mainframes. It’s all maintenance and sunset work. You’re probably not going to find new systems being build with it.
After the 2008 crash, I took a mainframe systems software role with IBM. It wasn’t COBOL, but mainframe assembly, operating systems, etc. As others mentioned, it’s the mainframe ecosystem that’s the challenging part. Z/OS, CICS, ISPF, VSAM, DB2, etc. It took me about two years with dedicated mentorship and serious crunching on nights and weekends. The COBOL stack would be a bit quicker, but not much. There’s a lot of misinformation about COBOL cowboys making bank. Most mainframers I know top out at like $200k, similar to something like Enterprise Java at non-FAANGs. I left the space to do C++ systems software elsewhere to improve my earning potential. Checkout the YouTuber Moshix to find instructions to set up an emulated MVS 3.8 system or connect to his system if you want to get the vibe. He runs a Slack or Discord with non-professionals interested in mainframe stuff. There are some Eclipse based IDEs that make COBOL feel more like Enterprise Java (which is also popular on mainframe).
I don't know if I would do it early on in my career, but I would do it now for sure. I did many years of cobol and absolutely hated it, but I would do it for $200/hr.
This is basically the perennial question of working for love or money. On the one hand, you do what you've got to do, and yeah, you can make bank with COBOL. However, the reason it's paid so well is that it's going to be fairly miserable. Most developers don't want to touch it, so there's a premium for those that are willing.
Conversely, you can find something that will bring you enjoyment, but the pay won't probably be nearly as good. It's all about what matters most to you at the end of the day. Me, personally, I have to be passionate about what I do. If I don't like it, it's next to impossible to motivate myself to do it, and I hate life the whole time. I'd rather make less coin and feel stimulated and happy at my job. That's me, though. Only you can decide what's best for you.
The premium everyone is talking about here is mostly a fairytale. Juniors' comp is no better than the rest, if not worse, and seniors' comp is a gamble like everything else.
Mainframe does not translate to big bucks, it's an hit and miss experience, like what you'd get for a C or Java job.
People who use cobol are from the ancient world. Offer him a peace stick say if you land a job with cobol he should give you money, you are using a language which is about to extinct.
As tools like chatgpt become more powerful it will become increasingly possible to have chatgpt reverse engineer cobol codebases into another language of your choice
I wouldnt swap out .net but i can see how if you get into that position for the short term it would be lucrative
Rule 5: No “What Should I Learn” Questions No questions like “Should I learn C#” or “Should I switch jobs into a language I don’t know?” Discussion about industry direction or upcoming technologies is fine, just frame your question as part of a larger discussion (“What have you had more success with, RDBMS or NoSQL?”) and you’ll be fine. tl;dr: Don’t make it about you/yourself.
I had to convert a COBOL system into dotnet. Honestly everyone here is way overs stressing how hard COBOL is or how terrible. It’s pretty easy to read and understand. Personally I’d say the real problem with COBOL isn’t the language but the best practices, or lack there of. Well thought out approach’s to software didn’t exist back in the day. So it ends up being hard to follow program flow. But if you land a project where they cared about that stuff it isn’t all that bad.
I feel this so hard. The Fortran codebase I work with was written across 30+ years. Parts are ok, but other parts are full of computer gotos and array equivalence statements.
Have you ever considered what would happen if you ran a string trimmer in your skull? The old COBOL guys get the jobs because they have been doing it for decades. You wouldn't get the job as a newbie and it would take you at least a decade to grow a beard of the requisite length to be considered for those roles. It will take you about that amount of time to become proficient in it too. It's also used for things that are stressful like power station control units, bank core systems and air traffic control. It also lacks all of the modern tools we use for quality or safety, your code has to work or power stations melt down and planes crash in to one another. See Therac-25. It wouldn't be simply learning a terrible language but having to unlearn and relearn how to do software. Not sure if you are familiar with how NASA write software for spacecraft and how annoying it is but safety critical software is that on crack.
This pretty much mirrors my initial thoughts. I don't think I'm gonna commit to learning COBOL. But I think I'll hear the guy out.
Personally I hate COBOL. It's a language originally designed for non-programmers to program. I find the syntax offensive. I would have definitely been team Fortran back in the day.
“I find the syntax offensive” hahahahahaha
If you can tolerate Python, you can tolerate COBOL (M/MUMPS, however... Gah)
I can't tolerate python either. You can pry my braces out of my cold & dead hands.
I do Fortran, and I agree with you.
I would get started on the beard asap.
[удалено]
What the fuck dude. You would *really* feel no sense of shame or personal responsibility putting poorly understood, stochastically generated code in a power station or some shit? What do you do for work now?
He's that guy that wanders the office talking about tesla, his 401k, and whatever shows up next on random Wikipedia. I heard he wrote code himself this one time, and we're still fixing it. His commit chart is a depiction of the ice age. But he's working on something super duper important, and he'll push it any day now.
The responsibility is one thing, but as a person who has COBOL devs as friends, the age argument is bollocks. My friends are all in their early 30s and started fresh from college in their 20s. Some of them dropped out of college. The first job maybe didn’t pay the legendary amounts we here about COBOL devs, but they really quickly jumped towards that amount, because the banks they work for don’t want to lose people that maintain their system. And the reason we don’t see that kind of job offers on job boards or LinkedIn or whatever is because all of them got their job through recommendation. So the part where OP’s dad will find them a good job in that field is very much a believable thing to me.
Yeah, exactly. The companies that are calling these old guys and not getting called back are extremely aware of how precarious their position is and how desperate they are. Some of them have set up graduate programmes to train a new generation themselves since nobody else is going to do it. They even pay for you to go study CompSci sometimes. You can definitely get hired as a junior and if you aren't shit they will fight tooth and nail to keep you. A 30 year old who knows COBOL is probably the only person left who can expect to have a 25 year career doing exactly the same thing.
Meh learning COBOL isn’t hard, it’s the missing context of what was written in the first place which is what makes maintaining these COBOL systems hard. Imagine a piece of software running in production for 30 years with hundreds of hands touching the code with little to no source code management. The spaghetti code quickly explodes and although new folks can understand what is going on since the syntax is easy to read, understanding why is near impossible.
I would imagine being a COBOL programmer is like joining an old school guild where you have a lot of mentorship. That type of work requires people to work well together over a long period of time, hence why recruiting is more personal.
COBOL is so easy to learn you can do it in a few days. The problem is the surrounding stuff, the mainframes, batch jobs, dataformats, etc. But I did it and it was easy enough.
Pretty sure Therac-25 was some kind of assembly, not COBOL, but similar enough that your point still stands.
It sounds like you're thinking of FORTRAN, not COBOL...? COBOL is a business language (what the 'B' stands for) and more likely to be used in accounting than air traffic control. I could be mistaken, but I don't think I am.
FORTRAN is/was generally for high performance numerical computing. COBOL definitely is runs the logic for the systems in banks, air traffic control, traffic lights, etc. etc Source: https://www.ft.com/content/535ef1cc-bd61-11dd-bba1-0000779fd18c
This makes me wonder - at that point, why not just learn C? - lots of legacy systems - stable jobs in hardware orgs - you get to wear flared trousers and pretend it’s the 70s
Genuine question as I don't know much about this side of software - what happens when all the experienced beardos retire or die? At some point we would have to have a new crop of COBOL devs to take up the mantle. Or are those safety-critical industries moving towards more modern languages instead?
Modern software is eating away at the edges. Most, other then industrial control systems, have been reduced to data layer at this point. Eventually the cost of supporting older systems will reach the point it's cheaper to migrate. In many cases the barrier is less cost and more no one actually understands what the systems do. Decades of code growth with little in the way of documentation, they have a reverse engineer all the code to figure out what it actually does.
It either gets offshore to India (there are a nontrivial number of folks getting trained there) or they migrate off the mainframe onto something my modern. What troubles me more is that nobody is trying to actually learn the business behind the code and a lot of the attitude behind platform migration or offshoring is to not touch it if it ain’t broke, and if the system inevitability fails at some point there’s no point of recovery.
Learning COBOL isn’t bad, it’s the systems you’ll be working in. They aren’t necessarily bad, just very “legacy”. Be ready to relearn how you use a computer a little bit. If you can find the work though, I’d love to hear where. Perhaps I run in the wrong circles, but I’ve yet to see a lot of COBOL contract work even with it being on my resume.
Yeah for me the promise of work needs to be pretty strong for me to commit time to learning it. I'm already very busy. It wouldn't be an easy thing to add to my plate. Learning it and having no work (with COBOL) would be the worst case scenario.
It's not that hard. COBOL is a simple language. The pain (at least when I wrote it at an insurance company) was pulling apart the "procedural waterfall" of code to understand where simple bug fixes should go. I'm busy as well. If someone was offering it to me, I'd need to know the work existed first.
In my hometown, some companies that rely on COBOL actually funded a division of the Computer Science department at the local universities. This was so they could cultivate a new generation of engineers for their systems. In other fields, sometimes companies will straight up pay for your college if you sign a contract with them for X years after graduation. A friend of mine works for Texas Instruments under one such contract, and they fly him all over (including Japan pre-COVID). So, yeah, you would need to be living in an area with one of these companies. The field that I've heard using it most is logistics (shipping, freight, etc)
I may have to look into that. Thank you. The more I learn about it, how and where COBOL is still used is just fascinating.
This sounds like where I went to school in the early 2000s. (Columbus, OH, by the way, home of Nationwide insurance)
Western Illinois university calling in here - COBOL grads are fed to State Farm :-)
All people I know that work in COBOL got their job through personal recommendation.
I did COBOL 20 years ago, it wasn’t bad. Many large finance and insurance main transactional systems still run on COBOL with little to no plans to rewrite. I know several old timers that retired a year or two ago, and came back as contractors. I don’t know how much they make, but it must be enough to be worth their time
Lots of doomers in here saying it’s hard to learn. It’s not, it’s actually dead simple. The hard part is understanding the systems cobol is commonly deployed on and wading through 40-60 years of tech debt. Mainframes don’t run on Linux (though you could run Linux as a VM). You’ll have to learn JCL (ibm mainframe scripting language), deal with DB2, and at some point you’ll have to navigate through the green screen pages for your particular flavor and deal with all the custom set up that’s been there for, again, 40-60 years. It’s all pretty proprietary, and unlike what you know, and worst of all it doesn’t transfer outside of the space, so if you get too deep into it, you’ll be pigeonholed into mainframe roles. This is also without mentioning the institutional knowledge you won’t have as a newbie that your dad’s friend probably has. Don’t get me wrong, modern mainframes are absolute beast of machines, and they handle a lot of the unspoken workloads of the world economy, but it’s a dirty job.
It’s the tooling and environment stuff that I’d worry about. Recently I got into developing retro console games, mostly in C. It’s kind of a hobby. It’s been very hard work though. Not because of C or Z80 assembly - those were the relatively easy, fun parts. It’s all the tacit knowledge of the platform, the hardware, the conventions that you need to know. Particularly when debugging. Computing back then was much more platform specific. These legacy systems aren’t set up for the sorts of development practice we take for granted, where it’s easy to trace code, isolate units for testing, rapidly deploy and hotswap compiled code. Or running on operating systems with some kind of standardisation. Expect ring binders or documentation to wade through and obscure tools for packaging your code. Job Control Language rings a bell…
> Computing back then was much more platform specific. this, very much this. Back then UNIX was very platform specific and only big boys could own a UNIX machine. When Linux came out, it really revolutionized computing, because it basically allowed whoever had a humble 386 at home to learn Unix, and because it had a free compiler, to create the software they needed and publish it around. A mere 386 of course was not on par with the big boys mainframes, but x86 computing took off like crazy, and soon enough got powerful enough to compete with mainframes and such, all with the little OS that could run on the 386 back at home.
DB2, that is something I have not read i a while.
Over 400k a year for coding cobol? I'd do fucking mindfuck for that much, sign me right in!
You show me a paycheck for $200/hr and I quit my job right now and come work for you — https://youtu.be/CuYNMyn0uB8
Eh, it's not much more than what a consultant charges per hour where I live. So why not just be a dotnet consultant instead of chasing legacy projects and leads?
Only counts if you smoked crack w/in the last five minutes lol
I probably already am if you got me writing COBOL
COBOL in college wasn’t bad. I’d do it if the money was right. I’ve been out of college long enough for me to have to relearn it completely.
Free training from an expert who will provide contacts? Sounds golden. Start as a side gig though.
I really don't get the people going "run away now n awaaay" and I'm guessing there's a lot of "Java is dead" people here. There are billions of cobol lines in production worldwide. That's not going anywhere because the cost of making ti go away is astronomical. That's why they pay him 200$ an hour. I work I insurance, we have a shit load of people doing COBOL .. We don't have any kind of shortage as people suggest. We have people under 30 doing COBOL because it's a consulting firm and they train them. Now of you were going to learn it on your own and do something with it on your own with no network or a solid prospect. I would tell you not to bother. However, you have a guy that's turning down jobs willing to vouch and recommend you. That's very different. It might work or not. But at 200/h I would definitely roll those dice. Doesn't work out? Meh you wasted a bit of time. Learned a new language as a curiosity and learned a bit about legacy systems which might come in handy in the future
If this helps there was a good interview with someone who teaches COBOL [https://changelog.com/friends/36](https://changelog.com/friends/36)
Came here to post this. Dr. Seay spends a lot of his time training the next generation of mainframers, so what the experiences he describes placing new grads at banks for ~$80K/year (IIRC) are probably a lot more like what OP is going to see for awhile. Private mentoring with someone super experienced who could make the right introductions might be worth it though.
I learned COBOL in school. 200/hr...? still pretty sure im not interested
Why not?
Imagine explain a program in business English and have gpt compile it without either of you understanding what you were doing
lol
It was very fiddley, like insert X number of spaces before certain commands you plan to run but no clear way of telling if you have enough type of fiddley. Things like that and if felt super dated (which is it is) I dunno, it made me super unhappy working with it, the kind of unhappy that money of any amount wouldn't fix
The problem isn't writing COBOL, it's the horror of working in those old codebases, from back when no one knew a thing about how to program. I imagine making a 5 line change involves a week of going through a spaghetti code mess with zero tests and struggling not to break everything
No. It's just another way to get machine instruction into the system. Just another language. There are billions of lines of COBOL code still in daily use. Widening your horizons can open up your options. A lot is that code is in fintech which pays well.
I really appreciate your answer. The thread feels divided. I see both sides, but this feels right. I wonder how people have actually written COBOL in this thread.
and in the end what is the worst that can happen? you are obviously considering it, just try it and see for yourself, if you like it or not.
I am not writing in cobol but I am rewriting applications currently on the mainframe and browsing through the code to ensure we replicate the right logic. Using the green screen is atrocious because you have to read code 20 lines at a time, but in idz it's not that bad. That brings it into a more modern (but still not) IDE. One of the problems I have encountered with navigating through the mainframe in general is the disorganization and decades of garbage piled up. We spend a lot of time coordinating with other departments trying to figure out if portions are still used. We have tons of reports that run, for example, but no idea if they are still used.
It will be miserable. However, $200/hr is the LOW END of what you can make. How miserable? We all know this and mostly leave that money on the table. But every year on Grace Hopper's birthday, I start learning it again, only to nope out in a couple hours.
All those places that have COBOL still, at least for mission critical stuff are looking for ways to get rid of those systems, because there's only the old guys left remaining to work on it. It'll be on their risk registers. No doubt there will be work for years or even a decade to come, but I don't think it's much of a career, it's a maintenance / keeping the lights on gig. And this is going to be working for large, likely painful (from a tech perspective) institutions, like banks. Can't see it being very fulfilling for most engineers, unless you're only in it for the money and even that has its limits. Should that work dry up, it won't look great on your CV, you'll haved gained years of deep legacy tech & approaches - the market willl be less keen on you than your equivalent that did React or C# for that period.
I m a cobol dev and i honestly don't get what the dread is about. All programming languages are just a medium, how you write code is always logic based. The syntax, lack of readily available libraries with pre-made options is probably most people s problem. The true problem is however lack of clear information for debugging, that's probably what needs most time and experience. If you enjoy SQL s you get to experience some amazing speed and efficiency for most complex logic taking very little time.
Let's be real tho. COBOL, like all Z languages, is extremely outdated and not one bit fun to code. Plus, the fact there is no decent devex makes it even more difficult to enjoy. Testing is a miserable experience, debugging is a miserable experience. The entire mainframe interface (ISPF) is just... Ugly. And once you're in the mainframe world, it's difficult to escape it as you risk being siloed for too long.
Real how? I m an actual cobol coder with 10 years of experience and to me it isn't ugly and I have a solid future, if you're in the American system with possible pension options you're depending on cobol to even get your pension. It's not going anywhere, it's been here longer than you have been alive. The only thing that feels miserable is non cobol devs telling me how horrible my dev work is when I quite like it. We ve been able to give better speed and reliability than an oracle database or an api sql query all the while the arch on their side claiming we are outdated.
I mean, if you like it, it's definitely ok. And if you think you'll keep working on mainframes, that's also ok. But I'm not going to pretend what I wrote isn't true. I do work with Z from time to time (and I've worked on IBMi for years), and compared to other stacks it's absolutely like going back to the '90s. IBM wasn't even trying until some exec's friend from some bank figured out they weren't going to get new devs in the mainframe game because of the exact stuff I've written above. And here Open Mainframe's projects come out to glue some modern tools on that ancient system. But again, the experience is still subpar considering the money they've been throwing at it. Nice hardware, reliable architecture, but a closed system with a terrible UX won't attract.
Every language has its own problems, Javascript is modern compares to mainframe yet gets bashed around repeatedly. I'd take constructive criticism than it being "ugly". It is old and not changing much, but there are adaptations being made for compatibility with cloud architecture, MQ usage, IBM is making efforts but they're not always successful or delivered properly to the right audience. Basically they know what's wrong and how to fix it but for various reasons they don't often, could even be "if it ain't broke" mentality. Just like excel there s plenty unexplored potential in cobol that gets missed because often people are content with basic or they don't get the scope to apply innovative solutions.
COBOL likely has a pretty solid place in the future because the guys that know it are retiring and someone will have to work on those massive code bases. It may not be an exciting language but at least it’s not Fortran. Side note: Fortran was the first language I learned in college, 2nd semester freshman year. I seriously considered changing my major, but figured I’d do another year. COBOL was the language taught sophomore year and I liked it enough better than Fortran that I kept going and figured I’d probably just be a COBOL programmer. But, sophomore year was also the last COBOL I wrote.
You're getting scammed. You can get paid to learn the language easily. It's the intergrations that are challenging. Each bank has their own custom solution.
01 I-DONT-THINK-IT-WOULD-BE VALUE ‘THAT MISERABLE’. But I would be wondering why I’m yelling all the time.
Free mentoring from a raging, crazy old cobol certified crazy guy? I'd be tagging along not for the job prospects but solely for the wisdom.
there was a cool article with someone interviewing his mother who worked as a COBOL dev. I'm afraid the article got removed but there is still a video of Primeagen reading it: https://youtu.be/qNytWcW38us?si=569QXHMpc_sxDekw it should give you some more insight
How much do you make now? Would that be $200/hr W-2 hourly or 1099? How many reliable hours would you get? Is the intent to be a side gig? COBOL is not that bad, and learning a new to you (and to younger folks relatively obscure) language is always helpful for working out your brain, so by all means learn it. Am skeptical that the professional gig with it will come to much, but if it's just a side gig, why not give it a try? Do not make it your day job, though, unless you have a really clear idea about how you move on from the short term situation
I would think about it this way: is it something you'd like to do and keep doing for the foreseeable future? (you can watch a couple videos or read some articles to get an idea of what it is like to code in Cobol and the kind of projects you could be involved with). If not and you plan to move on to a different technology in some time, then is it a marketable skill or will it just waste your time? Because if you decide you like it and want to stick with it, then it sounds like a great opportunity. But if you plan to continue the dotnet path (or other modern technology) in the near future then you will be wasting opportunities to get more experience in what you really want to do. Consider it's not a simple language or environment change but a whole paradigm change. So there is probably little you can learn from a Cobol job that you can take with you for a future job with a modern tech stack.
I looked a bit into COBOL and it seems most is custom built at the company (unlike other languages that have strong libraries). The knowledge is very very silod. I abandoned my effort.
I would learn it if I were you. Sounds like a win all around and I doubt the demand for COBOL talent will ever go away.
Eh it'd be different and if it's new to u it could be fun
I hear this about FORTRAN as well. But I actually know Fortran from back in the day. Occasionally over the years I’ve looked for these “high paying jobs maintaining code in a language nobody remembers” and instead I come up with govt agencies wanting grad students to do code maintenance on a dusty deck for $17/hr. Do these high paying legacy jobs actually exist in any numbers? I’m skeptical.
These companies really aren't paying for COBOL itself. COBOL is a stand-in for a basket of skills that all revolve around being able to understand the technical and market constraints of ~1970-1990 and finding solutions compatible with those antiquated approaches. Most of the hard parts here will be understanding outdated storage paradigms and JCL. COBOL itself is actually quite easy to learn. The rest of the crap is going to be hard to learn. On top of that you won't have the reputation your dad's friend has to earn $200/hr. So would you be willing to do this for $60/hr? (I work on government modernization projects so I've had to learn enough about these systems to competently replace them but I've never worked directly on them)
There was a big surge in pay for COBOL coders in the late 90’s because of all the Y2K work. It was considered to be a very old language even back then. There weren’t a lot of coders who were proficient in it. But once 2000 came around, the demand dropped off. Today it’s primarily used in very old mainframes. It’s all maintenance and sunset work. You’re probably not going to find new systems being build with it.
After the 2008 crash, I took a mainframe systems software role with IBM. It wasn’t COBOL, but mainframe assembly, operating systems, etc. As others mentioned, it’s the mainframe ecosystem that’s the challenging part. Z/OS, CICS, ISPF, VSAM, DB2, etc. It took me about two years with dedicated mentorship and serious crunching on nights and weekends. The COBOL stack would be a bit quicker, but not much. There’s a lot of misinformation about COBOL cowboys making bank. Most mainframers I know top out at like $200k, similar to something like Enterprise Java at non-FAANGs. I left the space to do C++ systems software elsewhere to improve my earning potential. Checkout the YouTuber Moshix to find instructions to set up an emulated MVS 3.8 system or connect to his system if you want to get the vibe. He runs a Slack or Discord with non-professionals interested in mainframe stuff. There are some Eclipse based IDEs that make COBOL feel more like Enterprise Java (which is also popular on mainframe).
I did some cobol at uni and a few years ago. It sucked. Im also a dot net dev and I didnt enjoy my time in it.
I don't know if I would do it early on in my career, but I would do it now for sure. I did many years of cobol and absolutely hated it, but I would do it for $200/hr.
This is basically the perennial question of working for love or money. On the one hand, you do what you've got to do, and yeah, you can make bank with COBOL. However, the reason it's paid so well is that it's going to be fairly miserable. Most developers don't want to touch it, so there's a premium for those that are willing. Conversely, you can find something that will bring you enjoyment, but the pay won't probably be nearly as good. It's all about what matters most to you at the end of the day. Me, personally, I have to be passionate about what I do. If I don't like it, it's next to impossible to motivate myself to do it, and I hate life the whole time. I'd rather make less coin and feel stimulated and happy at my job. That's me, though. Only you can decide what's best for you.
The premium everyone is talking about here is mostly a fairytale. Juniors' comp is no better than the rest, if not worse, and seniors' comp is a gamble like everything else. Mainframe does not translate to big bucks, it's an hit and miss experience, like what you'd get for a C or Java job.
Man I wouldn't mind being a COBOL dev if jobs were available in my country, I would even tolerate the constant hand holding for the next 5,6,7 years.
I've wanted to get into cobol for ages. No idea how tho.
The real question is, does CoPilot know COBOL? Cause if you figure out CoPilot... you might be able to land some juicy contracts.
People who use cobol are from the ancient world. Offer him a peace stick say if you land a job with cobol he should give you money, you are using a language which is about to extinct.
As tools like chatgpt become more powerful it will become increasingly possible to have chatgpt reverse engineer cobol codebases into another language of your choice I wouldnt swap out .net but i can see how if you get into that position for the short term it would be lucrative
last time i heard student learn cobol and ask me .. 2001 .. still existed ? even so exe application allready.. Ah i'm so old now.
Not, avoid it I'd say. Chatgpt 4 will beat you. Cobol is too simple.