Computer courses c++ language

gm0

Assembler.  Calm down chaps.  

COBOL - yes - some are.

Plenty of COBOL still.  A lot of big government systems for a start. So jobs offshore and onshore with the big outsourcing contractors. Several banks have large pockets of it. And a load of Java (which might as well be COBOL for post 90s kids).  Core banking system replacement at larger UK banks is complete at some and underway at others.  But is a challenging thing which doesn't get done in a hurry c.f. TSB in the news for their troubles - if you remember that one.

When I think of mainframe assembler apps - I think of Halifax long ago - presumably now mostly migrated off by acquiring banks since.  Most organisations moved on from mainframe assembler in business applications.  Example BA - BABS early 2000s going to Amadeus.  Or other airlines shifting via the evolution of Sabre leaving TPF (in 2023).  TPF being of 1979 vintage and itself comes from PARS which is an offshoot of the original development of booking applications by Americain Airlines in the 1960s with IBM. Who partly learned to build the product later sold to others - from working on the AA projects - as often happens with stretching requirements of the age where people make a product after solving it for one example. In that case the problem being - with a single booking database - how many transactions can we do out of our single - biggest you can buy this year computer.  https://en.wikipedia.org/wiki/Transaction_Processing_Facility  (1979).  Just as a worked example of Assembler era apps - a good long run of 45 years. Closer to 60 back to its AA origings.  Enough for most. But I would not go and learn that now (Mainframe Assembler or TPF).

This also links back to my earlier point upthread about abstraction and 1,2,3 skills.  

Protective abstractions shield software developers from everything that is going on. Not needing to know how memory access actually works underneath - (which you did with TPF).  Abstractions can be "assumed" to be there in more recent (and also slower) operating systems and middleware and languages. Moore's law hides this for most reasonable applications.  So separation of concern has occurred. It's fast enough for most requirements.  The (category 2) application developer doesn't know, doesn't need to care what's happening underneath. The language, framework and OS takes care of it.  Which is fine. As it should be for productivity and fewer skills needed upfront to get going doing the job they are paid to do.

And yet much later - one day operationally - it isn't OK - because of a failure, or a change - related or not.   At which point you need savvy technical operations in flight to "stop" the hole being dug deeper". And then category 1 support skills on the infrastructure and tools that are now behaving abnormally upsetting applications.  To make a root cause resolution, pick yourself up and go again.   Lots of people doing root cause analysis about why things they did not think should be (or were) dependent on Amazon US East "DNS name resolution" suddenly turn out - are.  And went "boom".  This morning.

You can carry that sort of risk along singing la la la - with very old technology - in a large organisation - for a long time. Don't spend on it. Yes it's on risk logs that we should do something - but aaah other priorities. Whether that matters depends if it's some random oddity in a corner used at leap year end by one finance troll nearing retirement who likes it and claims its essential whenever switching it off is suggested. Or it is the thing that keeps the business running every day and processes all the customers transactions.  

I have seen organisations with 1000s of applications built in everything you can easily recall or imagine from 30 years of technology - and with less than 35 of them being actually "important" - So on a priority disaster plan to think about how to get them back in <24 hours. In personal life you might call people with that much junk stored up in cupboards hoarders.  

With mainframe assembler dispatched - other kinds of assembler exist away from mainframes - embedded systems - logic arrays, low power devices.  The specialist assembler dialects are a different thing. But arguably one where an engineering degree is going to be part of the table stakes for many job applications.  A barrier to entry.  Small design companies. Small teams.  Not usually looking for developers who are only developers.  Want a design engineer who knows the relevant tools and get the product into shape at prototype small run level - software included.

That leaves intel (desktop/server) - nobody has done much PC development in assembler for a long time. It's not a terrible thing to know - symbolic assembler language - and how cpu registers and memory structures and interrupts all work. Actual byte code and chip instruction sets. Programming in raw hexadecimal as a party trick (clearly at the wrong kind of parties). But there is precious little real world demand for jobs actually coding or maintaining PC assembler.  So again. No.

When I wrote my first Intel assembler for speed - a 25Mhz clock and 2 clocks per instruction - that was a whizzy fast Compaq PC still running DOS as a loader at least until your program took over.  Not the >4GHz and Windows 11/Linux of today.  We use a few more instructions to get each thing done these days but there are plenty.  That was my 3rd assembler dialect and chipset - and honestly I wasn't very impressed.  My first encounter with "ugly" tech that mysteriously wins over "nicer".

To get involved with hardware now - you need a true niche where "resources" are limited and constrain the use of higher level languages and inefficient abstractions.  But phones are powerful. And many satellites are about to get bigger again now that SpaceX has made lifting cheaper.  Situations where C or assembler or something similar and very lightweight with direct hardware access are used are rare.

So the more useful point (for OP) and job seekers - is that legacy banks (alongside government) and the outsourcers they use - are among the richer fishing grounds for terrible old stuff that sort of works and hasn't gone away.  And still needs looking after.  Most jobs overseas.  Some here.

Maintenance jobs on such things can linger for years. Or vanish in 2-3 years - if a takeover happens and a migration off begins. So luck and local opportunities.  It's all stuff that generations of the young have dismissed as yesterdays news - "legacy" (with the lip curl) and constraining of our new shiny thing.  

And then we all failed to replace it entirely with our bolt on web site or dashboard or phone app or enterprise service bus or cloud gateway - all the fun toys of the past 40 years.  Almost always adding complexity.  And removing less than we added.  The bath drain plug looks a bit blocked and the water is rising.  It's how these big corporates end up with the estates they have.  Enthusiasm and limited budgets meets decades of existing investments and terminal indecision.  And new shiny sponsored by various departments.

Implication

So for a job seeker - consider - will you be a "rockstar" of the new.  
Are you motivated enough as well as talented enough.  
Are you good enough to successfully break in to gaming, digital development - whatever it is. 
Is it a passion?

Being OK at it - and not that bothered isn't in 2025 going to cut it. Too expensive vs similarly ordinary developers available both nearshore (cheaper central europe) and farshore (india + china).  It won't get you far. 

I didn't encourage my own kids into this business technology area despite it being my main career post engineering apprenticeship. Once exposed to it a little as teens. It didn't spark enough joy for them to have the high degree of motivation and curiosity - to pursue it with enough vigour - to be successful. More competitive world with a different supply/demand equation.  They took different paths.  It's fine.  It's not a dynasty.

You work a long time.  As per OP - it helps if you vaguely enjoy it some of the time at least.

Other alternatives

Perhaps you can become a handy (but overlooked) unfashionable maintainer of the old.  On something where there is a local "shop" which uses that.  It has its own challenges breaking in with newly acquired skills but no heft to your cv of doing the job competing with age 55-65 contractors who would rather sweat that a year or two more than push supermarket trolleys back.  

But competition is still less as nobody now wants to learn the old stuff.  For inhouse and contract to perm. A younger face would be a novelty (yes I know age discrimination is theoretically illegal - and when I stop laughing - we could talk about that).

If you like solving and numbers and data and analysis and detail.  Then machine learning, data science, dashboards - might appeal. Different tools and different things you could learn for a range of business analysis and related tools jobs.  There are jobs for coders.  And there are jobs for phd mathematicians in that world. At the high end it's an odd little corner of IT.  But AI/ML is a happening thing the past few years.  Training ML tools with data sets. Query development.  Data platform engineering (system programming) - devops for AI/ML.  
And a lot more importantly - working out how to apply them in real world settings and the testing of them.   
Can self train at home to a degree. Spin up some Amazon instances - the cloud formation skills would not go amiss anyway as part of a basic cv for a new hire.

robatwork

gm0 I think the OP got more than he bargained for here!

MeteredOut

I'd challenge the assertion that Java is COBOL for post 90's kids. It is still very much a language used for building back-end service layers for new solutions in many industries where it is still seen as "safer" than Python.