Should I learn COBOL at 14yo in 2025?

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.

Cobol by itself is quite simple, it’s the whole code and architecture that is convoluted.

I agree with the others - do whatever you think is fun and inferesting at this age. Too many things will change before you get to the job market.

Having said that, reading up about Cobol can be fun and interesting, and unique.

I can also recommend this book about working with legacy systems. It makes for an interesting read:

https://a.co/d/4r4Svx8

(And also other classical books like Pragmatic Programmer etc)

The largest bank in Sweden offers a free 16 week COBOL training course and basically a guarantees job if you pass. That's how desperate they are to hire new COBOL developers.

But it's worth noting that what most of the places hiring COBOL developers actually need isn't someone that knows COBOL, but someone that knows how to develop for mainframe systems (using COBOL). If you just learn the COBOL language in a vacuum, you'll have a much harder time getting hired.

I worked at IBM for 7 years and I worked with mainframe and AS/400 systems while I was there.

If you want to learn Mainframe and COBOL for fun I say do it. I did enjoy working with those technologies and you probably will too.

However if you want to do it because you think you'll make lots of money, unfortunately that is not the case. Yes I know you hear all the time about how COBOL programmers make bank. That is not quite true. They are not looking for people that know COBOL or Mainframe. They are looking for people that know their big ball of mud. If you know their big ball of mud they'll pay you a lot. However if you just know COBOL and they have to train you on their big ball of mud. Well they would rather send that work offshore to pay the lower wages. Any work done onshore is paid at low rates.

I haven't touched those systems since I left IBM 15 years ago. In fact I don't even have it on my resume anymore. Cloud technologies pay so much more and the jobs are easier to get.

Last night I saw an interview with the US Treasury Secretary and one of of the "DOGE bros", Sam Corcos. He is tasked with modernizing the IRS's computer systems. Some of the highlights included him saying that this modernization has already taken place at most banks, and that they're hopeful to do this in the government with roadblocks gone.

I bring this up to you, as a 14 year old, to think about your future career. You have 8 years before you're out looking for work, then 45 years, give or take, in the industry. What is the likelihood that these COBOL systems will still be in place vs. finally being replaced? Yes, people have called the death of COBOL for years, and they were wrong, but one day they're going to be right.

From the economics perspective you might be right. But, keep in mind that you will be working with 60-70 yo, who have been working and maintaining the same code base for the past 30 years. With age, neuro elasticity decreases, comprehending new concepts becomes though. Unwillingness to learn is the killer of any improvement. A grumpy old man might be a funny meme, but, waging a war with your colleagues on every change in the code is a solid drain on your mental health. You’re young, any mistake you might make is a learning opportunity. Learn COBOL if you want, it’s always a plus, but stay in touch with anything else. Work takes a solid part of your life, having good connection with your colleagues, doing stuff you’re challenged by, .. all this is equally important to the job security

Since you're young, learn what you want based on what interests you. My best advice right now is not to focus on languages but on projects. Think about a particular project you're interested in creating and try to make it. The language required for said project will become apparent after a little googling.

That said, if you just have the interest in cobol, just go for any and just have fun. Don't worry at this point about how useful it will be.

Generally, no, as a principle. You don’t want to learn things in chronological order, you want to learn them in intrinsic ness order, to the extent it is feasible. If you really want to learn computing, start from scratch. Go from logic gates to building logic boards to cpu architecture, assembly, and then programming. That will allow you to pick up arbitrary skills in a compounding way.

I think that 14 years old is too young to specialize. Your free time, which for now is plenty but will become less and less, would be better spent exploring and learning ad many things as possible according to your personal interests rather than following the job market. The next 5/10 years will be times of great change for you and you never know what will come your way, so the more things you know and explore the more opportunities you will have. You will have plenty of time to specialize once you know you are on the right path.

That is to say, if you find COBOL and Fortran interesting go for it! But after 6 months or a year consider trying something else.

What a perceptive question!

Learning boring technology and invisible infrastructure definitely can pay dividends. I don't think it's worth learning in isolation, but if you also engage in the relevant communities (think mailing lists, in-person conferences, company events, etc.) then the effort pays good dividends IME.

I'm a bit biased, but I recommend looking at APL[0]. For one, it has a legacy almost as old as COBOL, with large pieces of European infrastructure running on the language. At the same time, it's cutting edge in both performance and the software architecture principles it encourages. Heck, APL even runs on GPUs these days [1], boasting a solid route for learning modern GPU programming as well.

Also, the company behind the leading APL implementation these days, Dyalog[0], has some of the friendliest outreach around, and their yearly conferences are some of my favorites to attend.

Disclaimer: I am kind of in love with APL as a greenfield development language. Feel free to email me personally if you have any questions. Address is in my HN profile.

[0]:https://dyalog.com/

[1]:https://github.com/Co-dfns/Co-dfns

Don't. Learn something fun instead.

If you're into classic languages, learn Common Lisp, or Scheme, or APL. If you're into more recent stuff, try Caml, or Haskell, or perhaps Idris.

And don't worry too much about your employability: if you're smart and know two or three programming languages, you'll be able to adapt to whatever technology is fashionable when you start looking for a job.

If you are so smart that you are able to do this, why don't you want to learn Lisp? Cobol is mostly USA-only AFAIK and there aren't much reasons to keep Cobol except not wanting to buy new hardware.

I think it could be interesting. There are only a few Thousand COBOL developers left, median age is in their 60s-70s or something like that. Don’t know the extent of the problem but I know VC/growth investors are thinking about it. Had a chat with one this week, not on this topic, but they brought up COBOL and basically hinted that ATM infra would collapse if a COBOL dev decides to take too long of a vacation (hyperbole).

Worst case scenario you become the youngest COBOL dev in the world and it becomes a really interesting talking point / part of your story.

I wouldn't bank on a job in COBOL. I took several COBOL courses at an IBM affiliated university and enjoyed the language. I wanted to work in COBOL. I sent out dozens of applications and heard nothing back. I'm not saying "don't learn COBOL." That said, COBOL isn't a particularly difficult language, but at your age, I'd learn something more modern, and if in 5-6 years you are still interested in COBOL, learn it then.

Its not the learning of COBOL thats the issue - its the custom nature of a lot of older systems and understanding the associated business logic.

I remember getting taken thru the core interconnectivity of the mainframe at a bank and being shown a diagram of the key flows which didnt look to bad. They then overlayed all the flows and the screen was like a bowl of spagetti - and understanding that is where the real skill and expertise is

Thats probably true of most legacy systems

There are plenty of niche languages one can learn, that will land you niche jobs.

Learning COBOL will position yourself squarely in the legacy/maintenance role for large entities (banks, governments, etc.).

But, ask yourself, how long until those systems will eventually be completely revamped?

Fortran is a bit more versatile, but I've only ever seen it in the defense R&D industry - which is where I worked for some years.

But for the intellectual curiosity of it, sure, why not.

COBOL will guarantee your employment, but beware that anything written COBOL is going to be deeply corporate stuff. It will mean that it is hosted by a company that doesn't need nor want to change, or worse that it's reluctant to put any money into upgrading its infrastructure.

The reason people don't want to do it is because it's not fun at all. I once had a project where the client was a bank that needed some COBOL work done. They needed to make a few changes to a program that had been running for years. They gave me the program in printouts. Like I had 200 pages of COBOL to read. And the people working there were people who had been transfered here because they were not good. So they had no idea about what they were doing. The whole thing was extremely frustrating and we ended up dropping the project.

Absolutely no harm in learning COBOL. The language itself is simple, and you'll quickly figure out why it isn't the one of choice anymore.

But if what you're trying to do is invest in your future, I suggest learning RISC-V assembly and Verilog.

I’m old enough to have learned COBOL at university, although that was the mid 90’s and says more an about the university than my age.

It was good fun and interesting, so if you have the time and interest I’d go for it.

In the late 80's I was taking a general computer course and one of my classes was COBOL. The teacher told me it wasn't gonna be practically useful anymore, however he said it was good for historical context. I don't regret it.

Learn what you want, you have more time and freedom now than you ever will.

COBOL is ok. The issue is the type of companies we will work for and the processes around old mainframe systems (which what you'd ended working on)

If I had to guess, a 14yo would feel pretty bored very quickly.

Good question for a HN poll

No. Learn something decent.

> they will probably hire any young person who has learned a minimum of COBOL

This makes no sense

Stop thinking about the job market bro, you're 14. Go outside and have fun.

The short answer: if you want to learn languages like COBOL or Fortran, do it, but do it for FUN, not for some idea of eventual profit or job security.

The long rambling answer:

I've been joking that a high paying consultancy in COBOL is my eventual retirement plan for most of my life. Like most good jokes, its built on some kernels of truth.

One kernel of truth is that I've never shied away from touching and working on "legacy code" no matter what the language. In the corporate environments that have been the majority of my career I've been asked to touch all sorts of strange things. As many point out here and many will keep pointing out, the ability to learn or dive into programming language N+1 starts to get easier the more programming languages you already know, the more you can see the similarities and understand some of the major family trees. Showcasing those skills has been a valuable resource in several jobs, having the willingness to touch some of the legacy stinky apps has been a way to signal maturity and technical competence. It's helped boost my path to seniority in some of the companies I've worked at.

It has not been job security. Knowing the deep arcane knowledge of a company's "mission critical" legacy systems doesn't make you immune to layoffs. Companies know that you picked it up quickly, the next "sucker" may pick it up just as quickly.

Another kernel of truth in the joke is part of the "retirement job" part in that it is not the job I want next, it is the job I expect last. The more I've worked on legacy apps the less I want to work on legacy apps. I've always known that legacy apps are legacy for a reason. They aren't fun to work on. They aren't exciting things to put on your resume. If you have legacy languages and efforts on your resume that doesn't necessarily help you get the next job. Companies almost always have lofty ideas that "we'll eventually rewrite the legacy app in something modern and cool". Companies hire for "modern and cool" even when what they are actually looking for is "willing to touch old legacy cruft". Making the "COBOL is my retirement plan" joke in an interview has been the way to keep the legacy cruft out of my resume to leave more room for "modern and cool", but also signal "yes, I've done the legacy stuff, I expect to keep doing the legacy stuff".

An easily overlooked kernel of truth in the "retirement job" part is that I learned early on that you hear a lot about "there's very few people doing this job so they are highly paid" and found out that the "causal arrows" in these stories is a lot more confusing in real life. True legacy jobs like COBOL mainframe programmer aren't just high-paying because few people take or want to take those jobs, they are high-paying because few of those jobs exist. Those jobs aren't just packed by highly senior engineers where senior also means aged and near-retirement; those highest paying jobs are sometimes by their very nature the sinecures and endgames and "rewards" for high seniority developers in a company. In many cases you do literally retire into those jobs. They are "mission critical" enough to be worth paying high salaries to high senior engineers to keep working on them, but they are siloed enough and "slow enough" that they don't actually have a lot of work left to do other than just to have someone on call for the small bug fix or percussive maintenance. Companies know those can be sweet jobs to reward decades of loyalty, or luck of the draw. Companies know those can be jobs to dangle for someone to climb the ladder all the way up staying in individual contributor roles. So they are, in a lot of cases they are.

So to recap: it isn't really a path to job security, it isn't necessarily a path to get hired, and it isn't the path to high-paying jobs that it sounds like, because it isn't an "immediate path", especially not for someone fresh into the industry.

But all of that said, learn every programming language you can and have fun with it. The more languages you know the better a leg up you have to learning the next language. If you want to spend time today learning COBOL or Fortran, do it because it is fun, not because you expect it to pay off. Learning COBOL is surprisingly easy. It's a relative of BASIC in ways that aren't immediately obvious (in both directions of the family tree). Fortran isn't just legacy code, if you dig deep enough into Python data engineering you'll find that some of the underpinning code is new Fortran code in the 2020s. It's got the easy "foreign function interface"/cross-language binding of classic C, but is a language that's always been tuned for high performance math. ("FORmula TRANslation", it's name has always signaled it was a language designed first and foremost for math.) Learning Fortran in the context of a Python is a fun excuse to learn two or three languages in symbiosis.

Prolog is considered a "legacy" language but can be a lot of fun to explore and can be a bit mind-breaking because it uses logic programming in ways that few other programming languages do.

Common Lisp is considered a "legacy" language and has a lot of fun things to teach, like some of the earliest ideas of functional programming and cool ideas like code is data is code. Lots of languages have descended from Common Lisp on one branch or another, things you learn in Common Lisp have modern needs.

Smalltalk is considered a "legacy" language and is a fun way to explore early ideas in "Object-Oriented Programming" and "Actor-Oriented Programming" from their deepest, oldest source.

Javascript is both a "legacy" language and a living language and there's no end to what you can learn from it and its ecosystem.

There's all sorts of weird and fun languages in niches smaller or rarer than "legacy" languages, too. You can learn a lot from weird things like Inform 7 and Io and Lua and Elixir and whatever else you might stumble on here on Hacker News or embedded in your favorite game/game engine/game platform.

Learn everything that seems fun, and that will serve your career well. It will associate learning new languages as a fun activity that you enjoy doing, even if eventually it will be some job telling you you need to learn some old ugly thing for some "mission critical" app no one else really wants to touch. Hopefully some of the "fun" rubs off and you feel a little bit less miserable about the ugly dark cave in the hidden depths of some corporate structure they want you to do that in.