
The Planned Obsolescence of Old Coders - coffee
https://onezero.medium.com/ctrl-alt-delete-the-planned-obsolescence-of-old-coders-9c5f440ee68
======
d_burfoot
I wanted to like this article, but I was annoyed by the second sentence, which
asserts that the tech industry is extremely white and male. The "male" part
may be true, but the "white" part isn't, and that fact is well known to anyone
with even a passing familiarity with the industry. The big tech companies are
actually LESS white than the US as a whole; it's Asians who are vastly
overrepresented. In 2017, Google's tech hires were 47.1% Asian and 42.1%
white. The 2018 Facebook tech hires were 51.3% Asian and 42.7% white. This
compares to the overall US population which is 72% white and only 5% Asian.

I don't want to start a flame war about diversity, I just want to get the
facts straight.

[https://diversity.google/annual-report/](https://diversity.google/annual-
report/)

[https://www.facebook.com/careers/diversity-
report](https://www.facebook.com/careers/diversity-report)

[https://en.wikipedia.org/wiki/Race_and_ethnicity_in_the_Unit...](https://en.wikipedia.org/wiki/Race_and_ethnicity_in_the_United_States)

~~~
thegayngler
This reads like you seized one sentence and stopped reading because you didnt
like what was said so dismissed the whole article. Thats not fair IMO. I read
the whole thing and the article uses the first sentences to set the backdrop
for his argument that older engineers and programmers are forced into early
retirement and companies in tech world and outside of it make rookie mistakes
that could be avoided by treating engineering as a life long profession.

~~~
TheOperator
Alternating between complaints about White overrepresentation that aren't even
true and politically correct terminology like "People of Color" and the entire
article being a love letter to an underrepresented group is just jarring. It
makes me wonder about how informed the author is about tech if he thinks
Whites are overrepresented generally. There's either a lack of accuracy or
moral consistency. Why the hell is the author even bring up his poorly
informed opinions on racial topics in an article about ageism anyways?

Anyways the article as a whole is heavy on anecdote and low on data & facts.
There is an emphasis on outcome metrics but the author doesn't bother to
examine any data on productivity vs age.

~~~
thegayngler
The problem with your argument is that there are other diversity initiatives
in the programming world which are mainly gender and race focused. That is
undeniably true. There hasnt been the same thing at the same scale for older
programmers. In fact there have been many articles on this very forum about
how many tech companies filter out older engineers when searching for talent.
Its not the first time this topic has been brought up. IBM was actively
phasing out older workers and long term workers. Lets not act like data isnt
there to support the claim even if it is just anecdotal.

------
wiremine
For context: I'm VP of a software consultancy responsible for delivering
software on time and on budget.

My take is that older programmers who maintain their skills on new technology
are worth their weight in gold. The financial trick is to pair them with
younger developers to create an overall cost effective team. If both the older
and younger devs go in with the right attitude, it can be wonderful for both
the project and their respective careers.

I also think it's really, really dumb to push developers into management
positions if they can't do the job. I'd much prefer putting younger managers
with great management skills into the mix than just rotating older devs into
that role.

Bottom line: software requires lifelong learning. If you can't or won't stay
current, you're in trouble. If you can, then it's just agism or a bad business
model that's keeping you out of awesome projects.

~~~
benatkin
In the article they mention a Python conference. I think Python is a good
counter-example. It's an old language and still as strong as ever. On Stack
Overflow, it recently passed JavaScript [1]. Unlike JavaScript, new Python
code isn't all that different from old Python code.

A lot of older Python candidates are being passed over for younger ones. Sure
they might not be learning Rust, but there are younger python developers that
are having an easier time getting a job, and they aren't necessarily learning
Rust either.

[1]: [https://stackoverflow.blog/2017/09/06/incredible-growth-
pyth...](https://stackoverflow.blog/2017/09/06/incredible-growth-python/)
[https://insights.stackoverflow.com/trends?tags=python%2Cjava...](https://insights.stackoverflow.com/trends?tags=python%2Cjavascript)

~~~
Alex3917
> It's an old language and still as strong as ever.

Does it make sense to consider Python an old language if it's still a living
language? The next version is coming out in October, and most new projects
started today are running on versions released within the three years.

This seems pretty different than something like COBOL, where it's technically
still being developed but not in anywhere near the same way.

~~~
jniedrauer
It's also worth noting that recent python versions have added tremendous
quality of life improvements. If you haven't kept up with the language, then
the code you're writing may still run, but it's not "pythonic" anymore.

~~~
caseymarquis
I haven't touched python in years. Can anyone link to a list of examples? I
remember hearing about optional typing, which is always my favorite addition.

~~~
wiremine
Python is indeed getting better and better, but I personally wouldn't include
optional typing... yet. Mostly because the optional typing in Python is just
for tooling, not for the run compiler or run time [1]. Python is one of my go-
to language, but I haven't found a compelling reason to use type hinting yet.

Python's really good at binding C code [2], which is one of the reasons you
see it in so many machine learning and scientific projects (Numpy, Scikit,
Tenserflow, etc.) I think that's what given Python a lot of legs in the last
few years.

[1] [https://stackoverflow.com/questions/41356784/how-to-use-
type...](https://stackoverflow.com/questions/41356784/how-to-use-type-hints-
in-python-3-6/41356872#41356872)

[2]
[https://stackoverflow.com/a/10202569](https://stackoverflow.com/a/10202569)

------
erikpukinskis
I've been doing some job interviewing lately, at 37.

I do find that companies seem to know how to evaluate young programmers: just
test them on their knowledge of your tech stack. Any young coder who is good
and is working in that stack will know the basics. The bad ones won't.

For older coders, I'm not sure that same signal works. I've forgotten more
frameworks than most coders will ever learn. I mostly don't care about
programming languages, they're roughly the same and I can learn a new one in a
couple weeks.

I know technologies like Rails and SQL, but I don't play with the new toys as
much as I used to, becuase lately I would rather solve a new problem or build
a new tool than learn a new tool.

But how do you evaluate a coder on their ability to solve problems? Much
harder.

Even more difficult, how do you get a 24 year old coder who only knows react
and FireBase to evaluate a 37 year old coder who has built web frameworks from
scratch?

It's another world, and a lot of companies just don't bother.

Thankfully I have no desire to work at any of those companies. I solve
problems. If a company can't hire for that I don't belong there. There are
plenty of companies trying to hire people to solve actual problems, not just
put coder butts in seats.

~~~
mkozlows
This whole "learn a new one in a couple weeks" mindset is toxic and needs to
die.

Yes, you can learn anything at a superficial level in a couple weeks. If
you've spent the last ten years maintaining an ASP.NET WebForms app running on
IIS, then within a couple of weeks, you can contribute code to a Go
microservice running in Kubernetes and using Kafka.

And that kind of "basic competence, with the ability to learn more" is what
hiring managers want out of a junior dev, so if you don't keep your skills up,
well, great, you're as useful as a junior dev.

But what they want out of senior devs is people who know the ins and outs, who
understand what to do and why to do it and can explain that to others, who can
avoid the pitfalls of bad tech choices and misguided implementation patterns.

If you've got decades of experience on your resume, my guess is that you want
to be evaluated as a senior dev. And if you're a senior dev who doesn't know
modern tech, then... you're not that useful. Your encyclopedic knowledge of
the WebForms event lifecycle doesn't give you any particular insights into the
design challenges of a microservice ecosystem; your ability to tweak IIS for
maximum performance won't help you write a Helm chart.

If you want to be hired as a senior dev, you need to understand how the modern
world works, and all the posturing around "I could learn it in a week" or "I
prefer to focus on problems" doesn't impress anyone.

~~~
ska
If you really are a senior technical person, you have many valuable skills
that are not tied to a tech stack. Otherwise you may have a related title but
you are really just a technology domain expert - which is sometimes very
useful and valuable, but it's not the same the same thing at all.

So yes, it's helpful that people keep current, and obviously waiting for a new
developer to get up to speed on the particular stack is always a cost (and it
isn't a couple of weeks, for anyone). However, if what you really need is a
senior person, it may well be worth that time.

Seeing this assumes the hiring manager understands how software is actually
produced and maintained, not just what their current tech stack needs. It's
surprising how often this isn't true, but a contributing factor is how mid
level mangers are made - which is related to this discussion I think.

~~~
mkozlows
What I'd say to that is, yeah, it's true that a senior dev will have skills
that go beyond a particular tech stack -- but if you're working as a dev, then
those skills are still tied to your technical knowledge.

You might be great at mentoring... but you have to know the stuff to mentor
people in it. You might be great at communicating with stakeholders... but you
have to understand the technical constraints of your system in detail to have
that communication. You might understand principles of software design and
debugging... but you still need to understand the particulars of these
technologies to make your design or to focus your debugging.

And yeah, you can learn the tech stack, and a company that really needs a
senior dev eventually could do okay to hire a senior dev with out of date
skills, and wait for them to get trained up. But don't plan on it taking three
weeks, is all I'm saying. To really get to that point of fluency and domain
expertise takes longer.

(And also, one of the things that senior devs are supposed to do is evaluate
new technologies and figure out when and where adopting them can make sense.
If you've fallen so far behind on learning new tech, then it's not clear if
this is something you're able to do -- maybe it is, and you just worked for a
workplace that stifled adoption of new tech, or maybe you're someone who'll
just learn what you need and then stop paying attention.)

~~~
ska
While I see what your saying, a lot of your language seems to come from the
idea that tech is a progression, that we are moving "ahead" always, and that
people get "left behind".

That's mostly not true. While there definitely have been advances, tech is
also very faddy and repeats itself. Trends are often reactive, techniques
repetitive. Someone who has been around for long enough to see some of these
waves resolve themselves is in a much better position to evaluate current and
upcoming approaches. Technologists also tend to be myopic, and view the things
happening in their own tiny slice of the industry as "what's happening". There
is a whole universe of interesting stuff on the go that you are at best barely
aware of.

Personally, if I'm hiring senior technical people I'm much more interested in
their continuing level of curiosity and engagement with _something_ , rather
than particular stacks.

So maybe you are worried that your candidate who has been doing ASP.NET
WebForms for the last decade on IIS will have a hard time getting up to speed
on your use of TypeScript and React ... but if I find out that she's also
being building raspberry PI infrastructure for fun and messing around with the
Julia language to implement a cellular automata project I'm not all that
worried about their ability to get up to speed, even though none of that stuff
will get used by the team.

But yeah, it doesn't take 3 weeks. It doesn't actually take 3 weeks for a new
dev already well versed in your technologies, with rare exceptions. At least
not to be firing on all cylinders.

The thing is, a huge number of teams really, really need a good senior dev.
They often don't think so, and often erroneously think they already have
some... but they don't. Instead they have people who had "Senior" (or "Staff"
or whatever) added to their title because they'd been there for a little
while. And every piece of work the team produces suffers for it. So yeah, it's
typically worth the investment.

Now granted, that assumes you are good at identifying talented people. This is
actually a big ask - and one of the issues surrounding the OP's questions
really comes back to that. I think that a lot of software and technology
development suffers fairly systematically from poor quality middle management.
One of the symptoms of this is the "ageism" discussed here, but it's only one
of many....

~~~
ngneer
Yes. These days gRPC is a new technology. And yet RPC has been around in one
form or another since the 1960s.

------
SamuelAdams
I work in enterprises with 50,000+ employees and billions in annual revenue. I
work with older programmers all the time! They're better at programming in
Angular than I am. And they are wonderful mentors!

I think what's actually happening is some programmers, who happen to be older,
don't keep up with their skills. Then when they interview, they bomb it, or
talk about how they could do the same thing in an older stack.

That's great, but the company is really invested in the current / new stack,
so it doesn't make sense to hire someone who does not have those skills. So
they pass them up and find a candidate who knows the software the company is
looking for.

But the older interview candidate, instead of reflecting on themselves and
realizing they need to spend time enhancing their skills, they simply say the
company was "ageist" and blame it on age discrimination.

Blaming others is generally easier than blaming yourself, I guess.

~~~
svachalek
The scenario you talk about happens for sure. And some of those protests are
legitimate; we've made little advance in real productivity since the 70s but
all the while churning languages and libraries and environments like
fashionable clothes partly because programmers are on the average young and
inexperienced. So after a decade or two of riding the wheel, a lot of
engineers decide it's pointless and just kind of check out. (Not me, FWIW; I'm
on board with React Hooks and looking for an excuse to use ReasonML.)

On the other hand, ageism is real. When I was younger I was told more than
once by managers, straight up, this candidate is too old so find an excuse not
to hire. And now in my 40s, when I walk into some companies for an interview,
I can feel the decision has been made before I even start talking. Not
everywhere, not even most places, but it happens for sure and it's not even
that subtle.

~~~
com2kid
> we've made little advance in real productivity since the 70s but all the
> while churning languages and libraries and environments like fashionable
> clothes partly because programmers are on the average young and
> inexperienced.

Making a real time video chat client is now a literal programming exercise, it
used to be the domain of multi-million dollar venture backed startups that
were valued in the billions.

Real time chat between users is now a feature that is added to an application
in a day, or even a few hours if you follow any of the myriads of tutorials
available on YouTube.

Go from writing a UI in C/C++ to writing it in any of the higher level
languages. Assuming you don't get caught in some design pattern trap that
results in massive code bloat, it is now possible to do things in hours that
used to take days to weeks.

Heck, transparency is no longer "write some ASM" routines, it is setting an
opacity variable!

Some tech stacks, such as those for making basic CRUD apps, may have actually
degraded a bit, but at the same time someone who is only slightly technical
can now _drag and drop_ their way to an online store front that is a fair bit
more powerful that Viaweb was back in the day!

Heck, it is possible to now go from an empty folder to writing+deploy HTTPS
API endpoints in under half an hour.

Edit:

More stuff!

App (not web!) updates can be deployed to users by uploading a file and having
a client pull down the changes and seamlessly switch over to the new code next
time the app is launched. Versus mailing out disks!

There are app stores that you upload intermediate code to and they'll compile
apps to the appropriate architecture for a customer's device!

During 72 hours of coding for Ludem Dare, game developers and artists work
together to create games that are as complex as a full fledged commercial game
would have been 25 years ago.

And of course, many corporate software engineering efforts continue to fail or
go massively over budget for largely political reasons.

~~~
lambda_lover
Your discussion of "real time video chat clients" has me cracking up; it
seemed that a myriad of pieces of software had this figured out in the 2000s,
but today I can't think of a single piece of software that I'd actually want
to use for video chat. All of them have some fatal Achilles' Heel: Facetime
has security problems/previously did not have group chats/is exclusive to
Apple OSes, Skype is laggy and has more connection problems than any piece of
software I've ever used, Google Hangouts chokes once you get to 3 or 4
participants and frequently has issues with even 2 participants, Duo is only
usable on Android/iOS as far as I know... does anybody have a good client that
they can actually recommend?

Myself, I've gone back to using Ventrilo because I realized that I really
don't care about having video.

~~~
com2kid
I mean sure, video chat is overrated... but the tech is there, it just turned
out it isn't quite as desirable as first imagined!

Firefox Hello worked remarkably well IMHO, it was super simple to use.

The field is full of video chat clients though. Uber-Conf is popular, although
I think the % of problem free calls I've had with them is less than 50%.

Zoom has worked well for me, no real issues.

Facebook Messenger, privacy issues aside, works well.

------
deanmoriarty
I'm in my early 30s and very aware of this, to the point where if I could go
back I'd pick a different career.

My strategy is: live in the bay area so I can get paid like crazy, live a very
frugal life much below my means, invest diligently, and hopefully have enough
money to retire in my late 30s (in a much cheaper area, of course), so that
when I'll be told that I'm too old, I'll raise my middle finger and leave the
scene with the few million dollars I saved.

~~~
pault
I'm 40 and making the most money I've ever made in my career, fighting off
hiring managers begging me to interview, and doing the most exciting work of
my career. Also, you should leave the bay area now, not later. Your crazy
money is getting eaten away by living expenses and you could have higher
discretionary income in a smaller tech hub, and you could buy a house now and
build equity instead of renting in the bay area.

~~~
deanmoriarty
> you should leave the bay area now, not later

Curious, why? I am having no problem being hireable right now at all
(literally just joined a FAANG recently).

As far as I know, it would be impossible to get the same pay I'm getting now
anywhere else. Even after considering the high cost of living, the spread
between income and cost of living is very high, and allows me to stash away a
significant amount of savings every year, to pay for my future freedom. I
really doubt I'd be able to save that much if I were working anywhere else.

What else would you suggest?

~~~
pault
Okay, it's crass but let's talk numbers. I'm currently earning $210k/year in
Austin, TX. My monthly income is about $12k after taxes, and my rent is $1,400
for three bedroom house 20 minutes from the office (wood floors, nice
appliances, yadda yadda). I save about $9,000/month, give or take. When I was
looking at relocating to the bay area I crunched the numbers and couldn't find
a realistic scenario where I wouldn't be taking a relative pay cut.

~~~
jofer
Damn... I may be more underpaid than I realized... I keep hearing from my
employer that they won't pay me comparably to my SF-based co-workers as I'm
remote, "Texas is cheap", and "No one there makes over 100k". I think it's
time to haggle a bit harder...

~~~
pault
No way, I have a friend that's a junior front end developer with three years
experience making $90k. When I do get numbers in emails from recruiters it's
140-170 for a senior role.

------
pipingdog
I will be 53 this year. I am, strictly speaking, an IC. A leaf node.

The company where I work administers a survey of all tech employees every
year, then publishes the results as a series of graphs, which can be broken
down at any branch in the org chart. The very first question is "how many
years of industry experience do you have?" The graph for my team is, shall we
say, bimodal. There's a bell curve between 1-4 years, and a spike at 30 years.

I've been building things for a long time, and I try to impress upon the other
developers on my team (or in my org) that I've never, ever, had an opportunity
to build at the scale that they're being asked to build at in their first gig
out of school. If I come off as negative, it's only because I can say with
surety that X won't work because it didn't work in the past. I expect to
learn, with my team, whether we can make things work at now scale.

There are times that I miss hours and hours of uninterrupted coding, and being
inventive at small scale. My leadership would take me out to the loading dock
and kick the shit out of me if I tried to contribute at that level.

My job is, essentially, to educate, and slap the team off of local optima. To
impress upon them that their customers are king, and that their customer base
includes themselves and their teammates, paged out of bed at 3am. And to
impress upon their management and the business that we really to need to focus
on improving operations, rather than add features from time to time. It is
also to observe the progress of, and advocate for the developers on my team.

I feel (at the time of writing... Talk to me on Monday afternoon) like I'm
lucky that my employer points senior engineers at problems like this.

------
akras14
I got to interview a lot of people in the past 2 years, and I noticed that new
grads are REALLY good at solving Leetcode type of problems.

The expectation in the industry is that Senior people would be even better at
it, because of their years of experience.

This,however, is not what I’ve seen on the ground. Most senior devs that I
interviewed, who were clearly smart and experienced took much longer than new
grads to solve most of the questions. Personally, I try not to hold it against
them, if they can clear the bar, but I wonder how many other people do the
same.

Also, I know in music they do blind interviews, were people perform behind a
curtain to avoid any biases they might have (gender, race etc).

May be it’s time to do something similar in Software, since we already are
prioritizing white board interviews above anything else?

Edit: I am not advocating for Leetcode types of questions. I do believe that
most companies hire like this (including my current company, where I get minor
if any say in hiring process). So just pointing out my observations regarding
the status quo.

~~~
pault
> The expectation in the industry is that Senior people would be even better
> at it, because of their years of experience.

The fact that a person with years of experience solves an interview question
more slowly than a fresh out of college grad should be a huge red flag that
our interview questions are bullshit and don't reflect real world challenges.

~~~
whatshisface
In one hour, you are supposed to determine what will happen if they are left
alone in their office to work for a year. How can you do it?

~~~
burnallofit
Depends on the experience level of the interviewee. If they are fresh out of
school I expect them to know algorithms and data structures and maybe some
specific topic they studied at an advanced level (like compilers, db,
graphics, etc). If they are 5-10 years into a career, they should have a lot
of knowledge about whatever it is they've been doing. If someone says they
have 5 years of Android programming, I'm going to ask them a lot of Android
API questions as well as Java.

In either case, there are questions that have multiple difficulties of
responses. The more experienced/capable they are, the more nuanced and
complete their answers will be. For example, ask a Java person how GC actually
works. Most people have very little idea, but the best talent knows a good bit
more.

But there are other variables. I've known perfectly intelligent and productive
coders who took months to build a really complex well architected system that
didn't solve the business problem and hence were a bad hire.

~~~
whatshisface
> _I 've known perfectly intelligent and productive coders who took months to
> build a really complex well architected system that didn't solve the
> business problem and hence were a bad hire._

That's an interesting statement. Isn't it usually the job of product managers
(or someone in management) to determine whether or not what's being done is
actually wanted? It is not typical for developers to be brought on under the
broad banner of "make us money please" and then set loose to email users and
determine 100% of their own direction. Wouldn't the fact that the wrong
program was being built have been caught in an informal "let me see how it's
going" sort of status update?

------
towaway1138
One possible reason for the lack of interest in older coders is that they're
largely white and male. Hardly a sympathetic demographic in the current
cultural environment.

For myself (note: am old), I'm just following the advice I've always given to
other minorities that are discriminated against to various degrees. Which is:
don't whine, and play the cards you were dealt as best you can.

The FAANGS may not, but many other employers can spot talent when they see it.
Keep looking--there's a niche for everyone.

~~~
potta_coffee
There are tons of smaller companies out there that struggle to find competent
developers. They're not necessarily super attractive jobs, and aren't as high
profile, but you can get paid well in a lower cost-of-living area to solve
some interesting business problems.

~~~
StudentStuff
If you set down any roots, your captive to that company in most lower cost of
living areas. There aren't many alternative employers generally, especially
around the same pay.

~~~
potta_coffee
It's kind of true, but every situation is different. I'm in a smaller city,
not on the coast, and I'm doing ok. It's definitely more challenging in some
ways. I make it through doing great work and networking. It's taken me a while
but I'm building up a network and now I've got more opportunities available.
YMMV, I know everyone has a different experience.

------
drugme
_Blenkhorn says that once she was back on the job market, the ageism she
experienced was compounded by sexism. Despite her profound technical
achievements, she was dismissed by recruiters as irrelevant and dull, as a
“mom.” She recently completed a PhD in computer science and hopes the
education will improve her chances in the job market._

Which is practically infuriating to read, once you take even a passing glance
at her easily findable profile.

If recruiters are really saying that about her -- this just shows (yet again)
how utterly useless they are at what you would think would be their core
function:

That is, identifying and promoting technical talent.

------
kokokokoko
I'm getting up there in age and have always resigned to the fact that I'll
probably be making significantly less money in 10 years or less in a low
skilled job unless I get lucky. I don't want to go into a full management role
in software so it's just something I've accepted.

I'm not sure how I feel about it. Sometimes I just feel fortunate for the
career I've had. I mostly wonder if I'll miss it or be glad to move on to a
new chapter.

~~~
JKCalhoun
Same boat — mid 50's. (Crazy how I didn't see that happening.)

For me it's a combination of 1) I see the writing on the wall: they don't
really want me in this profession any longer and 2) I'm getting tired of it
anyway — increasingly less willing to (laterally?) "move my skills".

Begrudgingly learned Swift (I like it tho). Begrudgingly learned every new
code management system that has come down the pike....

I'll switch careers and move on, go back to "service sector" pay scale.

Maybe I worry more for the current crop of programmers. Those of my generation
did all right — had fun. The industry is changing and not necessarily in a
direction that looks enjoyable.

------
MrStonedOne
The doubling rate of programmers has been 5 years for pretty much most of the
industries history.

This means, right now, half of programmers have been doing it for less than 5
years.

This is the primary reason older programmers seem oddly rare, 87.2% of
programmers are less than 15 years into their career, 75% less than 10.

~~~
swagtricker
Now the interesting question is - what's the churn rate for those same
programmers? Be it into seat-warming work like management, fluff work like
"sales engineering", or exiting the software world completely?

~~~
thekhatribharat
Why do you think "sales engineering" is fluff? Ref:
[https://en.wikipedia.org/wiki/Sales_engineering](https://en.wikipedia.org/wiki/Sales_engineering)

------
hellllllllooo
I've worked with at least 3 older IC software engineers (close to retirement
age) and their experience has been invaluable in forseeing issues that younger
people don't spot in advance due to limited experience. Also the breadth of
the work that these people have been involved in is very useful in being able
to pull experience from other areas into an unrelated project. I genuinely
don't understand the bias against this unless the person is unwilling to learn
new things which hasn't been my experience.

Hopefully this attitude will change as the valley ages and people will learn
that a lot of software engineering principles don't change as quickly as the
buzzwords do.

------
lgleason
All of this boils down to the same thing. Labor arbitrage.

D&I benefits those trying to increase the supply of coders and via supply and
demand reduce the rates. Older engineers are going to want more money etc.. Of
course a nice benefit with the movement (for those who want to exert downward
pressure on the wages) is that many D&I initiatives also tend to be ageist.
IE: accusing the previous generation for enabling bad behavior, stating that
the majority of older workers are white/male anyways etc.. Older workers
generally are more skeptical of the D&I efforts. The D&I supporters have a
penchant for getting people fired etc. for expressing any dissenting views
against the cause...even if the person expressing the dissent is an under-
represented person.

For the ones trying to reduced labor costs it kills two birds with one stone.
They get an expanded pool of labor. Plus the D&I crowd does most the dirty
work for pushing out older workers. Now rinse wash and repeat with importing
workers from low cost countries. The rich get richer and the rank and file
engineers get caught up in the battles as either active participants or
collateral damage.

It has very little to do with doing things that are morally right and all
about money. The moral outrage distracts everybody and keeps the infighting
going so that the labor does not organize and target the real problem.

------
gambler
At this point I am convinced that the stack treadmill most of IT is jogging on
gets propped mostly by the people who want to up their salaries by keeping as
many people out of their niche as possible. Older devs probably get hit by
this harder than most, because I'd imagine the treadmill gets more tiresome as
the time goes by, you see more hype cycles, and become more aware of it. But
older devs are by no means the only ones who are affected.

"Keeping up with with new technologies" is generally a euphemism for "uses a
random set of frameworks I chose". Amusingly, devs who demand everyone to
learn their frameworks are often the same people who try to stop anyone at
their company from using or doing anything genuinely new, because it would
undermine their position.

This is, BTW, why there is so much talk about the "shortage" of software
engineers right now.

~~~
fuzz4lyfe
I'll be 30 fairly soon and am I the only one who doesn't find learning new
technologies all that hard? Is it going to get harder soon?

In my experience a database is a database, even if you call it something else.
Really a database isn't too different from flat files with some helper
functions to make rooting around them easier. In turn that's not to different
from storing the information in RAM. Different ways to get at them but in the
end you have the same bits in that string.

Same with programming languages, I don't know the specific one you use perhaps
but I move between C, Python, Javascript and Go without much friction
(Jetbrains IDE's are helpful for when you forget specifics of syntax after a
time away from a language). Sure I have to look up some how something is done
in the standard library of one language vs another but I've gotten pretty
quick at that. If I'm working on a existing codebase I can look how similar
problems are solved and replicate that style.

Containerization, Lamdba, serverless. It's the same old code running in new
ways. I don't know what value to edit in the config file but that's just a
google search away. At the end of the day its "I need to hit this endpoint and
get this back" same story, different cast of characters.

I don't mean to humblebrag or anything but it seems like a non-issue to me. I
understand how computing systems work generally and the laws of physics impose
some hard limitations that sort of massage any solution to look similar enough
to any other that it isn't that hard to figure out what is going on. Sure I'll
lack some of the deep knowledge that someone who has focused solely on these
set of technologies may have but honestly most of the programmers I meet don't
have that to begin with.

~~~
seanmcdirmid
The problem isn’t really learning the new technologies, but more finding the
right projects to practice them with. As anyone knows (but especially
experienced devs), simply learning something doesn’t convey much mastery,
especially if you are used to more mastery than simply newbie levels.

------
kiawe_fire
It seems many people either think older coders are experienced and wise, or
old and stagnant. Younger coders likewise either young, foolish "wheel re-
inventers" or up-to-date and ambitious.

So far, I've not seen any pattern to back this up. I've worked with a few
coders in their mid-20s that knew PHP or Java very well, but refuse to learn a
front-end framework or Node JS. They act as though the burden of learning a
new stack when they've already learned what they know from school was too much
to ask.

Likewise, I've worked with coders in their 40s and 50s who still love learning
new technologies, and are more than happy to learn the new "Javascript
framework of the week", especially if they see the benefits it provides over
what they currently use.

I'm in my early 30s and have a strong distaste for Electron, but I know a
mid-40s coder who loves Electron and would never code a desktop app any other
way.

I find myself reading about Smalltalk and NEXTstep and am continually
impressed with the solutions of the generations before me (and their respect
for their users' resources) while the coder in his 50s I've worked with loves
that we live in a time where trading RAM and CPU for easy maintainability is
the norm.

What bothers me isn't just the ageism, but also the absolutism based on
anecdotes. It seems to me that the same person who would dismiss an older
coder based on age, is also the kind of person who would, say, "never hire
someone with C# experience even if they have Python experience, because we use
Python and anybody with C# experience is slow and inflexible" (real thing a
manager once said) or "never hire someone who prefers to use Sublime Text
because we use a 'real IDE' like Netbeans" (again, thing a manager once said).

Hire the right man or woman for the job. Pick the right tool for the task at
hand. Be open to new technologies and using them for their strengths, but also
learn from the good and bad things of the past. None of this seems that
difficult to me, yet it seems is a continual problem in the field.

------
notacoward
I'm 53, which makes me about twice median at my company. A lot of this rings
true, but I'll add one more twist on the "hard to keep skills up to date"
aspect. Keeping up with all the technological churn across the industry is
damn near a full time job.

When you come out of college, you might be pretty close to the state of the
art because you've been doing nothing other than getting to that exact point.
Then it suddenly gets harder, because most of your time is spent working on
whatever technology you already have instead of ramping up on new ones (plus
eventually family and such).

Sure, you can try to weave as much learning as you can into your job, but it's
almost never enough. Most people will end up getting further and further
behind, or more and more specialized. The harmful effect of the first becomes
apparent quickly; the second can actually be quite lucrative for a while until
suddenly it isn't. Either way, at some point your knowledge becomes pretty
severely devalued until you go back to spending near-full-time to catch up.

It's hard to blame employers for favoring newer knowledge over older, but the
effect on older _workers_ is still pretty profound.

~~~
int_19h
One thing that I've noticed is that a lot of "new" stuff gets less exciting
over time, because _you have seen it before_. First time is always exciting,
but when it gets rediscovered later with relatively minor incremental
improvements, it's kinda meh. And that, in turn, affects the motivation to
learn the details (that you need to learn to be able to use that stuff
productively).

------
jeffFrom18F
Maybe a little off topic, but I find it funny how big a deal people make about
going to tech conferences. I never got it.

For context, I'm 37. I watch conference topics on topics I find interesting
but they're often just mildly informative, definitely not the type of thing
I'm going to travel halfway across the planet to see live. A lot of the time
it seems to be more about making a name for the person or the company they
work for. It seems the number and prominence of tech conferences has exploded
in the past few years, I don't even remember hearing about these at all when I
started out (mid-00s).

~~~
blihp
For those doing it right, it's about networking and/or making a name for
themselves rather than the actual content of the conference. I've gone to a
couple and agree that the content itself generally doesn't warrant the trip.

------
rifung
> But the IC track is flawed. The programmers I spoke with said that promotion
> is slower on the IC track, and the distinctions between titles are blurry.
> According to David Golden, a 45-year-old engineer at MongoDB, “In the
> development-only track, there’s a bigger hurdle for me to move to the next
> level. It’s not clear how you get from one to the other and whether it’s
> something you can actually do anything about.”

In my opinion, this is both true but not a problem. The reality is that it's
much easier to have a large impact as a manager than as an individual
contributor. I have worked with L5's, L6's, and L7's, and honestly I couldn't
tell the difference between them. That's not to say the higher level people
didn't deserve to be higher level as they had more accomplishments, but I
personally didn't really feel like they had much more impact, if any.

For all but the largest and most complex projects, there aren't really going
to be sufficiently difficult problems that it makes a big difference. I don't
think I've ever been on a project where there were more difficult problems
than engineers capable of solving those problems for any level of difficulty.

> Based on interviews with a half-dozen programmers, it is clear to me that
> companies should create a qualitatively different role for their most senior
> individual contributors. Candidates for such roles would be judged by their
> past effectiveness, the same as managers are, not by a fast-churning
> checklist of skills. Greater clarity would mean engineers could climb the
> ladder faster, and the prestige and renewed intellectual challenge of each
> level would keep programmers motivated into their fifties and sixties.

> Proven engineers who occupy the most senior roles should be deployed to
> solve the hardest problems on the most critical projects.

At least at Google, being judged based on past effectiveness and being given
the hardest problems is already true. Or rather, higher level engineers have
greater independence to be able to choose what problems they'd like to solve.

------
semitext
Employers don't want to hire jr engineers because they're too inexperienced,
and are too liable to make mistakes. And employers also don't want to hire
older engineers who are too expensive, and are less willing to work nonstop.
Those are strong signals about what employers in general think of employees.

------
botswana99
Try to replace the words "old developer" with "woman developer" or "black
developer" and playback the comments people make. It ends up pretty appalling.

People who are good at development can't be determined by any outside criteria
-- you have to talk, test, and learn about them. At my company, we have
developers from early twenties to early sixties. We don't care about any race,
gender, background, anything -- all of it's immaterial to whether you can
create and code. Join us:
[https://www.datakitchen.io/company.html#hiring](https://www.datakitchen.io/company.html#hiring)

------
mnm1
> In 2007, Mark Zuckerberg, then 22, said out loud what many in the software
> industry think: “Young people are just smarter.”

How dumb or gullible does one have to be to actually think this? I'm betting
it's mostly the 20 something year olds that would ascribe to such stupidity.

Let's just accept that there is no track for programmers period. There are no
promotions beyond senior at most companies. You peak in your early 30's and
then you continue to work at about the same compensation and level for the
rest of your career. A few people can find more interesting work, but it will
require jumping to different companies and a lot of self-training. Unless it's
at FAANG, all that work will be for an extra ten, twenty, or thirty thousand
dollars. And raises? I've never hear of such a thing in any industry these
days.

The best option is to keep on top of your skills, find a job working 25-40
hours a week, possibly remote, and find some meaning in other parts of your
life. Work isn't everything. It's not even the most important thing.

There are and will be plenty of jobs for older coders. It's a new profession,
but older coders who stay on top of the tech are still plentiful. You just
need to know where to look. Also, many people don't make it as coders period.
If there is a shortage of old coders, it's because people drop out because
they can't make it. Even better for the rest of us. As if being in your late
thirties is old. What bullshit.

------
danbmil99
I'm ancient by HN standards, but I still find my skills are in demand. I would
categorize myself as a lifelong learner; I got into python over 15 years ago,
mongodb almost 10, and I have taken the time to understand what I need to know
about front-end frameworks like angular and react. One employer called me a
Swiss army knife, and I take that as a compliment. My knowledge is quite broad
and quite deep, though I'm not a super expert at any one thing and I can't
claim to know everything about everything.

However I have several friends around my age who never bothered to learn
anything beyond C++, and they are definitely struggling. They either are stuck
in jobs because they're the only person who knows how to recompile some
ancient module, or they're out of work and freaked out about the future.

Ageism is real, but so are some of the stereotypes. Older programmers are
often going to be more resistant to change, and can be more sure of themselves
even when they're wrong. The flipside is they often have forgotten more than a
young programmer even knows.

Present Valley hiring practices seem to optimize for general aptitude, and
downplay or disregard the value of experience.

There's also the undeniable fact that older people in general have built up
more obligations and responsibilities, and are often more skeptical of the
value of equity because they've been a few startups and their options never
amounted to anything. Therefore, they are going to prefer stability and cash
over the promise of future rewards.

------
daxfohl
I think to age well you have to consistently push your limits. "Learning new
things" and "keeping up with tech" is a bit overrated.

If you're 50 and you've spent many years drilling down through increasingly
deep scalability and throughput challenges, that will increase your value
beyond what any fresh-out could provide.

If instead you spent your time learning a new JS framework each year and are
proficient at 30 of them by age 50, good for you, but good luck finding a job.

~~~
joker3
The difference between the two cases you have isn't anything to do with limit
pushing. Instead, it's a matter of specialization. If you develop some real
depth, then that's a different matter than just being a regular programmer
who's been doing slight variations on the same thing for a long time.

That's not to say that the specialists have it easy, but they do have an
advantage here.

~~~
daxfohl
I think it does though. Or at least I intended it to.

In the first case I didn't particularly mean to specialize, but just to
continuously do things you really don't even know if you can, to continually
push against what you think is possible for yourself: _create_ a js framework
for instance, even a terrible one that you abandon after a year and move on to
a completely different project, but that requires you to dig and research and
stretch your brain. The second case was more you know it's possible and it's
just following a tutorial to get up to speed on the techniques; someone else
did the "hard" work, and you're not really getting anything out of it.

The first thing gives you skills that age well: you'll learn about lots of
gotchas about the internals of how js and presumably other language runtimes
work etc, which will help in lots of different positions; the second just
gives you a line item on your resume until that fad is gone.

------
losvedir
Anecdotes are one thing, but I think the data are important. The article
brought forth some interesting stats about the median age in the industry.
Does anyone know where that data comes from, and if it's tracked
longitudinally? What I'm curious about is if older programmers statistically
are pushed out of the field, or if it's just the case that the field is
growing like crazy and newer college grads are flooding into it.

------
prestonbriggs
I'm 63. When I was a kid (pick an age), there weren't anywhere near as many
programmers as there are now. So while I believe lots of older programmers
have gotten out of the field, one way or another, I think the remaining ones
are simply hidden in the crowd.

------
daxfohl
This hasn't been my experience at the larger companies. There's always room to
grow and stay in a purely technical role.

Prior to this I'd been doing freelance work and there it's more difficult.
Especially if you don't have any particular unique skill or tight relationship
with a solid client or a high level of marketing savvy, it's hard to compete
with kids that are willing to do things at half the price. And I think that's
fair: even though I consider myself a very solid coder, most consulting gigs
I've worked on could have been handled by someone less skilled and worked out
just fine.

------
throwaway-1283
I feel like if you're a knowledge worker who isn't interested in management,
the IC path is short-lived in almost any profession (not just SWE), no?

To me, the future isn't very bright for anyone who just wants to be an
"employee" for the rest of their life, coder or not.

OTOH, the manager path is dangerous in recession times. You lose a lot of
"hard" skills, and if you lose your cushy manager job at company A it isn't
necessarily obvious to company B what value you have when things are tight.

~~~
forgottenpass
>the IC path is short-lived in almost any profession (not just SWE), no?

Depends on where you work. If R&D is core to the business, there will be a
non-management ladder and plenty of near-retirement greybeards around the
office.

Note: many fashionable names in "tech" don't fit that bill.

------
strikelaserclaw
Too many people make the mistake of learning laterally, a little bit of
framework X, a little bit of framework Y, language X, language Y, then wonder
how they can be replaced by people much younger than them. Learn deeply, this
is something that cannot be replicated by people with not a whole lot of
experience. Tech is a double edged sword, it rewards people who are good at
what they do regardless of their age (this might or might not be a good thing
depending on where u stand on the age range).

~~~
int_19h
The problem is that you can spent a lot of time learning something deeply when
it's in a fad stage, only to see it become obsolete in a few years. And then
you'll have to learn the new fad, which is completely different from the old
fad.

OTOH if you learned a little bit about various things, it's very likely that
one of them will be that next fad, or its precursor. So when it happens, it'll
be that much easier to learn.

So it's a balance. Going either too deep or too broad can backfire.

------
thegayngler
Umm just wanted to note one of my friends started a meetup group for over 40
coders in NYC. I'll update this post with the link to the meetup. I'm gonna
contact him now.

~~~
thegayngler
Here is the links promised. [https://www.meetup.com/certain-
coder/](https://www.meetup.com/certain-coder/)
[https://www.meetup.com/techover40/](https://www.meetup.com/techover40/)

------
lliamander
1\. On keeping up with new technologies

There are a lot of skills churn in this industry, and even as someone still on
the young side, I'm rather leery of this trend. I imagine much of this trend
has to do with the fact that the population of programmers is still increasing
at a significant rate. I heard somewhere that the population of programmers
has doubled roughly every 5 years for many decades. Add to that the fact that
(as pointed out in this article) more and more programmers move into non-dev
roles as they get older. It's not too surprising that employers are going to
tailor their hiring process to younger engineers if that's what the hiring
pool looks like.

My focus has tended to be on developing proficiency with older technologies
that have stood the test of time (Unix, RDBMs, Erlang, etc.). The fact is that
when it comes to technology, the longer it has been used, the longer it will
likely continue to be used - this applies as much to COBOL as it does to LISP.
It's not that I don't get excited about new technology, but when I do I tend
to be more excited about tech that builds on the great ideas of the past
rather than tech that purports to be radically new.

I don't know how this strategy is going to play out. I certainly do enjoy
learning new things (that part of why I got into this business in the first
place) but I also want to know that I am increasing my value in the market
place by developing mastery in skills that are going to have lasting value.

2\. On the weaknesses of promotional tracks for ICs

When I was working at HP, I was told explicitly: "We promote people in the
management track to see if they can do the job, we promote people in the
technical track if they're already doing the job". I'm not sure if this is the
right approach, but it definitely does make it more difficult to stay
technical.

There are many valuable qualities that generally only come from seasoned
engineers: qualities like leadership, expertise, communication skills, project
management skills, and strong professional networks. The problem is that while
time is a necessary ingredient to cultivating those qualities, it is not
sufficient. We have to be intentional about shoring up our weaknesses in these
areas. This is something I've heard from some of the most respected scientists
and technologists - people who are arguably at the pinnacle of success and
reputation - say that they wished they had done better in.

------
jrochkind1
I'm 43, and I'm far better at writing code than I was even 5 years ago (and
I've always _thought_ I was good... including now :) ). This is an actual
skill/craft, that you get better with with time. I'm not sure what to take
from that put against the fact that old coders didn't seem to last as coders.

------
a3n
> Although I will seek older programmers to speak at PyGotham next year, I
> don’t yet know where to look.

You could look at unemployment and workforce offices that offer job search
databases to the unemployed. I went to the Arapahoe County Colorado office a
year ago, looking for training grants, and saw pretty big listings for coders.

------
_bxg1
At age 27, I find myself already qualified for most "senior" job postings I
see, which is a bit concerning.

Do any of the "older" folks here have advice on orienting one's career to
brace against this effect (beyond the typical "always be learning")? Feels
like it's coming up quick.

~~~
pjscott
This industry throws around the term "senior" the way restaurants hand out
complimentary breath-mints. It just means someone who has been out of college
a few years and hasn't been fired for gross incompetence.

------
torgian
I’m 36 and I kind of consider myself an older programmer, if for no other
reason than the fact that others my age also consider themselves older coders.

I’m not the greatest, but I get the job done and produce results. That’s what
businesses want.still, I wonder how sustainable that is.

------
ummonk
The article seems to imply that companies need to find a way for older
programmers to continue advancing up the ladder as ICs. It is not clear that
this is justified. What if there are diminishing (or even flat) returns on raw
experience as an IC beyond, say, 10 years?

------
accnumnplus1
To re-phrase this: kids, if you're getting into tech, you might want to think
again.

------
droptablemain
Oh christ, this is terrifying. _Runs off to to learn a new stack_

------
sizzle
Wouldn't working remotely solve the ageism problem?

Assuming a large component of ageism in tech might be related to narcissism
and in-group bias.

~~~
jpindar
You have to get hired first.

------
VLM
A useful cultural comparison to "coders should be turned into Soylent at 35
that's all they'll be good for" would be Bachelor Nation, which my MiL is a
part of, where any show candidate under 25 trying to get married is considered
a youthful idiot too unwise to tie their own shoes much less live with a
person and become a parent. Under 25 candidates are considered worthless and
taking up space for more realistic candidates over 25 preferably around 30.

So its an indication of an extreme sickness in a society or culture where
younger than 27 is too young and dumb to pick a spouse, then from 27 to 35 is
the only economically viable life, then at 35 they're too old to be hired
anymore so turn em into soylent they're good for nothing past that. Crazy that
our ancestors were productive members of society from 18 to 65, and the most
gaslit generation tries to hide the economic decline by claiming its "natural
or self evident" that kids these days only get to live as productive adults
from 27-35.

I mean... pro sports players have longer careers than coastal programmers...

Another hilarious analogy is the claim the building trades are horrible
because 30 years of that will destroy your knees or whatever; well, the
solution to that isn't a 8 year, at most, "career" writing code. Plenty of
50-something electricians making bank decades after their peers who went into
programming are utterly unemployable in their field...

A similar sickness can be seen in K12 school teaching where the average
teacher now has only a couple years experience before getting kicked out for
being too expensive and too many kids willing to work cheap.

Fundamentally a culture/society that is built on the demand side to have
people spend like crazy from ages 18-65, if not 0-85, is utterly doomed to
collapse if that culture is only willing to pay a tiny minority of people ages
25-35.

I would argue programming is not necessarily a career path any more than being
a carpenter or other labor job; some people will be "up or out" in five years,
but I'm not sure why someone supposedly can not program for 40 years, any more
than I have no idea why a doctor can prescribe for 40 years, or a truck driver
can drive for 40 years, or a bean counter can count beans for 40 years.

Another cultural trend somehow not mentioned is kids need the baby sitting an
open office nursery provides; if everyone older than 40 works as a contractor
for more money, its not really a problem that companies only hire children as
W-2 employees. I'm probably never going to be a W-2 employee again for a
variety of age and race and gender discrimination reasons; I'm OK with that
and enjoying making plenty of money outside the W-2 nursery.

------
ArenaSource
I would like to see a Bugs vs Age study

------
qqqwerty
I have been thinking about this a bit lately as I enter my 'mid-career' stage
and am contemplating a minor career shift (same industry, different
specialization). Also, I have some recent experience that was rather
illuminating regarding agism in the industry.

1\. The pool of older programmers is a little bit 'lemony'. The "really
talented ones" either move up into cushy roles, move into
freelancing/consulting, or start their own thing, etc., so they won't be
applying to random job listings. And most 'good to average' individuals will
build up a solid professional network throughout their career and if done
properly they should have an easy-ish time finding and getting new roles. So
that leaves folks who are a) for some reason their network doesn't extend to
the job they want (maybe they are trying to switch fields, or they are
targeting a small company with no mutual connections) or b) they are a lemon
(to put it politely). And to complicate matters, the standard programming
quizzes/whiteboard interview doesn't work too well on more experienced
programmers. Their raw programming knowledge/ability is usually good enough,
generally the issue is with something else (slow, hard to work with etc..).

2\. If you are an ambitious 20/30 something doing the hiring, unless you have
really good 'job security' (like best friends with the founder or some other
leverage) then it's probably easier to hire folks with less experience who
won't challenge you for your role. This is somewhat an extension of the 'A's
hire A's, B's hire C's' mantra, but on the axis of seniority and experience as
opposed to talent. There are plenty of senior programmers that are comfortable
being an IC under a younger manager, but there are also plenty that would
happily jump on the management track and climb right over you if the
opportunity was there. And the 20/30 something manager won't know which one
they hired until its' too late.

3\. There are plenty of industries and opportunities where seniority and
experience is respected, and many of these industries are hiring programmers.
You just have to look outside of the SV bubble. Banking, Healthcare, Energy,
Construction, etc... And because a lot of these industries operate in more
regulated and bureaucratic environments the 'SV 10x ninja' is just not that
useful. And some of the 'lemons' mentioned above, who don't fit the SV mold,
but who are perfectly serviceable employees in most regards would probably do
fine in these environments.

I also think we are starting to age out of the 'high school dropout gets $20M
in funding' era, which exacerbated the agism-in-programming issue. That sort
or worked in consumer web/app tech, but tends to fail spectacularly everywhere
else. So at the very least this 'post-40s' agism will probably start to fade,
and likely get replaced with the 'post-60's'

------
781
> He was interviewed by a younger engineer who told him, “I’m always surprised
> when older programmers keep up on technology.”

As someone relatively old, I've been in a lot of developer interviews. I also
noticed that older programmers tend to not be as up to date in newer
technologies or ways of doing things.

I don't think it's strictly limited to technology. How many 50-year old do you
know who listen to trap music? Or approve of the way teens dress these days?

It's just the classic "older people tend to be more conservative" fact. At
some point most people get stuck in the things the were doing/liking when they
were younger. The hate new music, they dismiss newer technologies (to open a
rats nest: Electron anyone?)

I'm sure I'll get comments like "I'm 18 and I hate trap music and Electron".
That's not the point, I'm talking about distributions not individual cases.

~~~
gerbilly
> I also noticed that older programmers tend to not be as up to date in newer
> technologies or ways of doing things.

I've been doing this a long time and it doesn't matter to me.

The newer stuff is most of the time just a variation on a theme that I've seen
turnover three or four times since i've been doing this.

What older coders have that younger ones do not, is experience. This can often
halve the workload on some projects. The older I get in this profession, the
more results I get out of less and less code.

Also, let's not immediately fetishize the newer stuff. It is often a less well
implemented retread of older technology. Seems like people have less patience
for learning existing systems, so they just re-write some quick and dirty
replacement and call it good.

Perhaps it might be better if younger programmers learned the old stuff
instead of just badly reinventing the wheel every few years.

~~~
unimpressive
>Perhaps it might be better if younger programmers learned the old stuff
instead of just badly reinventing the wheel every few years.

I think if you pick a concrete example of this phenomena (say, Java applets
vs. WebAssembly) and you ask "so why didn't someone take Java Applets and
update them, why do we need WebAssembly?", the answers to why this happens
start to become more apparent. It's not so much that Java applets were good
and then we decided they were unfashionable, as that Java applets were always
kind of ugly and we eventually stopped tolerating them.

For examples from before say, 2000, say Turbo Pascal a lot of the answer is
because the thing in question was a proprietary product so once the
financially backed dev team stopped working on it users were forced to move on
to something else. Other times it's because the thing was written for an 80's
computer platform that no longer exists outside of emulation and
retrocomputing collections. Sometimes it's that the graphical standards the
original used were for hardware with very different capabilities and making
the thing usefully work on a newer system would almost require a total rewrite
anyway.

Even beyond all that, there's another problem: Software is fairly hard to do
literature review for. If I want to know if a particular research idea has
been done before, I can hop on Google Scholar and figure it out with a few
hours of carefully constructed search queries. Doing the same thing for
software is very difficult, especially because most products for the majority
of the fields history were proprietary. As a consequence, we don't have our
history available to analyze in any easily accessed form. The Internet Archive
has been doing what they can to rectify this situation. (See:
[https://archive.org/details/BeyondCyberpunkMacintosh](https://archive.org/details/BeyondCyberpunkMacintosh))
Nonetheless, there are still serious problems in this area.

I'm a younger person (23) who shares your frustrations, but I don't think that
you can really wag your finger at people when there are real barriers to what
you're proposing.

~~~
thaumasiotes
> I think if you pick a concrete example of this phenomena (say, Java applets
> vs. WebAssembly) and you ask "so why didn't someone take Java Applets and
> update them, why do we need WebAssembly?", the answers to why this happens
> start to become more apparent. It's not so much that Java applets were good
> and then we decided they were unfashionable, as that Java applets were
> always kind of ugly and we eventually stopped tolerating them.

I've been asking this exact question on various HN threads with WebAssembly
announcements, and the answer is always one of "Applets are insecure" or "Java
is insecure".

So I don't really follow your example here... whatever security model you want
to have, it seems much more obvious to implement it for Java applets than to
implement WebAssembly and then implement your preferred security model for
WebAssembly. Why do you think we replaced applets with WebAssembly?

(It's kind of a leading question -- my experience as a browser user suggests
that we stopped using applets, spent a while not having them, and then started
working on WebAssembly. By that analysis, we never replaced applets with
WebAssembly -- we replaced applets with nothing, and then replaced nothing
with WebAssembly. That would tend to support the more crotchety answer of
"people developed WebAssembly because they just forgot about applets".)

~~~
le-mark
My understanding was that the concern wasn't necessarily that the jvm was
insecure, or the browser was insecure (although they've all had
vulberabilities at one time or another) it was the integration between the jvm
and the browser that was difficult/impossible to get right. This not only held
for Java but any browser plugin (flash, silverlight). The entire concept was
just bad.

Now where webassembly comes in is a compilation target for _anything_ to the
browser. I had the sorry misfortune of working on a project that had an applet
that interacted extensively with the host page. It was excruciating, the api's
were not up to the task. At the time, before the canvas tag, that's the length
we had to go to get "advanced" functionality into a page. Nowadays that could
all be done with js (or X compiled to webassembly) and canvas element. Things
evolve.

------
0x8BADF00D
IC doesn’t seem like a viable track. Consulting in a specialized area (i.e.
FORTRAN or COBOL mainframe programmers) seems to be where it’s at. Beef up
your network and you can setup a gig consulting at upwards of $200/hr on some
obscure system that very few people know about.

~~~
solotronics
Please forgive my ignorance. I taught myself C/C++/python/etc. enough to get
paid well to do it. There is of course a ton of easily accessible examples and
documents for these languages. Does the same apply to FORTRAN/COBOL? Are there
emulators to use to teach yourself? If you were to do this where would you
start?

~~~
dmitriid
I’ve now seen bootcamps that previously taught python/go/java set up courses
for COBOL.

E.g. this free (!) intensive course in Sweden:
[https://www.academy.se/artiklar/tieto-och-academy-startar-
ko...](https://www.academy.se/artiklar/tieto-och-academy-startar-kostnadsfri-
intensivutbildning-for-de-som-vill-sadla-om-till-programmerare)

My hunch that consulting jobs that require COBOL are primarily looking for
experience (especially with finance systems) than for 40 years experience
specifically with COBOL.

------
BXLE_1-1-BitIs1
The smart young coder needs to plan for being tossed on the trash heap
somewhere between 35 & 45\. So live frugally and build your "on the trash
heap" fund.

~~~
mrmuagi
Sounds like you are describing FIRE -- (Financial Independence, Retire Early).

------
TheMagicHorsey
Most older programmers want to be paid more because they are old. Not because
they bring added value. That's the issue. I'm over 40. I have no issues
getting the compensation I think I am worth. I also am not embarrassed to be
paid the same amount as people ten years younger than me. I'm not adding more
value than them on a productivity basis ... so I should not get paid more.

Truly excellent programmers in my age group are absurdly well paid as
consultants. But it takes courage and extreme productivity to live like that.
Most people my age don't have the gumption to do that.

