Maybe it's just me but with all the rampant age discrimination nowadays in tech, I really don't like to see the continued propagation of this stereotype.
All sorts of people of all ages are unwilling or unable to update their knowledge of new tech, there is no reason to link this characteristic to someones advanced age.
I can see how my choice of wording created an implication that people who have grey beards are old and that it is this oldness that contributes to their unwillingness to learn. The familiar cliche of "you can't teach an old dog new tricks".
What I actually hope to communicate is that there is a hubris which leads some to believe their skills do not require updating. The caution is that sooner or later this hubris may lead to sudden downfall. People may call on you in their time of need and you will fail. And this failure is not because of your age, your intelligence or your willingness to work hard. You will fail because you became overly comfortable with a passed status quo and you let your skills get out of date.
I see a trend of well-written, evidence backed articles where large, well funded sites are making a case to deprecate jQuery. These fact-based investigations into problems faced by their dev team result in a reasoned decision to remove a dependency that no longer justifies its cost. I encourage everyone to introspect if their defense of jQuery is on an equal technical footing to these types of investigations.
But speaking as someone who writes vanilla by default, it really really isn't as big an issue as you think it is.
You are wrong.
This is a strawman argument. It's a biased view you hold. Because of that, you make up a story to match your biases around people who use such-and-such library don't think they need to update their skill set. I'm not angry about this, but am only pointing out biased arguments create dissonance.
> I see a trend of well-written, evidence backed articles where large, well funded sites are making a case to deprecate jQuery. These fact-based investigations into problems faced by their dev team result in a reasoned decision to remove a dependency that no longer justifies its cost. I encourage everyone to introspect if their defense of jQuery is on an equal technical footing to these types of investigations.
You read something somewhere about how jQuery is a costly dependency. Yet, there are no links that I can see anywhere in the threads here, nor a good rational argument for people to NOT use jQuery because it is a costly dependency. There are opposing opinions on this, but the opinions that it needs to be included via CDN don't address the fact it can be hosted locally and the opinions "who needs all that code to load?" don't take into account that browsers and networks are bonkers fast nowadays. Who cares if it's a bit more code? It's not like jQuery is growing its codebase at the rate compute and network speed increases.
For that matter, could not the same argument be made of JavaScript itself? I taught myself Promises, not because I could stay "relevant", but because it makes good sense to write code that is easy to read and maintain, even if it is me doing both on my project. The code I produced when I wasn't doing Promises was "legacy" the second it hit the repo, and will be "costly" if someone else has to jump in and work on it to convert it to Promises, because they'll have to brain dump what I was thinking (or not) when I wrote it!
This salt and pepper beard stays up on technology. I didn't really write code in the past, but now I'm great at what I do and I fully intend on exploring new technologies when they compliment what I can do rapidly in the frameworks and methods I well understand, if that's what it takes to get to market faster.
Well, Gov.uk for one, as per the article you're commenting on. As they pointed out:
> Not everyone is tapping away on their 2022 MacBook Pro on a rip-roarin' broadband connection. GOV.UK has to be accessible to everyone, and that means keepin' it lean.
> Here's a few of the greatest hits from Matt Hobbs on what GOV.UK noticed in removing jQuery:
> - Less front end processing time overall.
> - 11% less blocking time at the 75th percentile.
> - 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.
If you're making a game, say, you may (may!) not care if Edna can't load it on a 1993 iMac, and you might be loading 40MB of resources, so another 24kB is not your pressing problem.
Engineering effort is always in short supply, and it is very expensive. Use it wisely. Sweeping judgements gleaned from very different products may not apply to your case.
> This is a strawman argument.
I'm not sure I follow. It reads to me like the original commenter is arguing that jQuery supporters have out-of-date knowledge. What's the strawman? jQuery supporters?
> his knowledge
Women are programmers too, and there are older ones out there maybe shaking their head at this type of judgement.
To try to shoehorn this back into the compiler analogy, modern frameworks would be like the advanced, complex and opaque compiler, and the grey beard is the guy that understands how stuff like HTML streaming and font download prioritization and hidden classes affect performance, whereas the team lead is analogous to the run-of-the-mill bootcamp grad that knows how to use the framework-du-jour but is way out of their depth if venturing outside the comfort of the framework and into the depths of those advanced topics.
And I think the gov.uk use case here might actually be an outlier in the sense that it actually considers performance of an already tight codebase, whereas a lot of jQuery deprecation efforts bring with them heavier alternatives in the name of maintainability or developer productivity or hiring or whatever. To be clear, many of these concerns are quite valid, but it seems a bit disingenuous to create a false dichotomy between understanding of low level concerns vs concerns about SDLC management. They aren't mutually exclusive.
If your expertise is in low-level browser performance but you lack deep knowledge of React/etc, your skills aren't of diminishing relevance, and probably won't be for a long time.
Something like Angular.js is a more apt example of a skill people still do advertise as a primary thing in their resumes these days and it most definitely plays into the diminishing relevance thing. On the other side of the spectrum, you have newbies writing down "HTML/CSS/Javascript" in their resume, which basically screams zero experience (aka "low/no relevance until they learn to speak the cool framework lingo"). There are plenty of other quote and quote "uncool" skills in actual resumes. Flux. Sagas. Ember. Etc.
So, yes, an argument can certainly be made that recruiters/interviewers do "discriminate" against various stereotypes to various degrees, and it isn't necessarily always based on ageism. A recruiter that reached out to me recently had an interesting term to describe this phenomenon: "skill commoditization", aka looking at people as snapshots in time, and evaluating some skillsets to be intrinsically worth less than others, even if they have some amount of overlap, instead of looking at people as malleable entities. It's worth thinking about how treating developers as commodities might hurt your hiring, especially if your hiring revolves heavily around evaluating for expertise in a specific framework.
But you kind of do have to be old in order to have outdated knowledge: nobody young is going to learn assembly tricks which worked on MIPS and other past architectures. Older devs and companies not constantly learning new things and updating to best practices is a real phenomenon.
On the other hand, anecdotally most older developers actually do keep up to date with the latest best practices. And there are lots of decades-old frameworks which aren’t obsolete: lots of people greenfield projects with C++ and Spring Boot and .NET, and unless I’m mistaken the C ABI and system calls haven’t changed much over the past ~40 years. So it's not like being old automatically means or even really suggests you're going to use worse, outdated techniques.
I'm not so sure. Google and StackOverflow are chock full of outdated (sometimes dangerous!) advice and knowledge on just about any tech subject, which hurts the young as much as the old.
I've seen just as many outdated suggestions from junior devs repeating the first thing they found on google as I have older devs with stale knowledge. I'd probably argue the former has been a larger problem, honestly.
Not in the frontend dev space. I once left it for 2 years. when i came back it was a whole new world
If any student leaves that program with a modern perspective of web dev (such as using Redux or even RTK), it will be due to their own personal grit.
C'est la vie.
No, this generalization is quite correct. If you went to a bootcamp which was not such as Hack Reactor, then perhaps you may wish to promote the program by name and discuss your experience there.
Hack Reactor has made Redux completely optional and so almost nobody choose it for their projects. This may have been in response to transitioning to an online-only program. If students understand anything on the "React ecosystem" including even Redux, it is due to their own personal ambition. If you see Redux explicitly listed in their curriculum, do not be confused.
If you see students with Next.js, RTK, or any other framework or library from the React ecosystem on their portfolio, that is due to their own grit.
I've also seen the opposite of what you'd expect: a young startup with a very young team that functioned on outdated practices and tools. My first contact with their codebase was a shock to the system – a mishmash of competing coding styles and conventions, barely any of them a best practice, much of it not very idiomatic, an alarming lack of consistency. The choice of tools, libraries and frameworks was (by startup standards) definitely not best in class, and where good choices had been made, the joy was short lived by realisation that they were on old versions, or not using their tooling properly.
But, anecdotes aside, there's a point that generally gets overlooked. Best practices and good developer experience are the result of intentional choices, often in retrospect. The only way to come up with best practices or to improve DX is through experience -- especially poor experiences. I mean, who would've thought that experience was an asset.
As an old guy I would find it very hard to keep up to date with the "latest best practices" because I tend to think of "latest" and "best practices" as antithetical. JQuery is a good example: I never invested time in it since I figured it would pass. I could smell it from the way kids were raving about it. So this type of article foreshadowing its demise is nice to see. Like when you drag your feet on some looming deadline at work and some force majeure makes it completely irrelevant.
Either that's wisdom from an older dev that has been burned in the past or that's just an old dev set in his ways. Take your pick. ;-)
To be sure, when I began a good dev was good at memory management (ha, ha).
More recently, a good dev is one that is good at concurrency.
New devs might not understand memory management, should they though? Has everyone come across (at least once) where a junior dev creating an "integer object"? Or perhaps an object to represent a character?
When I began I rarely even saw a single secondary thread in code, very rarely saw the need to create one. Then again, one core machines so.
What I have seen is awkward situations where you have two developers of roughly equal competence. One happens to be 45 and the other 28. Fine, nobody would care about that. Except that due to automatic annual raises, job switches, seniority bumps etc, the 45 year old developer is paid twice as much as the junior.
The rational response to this would be to say to align the two salaries (probably somewhere in the middle), but obviously the older one is never going to accept that - we all expect our salaries to "ratchet" upwards. So we end up with the irrational response, which is to sideline/kick-out the old expensive developer
That, to me, says there's plenty of ageism.
If it was as simple as "they ask for too much", then someone would snap them out of it and we'd see plenty of older devs at software companies. Maybe less than younger devs, but plenty anyway.
Honestly, I'd prefer if there were more older engineers to show the younger ones how dumb they are. Maybe better at building dynamic frontends, but dumber. That kind of seniority is sorely missing in software engineering, and it would drive standards upwards rather than downwards as they currently are.
I'm currently in between, and wish I had more mentorship.
I agree with you here - the question is why? I don't think it's because we're discriminated against for being old, I think it's because in 99% of cases (we can't all be donald knuth), our cost grows faster than our skills. So we either move to management/business (where experience matters more and it's much harder to quantify productivity), or we become "the overpaid one".
> If it was as simple as "they ask for too much", then someone would snap them out of it and we'd see plenty of older devs at software companies
But they wouldn't snap out of it. (a) in most countries you can't demote people, (b) it's very hard psychologically to accept being paid less for the same job
> more older engineers to show the younger ones how dumb they are.
I'm talking about 45+ vs 30 years olds here, not 30 vs 23.
I think a major factor is that the field just exploded so much over the past 20 years. Statistically, people over 40 are going to be in the minority.
I also do think a lot of startups maybe aren't the best place for older people. My brain wastes a lot of cycles on edge cases I've learned to identify from experience, that don't matter if you just need to slop some shit out the door ASAP.
Following from that, it's easy to imagine that a bunch of the older engineers that you don't see at software/tech companies have in fact graduated into extremely well-paid, long-term roles working on software for banks, insurers, utilities, resource companies, whatever.
Seniority bumps, x-weeks-vacation-after-y-years-of-service reward that intangible.
Yep, especially culturally rather than financially. Almost everywhere I've worked there was the implicit assumption that engineers graduate out of coding jobs into management roles. In a lot of places there's the idea that focusing on writing software is some sort of career dead-end for older people which is a shame for anyone who just likes coding. I think it's widely perceived as a young person's job for no good reason.
And on the business side it's also pretty blatant. IIRC founders in their 40s are statistically most successful. Yet prominent people in the industry still openly fetishize youth.
If your answer is that 'it's just part of the story'. Well that's precisely the complaint.
It simply means someone experienced/being at something for a long time. The greybeards at a company can be all women of the age 26, but if they been with the company for 5 years when the company got started 5 years ago, they are the greybeards of that company.
Might as well say "veteran" or "old-timer", although "old-timer" would imply actual old age, "veteran" implies nothing like that.
Greybeards is an inclusive term and it's a well known term.
> Maybe it's just me but with all the rampant age discrimination nowadays in tech, I really don't like to see the continued propagation of this stereotype.
I would agree. If you last a long time in tech, you're more than the sum of the libraries you've learned.
In 1998 I was in a web development class with a guy, and one time I went by his house and he showed me his little resume site he was working on. It was really nice looking, he had a great sense of design, I could have made it but I couldn't have designed it. But it was all table based, so I showed him CSS and extolled its virtues.
After which he exclaimed furiously "That's the problem with this industry, there's always new things to learn!"
He was just starting out and was already unwilling to update his knowledge of new tech!
I think he's working as a SiteCore admin in Dental association now. I'm pretty sure he has a nice work life balance, so make of that what you will.