An old programmer loses his job
medium.com
medium.com
But there are also a lot of people who thought that if they learned one environment they'd have a job forever, like their dad running the panel stamper at GM or working in a coal mine.
I know of one particular guy who learned dBase III and is still using it, and stubbornly refuses to move off it despite his employer deep-sixing the system in favour of a new outsourced one. The old one "still works" despite blowing out the theoretical size limit of dBase III and having to live every day on a knife edge of not knowing whether the environment will start again today, but he is uninterested in learning anything new.
I'm not 65 but I am over 50. I don't find it hard to keep up with new tech, in fact that experience makes it easier as all the "new tech" is usually just old stuff reinvented by people who don't know history. Which is fine, it's boring to read about the crufty beardies and their epic hacks. Perhaps it's better to keep it an open secret so I can keep programming longer.
It is true, though, that it feels like change has been accelerated greatly over recent years. I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? More than a couple, for sure, but if you look at popular languages right now, there's a really long (and not overly thin) tail. And a lot of the languages you'll find on that list are fairly young, while older languages have mostly disappeared (besides C maybe).
I do wonder though what the author finds so hard to learn. I'm not exactly new, either, but with more experience I don't necessarily find new things harder to learn than when I was young. It's different - perhaps my brain doesn't work as quickly any more but with more experience, it's either to recognize where "new" concepts are very similar to stuff you already know.
With programming, I think there are people who get it easily and those who struggle. And don't mean "at first" but in general, and those who struggle would probably struggle with any language be it new or old, while those to which it comes more naturally should be able to adjust to new languages fairly easily, no?
But then again, it's not just the languages that are new, but development styles have also changed quite dramatically since the time the author first entered the industry. Just think how much powerful IDEs have changed the style of development - hot swap, time traveling debuggers, inline documentation, on-the-fly compilation with in-editor error messages, refactoring support,... This is all stuff that the author is implicitly referring to as well.
The resurgence of the command line has surprised me, in a good way. Sitting at a debian box with VSCode and a few terminal windows humming isn't a big leap from what having a sparcstation on my desk used to feel like.
Visual Studio and Android Studio suddenly feel very old fashioned and confining.
Edit: to be fair, if your background was mainframe programming, most of those paradigms would be pretty alien.
Would you mind elaborating about this "full circle" analogy? How come the preferred way of coding is now a combination of a powerful editor + the command line (again)?
At the time, the Sun workstation (and competitors) made the graphics on a PC look pathetic. A PC simply couldn't drive enough dots on the screen to compete with Sun or SGI.
I'm talking about programming a big system in C here but other languages would be similar.
A pile of terminals would be your editors. If you were lucky, you could drag out your window and the editor would still format OK (vi was good at this, emacs sometimes not so good depending on your local sysadmin and what they had installed). Other editors... didn't really do that and you were stuck with whatever the termcap entries on the machine looked like.
There were native "windowed" editors available but they mostly sucked for a programmer as they were more like "point and click" and didn't have all the buffer commands, quick jump to the line you wanted etc. shortcuts that a good programmers editor has. Line numbers are important!
Most non-trivial programs have lots of source files, so you would have half a dozen vi sessions in half a dozen windows running. One window I would use just for running the compiler. The workflow was: compile the program, compiler spits out line number and file where problem is. Likely you already have it open so jump over to that window, fix the problem, :w!, recompile.
Once it compiled, fire up dbx or whatever was installed and run your stuff. dbx was (is?) capable of setting break points, inspecting things etc. You'd find the issue, kill the debugger, fix it, recompile. Happy programmers felt a new freedom compared to being hunched over a vt220 terminal. It was bliss.
Then, Visual Basic turned up. It took all the ideas of something like Turbo Pascal (everything on one screen) and kinda smooshed it together with the workstation windows idea, but instead of little windows all over the place, you have one big window with a pile of little windows inside it. For small screens (say 640x480) it felt a bit like having a Sun. Well, it felt like a Fisher Price toy but for putting together CRUD GUI apps it was pretty much unbeatable.
At that point I had moved onto Smalltalk (VisualWorks) but it was not like Unix. Everything is inside the environment - windows spread out everywhere but no command line stuff whatsoever. For the time it was fantastic (sorry digression).
Eventually, as the capabilities of PC's increased the industry kind of settled on things like Visual Studio where you have one screen, and tabs, and everything you need to do is on a menu somewhere. But having somebody have to program up all those menu items just about kills the release cycle of new features. Every time you add a new feature to the compiler you have to change the properties screen, test it, merge it, roll it into the next release. I understand why Microsoft in particular abandoned that idea for .NET where the importance of a PowerShell window really started to come into play.
Outside of MS you start to get things like Node.js where you need to run a command line tool to set things up. So it became normalised to want a rich CLI and all the nice things like "more" and "grep" suddenly become more useful again. Which is unfortunate if you are running Windows because suddenly you have to install a pile of 3rd party stuff. And along with it the most uselessly named system in the history of uselessly named things: chocalety. Hey whoever named chocalety, go f*ck yourself.
So VSCode is almost back to where I started. It has a bunch of tabs instead of different editor windows, but a lot of the time I'm in a terminal running "code ." and starting another instance of it. The compiler is running in a terminal session within VSCode but you don't have to do things that way and sometimes I don't, I have another terminal open where I do "dotnet start" or "docker run" and just attach to the process rather than using the vscode built-in launch stuff, because I want to drag that output window out nice and long instead of being cramped to 8 lines at the bottom of VSCode.
Onion on belt etc.
edit: If you really want to know where all the Ctrl-Z, bg, fg etc. stuff came from in the Unix shells, it was programmers who had 10 vi sessions running on a single terminal and were switching around between tasks.
It was at the time when the big debate was whether to use GNU Emacs or XEmacs. If you weren't in team vi, that is.
I remember sharing Emacs frames between machines (using `xhost +`) to do "pair programming"... or rather, have your more experienced co-worker debug your awful code for you ;-)
Anyway, thanks for the interesting write-up. I myself never got into vi, although I don't subscribe to the flamewar mentality of old. I wish I were proficient in both.
Emacs, by the way, always had multiple "tabs" that you could switch between. Just sayin' ;-)
My mentor at the time hated emacs. She said everybody had to learn vi because on a new machine it might be the only thing installed. The flamewars over it seem quaint now.
But in all these years I hardly ever encountered a situation where I had to edit some files on a machine that only had vi installed. Perhaps I would have learned it by now if that had been the case more often.
I started my career in 1985. I've never been a mainframe programmer, but I know back in the day they were using Cobol (still do!), RPG, PL/1, and JCL.
On the minicomputer side they were using Fortran, Lisp and C.
Microcomputers also adopted C but also added Pascal, Modula-2/3, and of course, Basic.
In the late 70's and even early 80's they were still working on the paradigm shift to structured programming. That's table stakes today but yes, there was a time when structured programming was a paradigm shift. Structured programming was all the buzz.
And then came those weirdos from Xerox PARC with Smalltalk and talking about "object-oriented programming." Great. Another paradigm shift. Bjarne Stroustrup then had to go and post incrementally improve C to add object-oriented programming to give us C++.
So far we've only made it to 1986 and we haven't talked about platforms! The various mainframes, minicomputers and microcomputers and all the different operating systems running on all of them.
Since you said "maybe even 90s" then I would remind you that's when Python, Perl, Java, Ruby, and C# all came into being.
From my perspective things have slowed down dramatically over the past 10-15 years. We only have 4 major OSs, 2 microprocessor architectures and there haven't been that many new languages: Go, Rust, Julia, Scala, Kotlin, and Clojure (hmm, maybe there have been a few new languages!) You could argue there's another paradigm shift afoot, functional programming, but it's been around since the 80's (!) and hasn't had widespread adoption.
Finally, it's far easier to learn today than it was back then pre-widespread internet. You used to have to read periodicals and buy books. There weren't videos, tutorials, and the plethora of training options there are today. Add to it that all the tools you need to get started are free and you're all set!
Bottom line - I'd say it's easier than ever to keep up with new developments. The field is moving slower and there's more resources available to keep up with the changes.
What you're ignoring here is that in your 20's and early 30's you have nothing but time. You can spend your evenings and weekends reading O'Reilly books and churning out cool side projects. As you get older, non-work responsibilities increase massively for most people, as you spend time taking care of children, elderly parents, doing small home repairs, etc. Suddenly you can't just drop everything and spend the entire weekend reading documentation and tutorials when $BIG_CORP suddenly decides that all work must henceforth be done in $SEXY_NEW_FRAMEWORK_X.
20's and 30's are where lots of people have time pulled away by kids, not later (median in 2020 was around 28 for kids). And in your 50's and 60's people generally have lots more time as kids move out (28+20=48 = kids gone or at least not such a time sink).
If anything, 50's and 60's should be a golden age of learning.
First, I think there were a lot of languages then, too. It's just that you haven't heard of them. SNOBOL? JOVIAL? There were 1700 known languages in 1965 (quote at the top of https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf). In 1990, say, there was Lisp, FORTRAN, COBOL, BASIC, PL/I, APL, probably still some ALGOL. Then there was the Unix-flavored stuff: C, PERL, awk, sed. There was Pascal, Simula, and Smalltalk.
Today I think the picture is similar, except for one thing: web frameworks. If you exclude web frameworks, there aren't that many languages in general use today. C, C++, C#, Java, go, python, Swift. Maybe Clojure, Kotlin, or Scala, depending on how you define "general use".
I think that a huge amount of the churn is in web languages and web frameworks. Outside of that, languages aren't moving that fast at all.
Well that's how it worked out for me. I learned Java in the 90's and have used it at every job since for a quarter century. It's changed some, but it hasn't changed that much. It's not going anywhere. I learned other technologies when I had the chance but it hasn't really mattered, all that was wasted effort.
I guess it matters more for front-end development, but over the years that has shifted into being done by a separate team most places I've worked. I don't touch front-end code where I work now.
It's not impossible but I think if you aren't in a job (or working for yourself) that you're learning something new every day then you're falling behind.
I also don't fault the guy. Nothing in human history has ever changed this fast.
The first computer I played with was the (then new) Commodore PET, with 4KB RAM. My elementary school had one, and access to it was like some sort of special privilege.
There’s a certain tendency people tend to have, which is to believe that “things were better in the old days,” or “they don’t make ‘em like they used to.” Or “there are no new ideas.”
I dunno, for me going back to the pre-smartphone, pre-Google, pre-Internet world… pass.
Naturally, there are a wealth of core ideas, algorithms, patterns which have stood the test of time and even evolved and flourished. But our understanding of even basic ideas has significantly changed over time.
Personally, I’ve generally elected to not get too caught up with fads, and to focus on understanding fundamental ideas, algorithms, mathematics; how things fit together into robust, efficient, flexible systems.
I've never used Multics but it seems that the guys who wrote unix and VMS and other mini computer OS were time sharers. One box, lots of users, how do we stop users from stomping on one another. The final paradigm was that your programs can pretend they own the whole machine and the operating system handles keeping everybody safe from one another.
This is fine if everybody runs single programs but eventually hits the wall when you need competing environments.
Personal computers and networking fixed that, but now I want to share my running program, I need a server again. A big, shared machine only my environment clashes with yours, so containers are born. They are networked personal computers in conception.
The other pattern is transaction programming. IBM mainframes didn't really do time sharing, you write up your job and schedule it. Some jobs are then triggered by conditions or events. Its more like a domino stack than processes trying to pretend they are the only thing running. AWS lambda functions are the modern equivalent but without the safety of proper queues that something like CICS provided. They will get there.
For some problems, you need interactivity. For others, you really want transaction processing. I think transaction processing is really underutilised in modern systems as we all scramble just to make stuff work and the time sharing and personal computer modes of thinking dominate the problem space.
That wouldn't surprise me. Larger companies are often well advised to keep their production languages to a minimum. I mean, even Google when they first started out (straight out of grad school) wisely restricted the number of supported languages.
If you stay with the same company for a long time, I can easily imagine that you don't get a lot of exposure to new trends. I mean, C has been around for a while now and depending on the field of application can still be the go-to language.
My experience has been exactly this. I've read many such complaints in the last 20 years of working, and in every single case the author has pigeonholed themselves into a long obsolete corner of the industry. There is a difference between 30 years of experience and 5 years repeated 6 times.
It is important to get onto the right team to have a long lived tech career. Your business domain should be big enough so you organically have to move with the rest of the industry. By 20+ years, you should be in a senior enough position to help lead the change.
I've never met a tech guru who was up to date and didn't retire or move on to other things on his/her own terms.
I suspect there is a geographic mismatch. COBOL programmers probably can't be remote-only.
Python/JVM/Ruby are the opposite: It's more about a diverse skillset, because most of the time you'll have to use Java AND Python, or Python AND Ruby.
That doesn't sound about right. Maybe he just chose the wrong ones? I agree that the churn rate for methodologies and architectures is high in the industry, but not so much for programming languages. Java is 25+ year old. C# is close. Python is not going anywhere soon. Even Cobol is still somewhat relevant today.
I've been around the block for a while, too, and I don't think I've ever learned a language of which I thought it might be useful career-wise which then later fell of the surface of the Earth completely.
I mean, how long does it take to learn a new language, once you're experienced with some others? Hardly as long as new trends arise and die again.
I have a friend with a wealthy father who has never bought even a single bond share. He has stayed invested in equities his entire career and into retirement. He was already retired in 2008 - and the drop was a mere hiccup for him. He didn't panic-sell and just continued making his required minimum distributions like normal.
There's also an amazing influx of new competition from countries where wages are a lot cheaper than in the West.
Give it 10, 20 more years, and programmers might be the new factory workers: easy to replace, and hence not a valuable asset any more.
You might think "But hey! Factory work is mostly manual labor that almost anyone can do. Programming needs intellectual acumen.", and watch kids with AI-powered tools eat your lunch.
But once they graduate and start looking for jobs in the same area that they've become acquainted with over the course of three years or so, and where by now their center of life really is, they find out the same thing you report about Germany: outside the university circles, you won't get very far with English.
So the majority will go back home again after a while, often times not so much by choice but just because they're forced to.
I imagine this is double tragic for a place like Germany where studying is (almost) free: you give international students a high-quality, free education which is then promptly taken out of the country again.
On the last point I'd say though that they are of course welcome to stay, but also welcome to take their skills back home. I made a lot of friends from developing nations, or wartorn places like Syria, that will hopefully make a real difference there. Giving free education to talented people is probably one of the most effective ways to help the world become a better place.
And just to clarify, this concern is not about the current programming-related AI technologies, which have nothing like human abilities. It's about anticipating advances that have not yet occurred.
Don't put all of your eggs in one basket. None of us can expect to stay in the same field that we start off in for the whole of our working life. In my own case, I started in Pharmacy, but developed expertise in aviation, computing and rental properties.
While the aviation and computing didn't become the main thrusts of my work, they became important sidelines. When it comes to rental properties, my wife and I had little savings due to our two divorces, and we needed to ensure that there would be some form of income after we retired from our 'main jobs'. So we took a few risks to build up a stable of rental properties while we still had our main-job incomes.
Today, retired, our income comes from rental properties and some of the property-management is made easier by my computing expertise.
The aviation? Well, after I became a commercial-pilot, the aviation industry went through a down-turn for several years and it never became the enjoyable cash-cow that I hoped it would. All the same, it was a fun time that I would have been disappointed to have missed.
Another thing to always keep in mind: For instance, when they moved their offices, I came in on my own time to help physically move computers and helped to hook up all the cables.
If you discount your own worth by working without pay, why should the employer consider you to be worth more?
It's certainly a slog keeping up with change in the software industry. It's not just that things keep changing, it's that the wheel keeps being reinvented and that's just tedious.
I remember working with an older programmer when I was about 30 who was retraining as a lawyer. He said he was just bored with having to learn essentially the same things but in different forms over and over again.
Not taking ownership of your own job search is a red flag.
Author also failed to act on early warning signs and thought that he could make himself too valuable to be let go.
So it seems that it's less about age and more about mindset.
Yes, but the author clearly has taken active steps to find a new job himself. I mean, the fact that he got in touch with a company to help him search is already evidence of that, but as he later writes, he did find some part-time jobs at least by his own doing.
I can sympathize with his reaction: what's the point of hiring a company to help you find a job when all they do is call you two months later to ask whether they're still needed?
Of course, we only know his side of the story...
Imagine being a Cobol or dBase III developer. You recognize that some new technology (say AWS Aurora) is in demand.
So you study a whole bunch during your off time. You do tons of courses, hobby projects, and even take the applicable certifications.
Here's my question: then what? You have textbook knowledge of this new skill, but no actual production experience. What's the best way for these re-skilling workers to make the jump from learning to earning?
Ok, so it would be unethical for me to suggest that you lie and imply that you have actual production experience but... there's really no way for most interviewers to realistically check whether or not the company you worked for did or didn't use (say) AWS Aurora in some internal projects. That's why they do technical screens and ask you trivia questions about things.
- You do have production experience, just not with the new software - You know the new software, and especially if it’s new, you probably know it as good as most other developers - Your prior coding experience won’t 100% transfer over to new tasks, but it won’t 0% transfer either. For example many programming languages are very similar, if you’re familiar with one general-purpose language you’re ~almost~ familiar with all of them (C++, Rust, C#, Java, Scala, Kotlin, Swift, TypeScript, etc.)
A harder (but still pretty easy) transition is to work on something other people at your company are doing, but which you aren't. Perhaps there's a group doing big data and you want to get into it but you've never done it. Learning the skill on the job can be a hard sell, but it isn't always impossible. It's worth asking. Employers like working with smart people they already know, and can see it as a better bet to teach a known good guy a new skill than hire someone with the skill who turns out to be a terrible engineer. Some places will actually send you to school to get the certificate or whatever. However, this route often doesn't work because they genuinely can't afford to train you. Your odds of success go way up if you're willing to learn it on your own time. They improve even more if you can get pretty good at it. It helps further if the people on the team respect your intelligence and capability. The killer strategy is to make your preferences known, keep doing excellent work on your old system that no one else is willing to do, build up karma that way, get really good at the other thing on your own time and talk shop to the other team about their work, wait for a good time for the company. . . . your odds of eventually getting in are excellent. Boom, data science experience.
For something totally unrelated to what your company does, this is a lot harder. You have to both learn the skill and demonstrate competence on your own time. Your best bet is to build up a portfolio of accomplishments and side projects that you can share. This isn't the same as professional experience, but professional experience demonstrating you're capable, properly socialized, and people will actually trust you with stuff for years on end -- all of this still puts you ahead of total newbies, even if the specific skill is new to you. The truth is that talent is in such desperate demand (especially if you chose your new skill wisely) that interviewers are usually much more interested in whether you can actually do the work than they are in what your resume says. So just make sure you really can do it, and you really can prove that. Some employers really will insist that you have those 15 years of Haskell experience the job req says they want. But most of them will see solid general engineering experience on your resume, see during the coding portion of the interview and by looking at your public work that you really can do the job, and they'll decide you're probably the best bet they're going to get to fill the position anytime this year, and they really do need the help. Don't take "X years of Y experience" too seriously. If you really can Y, your odds are excellent.
I think though that there's other ways to apply new things you learn than just in your job. Open source projects come to mind, of course.
However, that raises a related point: if our field one where it's a necessity to spend a substantial amount of hours in addition to your day job (for both studying new tech and finding ways to apply it) just to stay relevant for the job market?
But just to be clear: no-one claimed that you cannot learn any new skills outside you work. The point was really more about the difficulty of demonstrating that you actually have said skills, and not just say you do.
How many associates at top law or accountancy firms are over 40? 50? From my crude linkedin survey, not very many. It seems that in these environments you either progress up, or move down the tiers until you can progress.
I think it's fair to compare programming roles to these 'entry' roles in other professions, with staff engineer and engineering management roles more analogous to 'partner'.
I'm not trying to discuss the merits of older programmers - I'm just unsure that the ageism is more of (or only) a problem in tech narrative is that strong.
It can happen, but it's much less common. Right or wrong, people have different expectations of different fields. I you ask someone to imagine an outstanding lawyer or doctor, they probably envision someone in late middle age, maybe with some grey around the temples. If your doctor walks in the room and looks about 25, you're probably not going to be thrilled. Now, if you ask those same people to image an outstanding programmer, they probably envision a young person in the twenties.
I was at a conference yesterday for IoT in the energy industry, and my main two observations were
* #1 complaint from industry was the skills gap in the current (aging out) workforce. (Of course, as automation has decimated that workforce, there's major reluctance to assist in your own potential demise ...)
* the main pitch from vendors was young people with those skills only want to work in tech / consulting / startups.
So definitely a competitive advantage is your ability to retrain your experienced staff, and definitely a personal moat is your ability to brand yourself as an old dog who is happy to learn new tricks.
That aside, a couple of things about your comment really struck me:
> Of course, as automation has decimated that workforce, there's major reluctance to assist in your own potential demise ...
I love automating myself out of a job, and that's been my primary goal everywhere I've ever worked. It was moderately successful at the "Fortune 100 Big Co." where I started out, but my career progression there was much slower than I'd hoped. I made the move to startups and fell in love. Yeah, it's less stable, but the compensation is generally better. Keep a few months' income in savings and you can ride out the instability.
There is a sweet spot where I like to join a company. Ideally they've built a product that works, they have a proven sales and marketing group that has actually made enough sales to prove that there are customers out there for it, they have funding available to grow the business faster than would be possible via bootstrapping, and finally, they're beginning the transition from a small engineering team of early employees to a much larger group composed of multiple teams.
I'm in that situation right now, and I'm loving it. Everything I do is intended to be short- to medium-term, and I make a conscious decision to put an end date on every project I work on and pass it off to another group within the organization. This is very much "automatic myself out of a job", as at the end of each project I'm somewhat adrift and no one is depending on me for anything more than occasional support adn guidance.
I also build relationships with leadership and the early employees by setting up meetings in the beginning and making explicit that I want to understand and buy in to the existing company culture so I can consciously promote and foster it as the group grows.
In my experience, this approach has worked either very well or very poorly, depending on the company and its culture. I'm happy where I am today, and if all goes according to plan will have the ability to make the decision in the next 2-3 years how I want to approach the future: specialize as an IC, make the move to engineering leadership, or exit the industry and take one of my side hustles full time.
> [...] young people with those skills only want to work in tech / consulting / startups.
As a group, I'd guess more young people want to work in this kind of environment, sure. A larger proportion of older engineers have a lower risk tolerance and/or don't want to skill up quickly and on a regular basis.
I noticed early in my career though that the older engineers who do have those skills and want to work at startups are worth their weight in gold. They're (obviously) just as capable as their younger peers but have the benefit of wealth of personal experience in similar situations. They can draw on that to save the company many expensive mistakes. Sometimes you have to make them feel comfortable first, though. A lot of the older engineers I've worked with have been badly burned by speaking up in the past and seem to be hesitant to do so as a result.
2) US companies keep ratcheting up interview demands, which artificially constrains eligible candidates.
Examples are using coderpad where your code has to compile and pass a test/performance suite now, and doing random memory quizzes in addition to programming. But that's the fault of the hiring company.
We do have a strange profession.
There aren’t clear pathways to careers for people who might need to transition.
But I can also see where the stereotype comes from. The big problem for older developers is developing a misplaced sense of pride in being unwilling to engage with the inevitable changes in technology. After a few rejections it's easy to start rationalising this as, "they don't want someone experienced who'll be expensive and know they're being taken advantage of" or "they know I'll show up all the idiotic decisions that greenhorn CTO is making" - which worsens the problem, because now as well as the age and skills disadvantage they're coming across as arrogant in interviews. It's hard to talk people out of this spiral because they think the attitude is a good thing, and they're getting that reinforced by all the people in a similar boat saying similar things.
(This is probably too much an aside, but IME older folks are some of the most naive about the salaries they should be asking for and how the company should treat them! For a company, the big benefit of hiring people who're 50+ is the tendency to be too good at the, "I'm just going to do what you ask me to do for whatever I'm paid without challenging anything" aspect. Recent graduates these days don't put up with the nonsense their forebears did.)
One of my favourite teams to work with had two 50+ guys in it. One who had the most incredible enthusiasm for new technology, and of course with 30 odd years of picking up a new tech every few months was incredible at it. You'd see him study something over a weekend and come back going, "so this is really a functional language at core, and I've worked out the idiomatic way to build an API in it is using this". The other built a lot of the testing code and did a fantastic job of playing the age-worn cynic in a way that made the younger team members laugh while embedding the point about defensive coding and building for testability. But there have also been plenty of older devs more of the, "J2SE was fine for me and it should be fine for you; all those new language features only make your code unreadable, you'll understand once you've been doing this job as long as I have" school which drives the stereotype.
The sad thing is I reckon you can tell which way a developer is going to go as early as 5-7 years into their career, because by that point things will have moved on from what they first learnt and you can see whether they're engaging with it or refusing to change.
Of course, for the author of the article there's the additional problem that any typical HR department will be drawing a big red flag in the "years until retirement" column, and in a lot of companies they will have veto power too early on in the process for a hiring manager to interview and find out what the actual story is. As others have mentioned it's difficult to overcome this, but you need to take charge and start looking for jobs on platforms where you'll be talking directly with team leads and engineering managers rather than going through the classic agency > HR > interview process route, which is basically designed for risk elimination through standardisation.
tl;dr: if you find yourself getting old in spite of your youthful belief that would never happen, stay enthusiastic and don't get bitter. I guess that covers more of life than just software development.
When an old Boomer says they did all the right things by learning new languages, they mean they took the risks they were (quite unfairly) expected to take (just to try and preserve their occupation), but in some way, they couldn't always keep up with industry changes. (Combine This with H1B-fraud and C-suite wage theft like https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L... and you have a retirement disaster decades in the making.)
To the 65 year old, you're not that old for a non-physical occupation (look at Woz) and when I started in this business 40+ years ago (tho still not yet old enough to qualify for the senior menu at Dennys), it was common to find guys your age around teaching us younglings --I learned a lot from them, miss them and I have sincere pity for the post-Y2K generations that lost that after the elders were forever purged (first to be RIF'ed and all at once as the dot-com bubble crashed demand for tech from 2001-2006). From following some of the elders through all of that, I know you're going to want to avoid head hunters, focus on marketing yourself to small companies and approach future work assignments as a LOYAL AND DEPENDABLE partner not just a body showing up to a "job". Pay attention to your shoes. Not fair that you have to hustle more as you get older, but nobody ever promised you fairness. (Also, I strongly recommend against investing in another line of business at 65, as I've seen that not work out a lot.) Lastly, don't listen to the critical voices on here and similar sites!