Well, I've never read a report like that before but it all seems wonderfully exciting. Go ahead, full speed.
But if it all goes wrong then none of it is my fault.
A growing body of research continues to show that older workers are generally more productive than younger employees. Annie Coleman, founder of consultancy RealiseLongevity, analyzed the data and highlighted a 2025 study finding peak performance occurs between the ages of 55-60. Old people Survey: Tech workers are terrified …
I've accumulated more than enough cynicism experience to be highly sceptical of these kind of studies.
On the other hand, if it helps con the youth of today into asking their grandpas how to draw a circle using Bresenham's algorithm, do modulo 7 arithmetic without executing divide instructions, or put a VGA monitor into Mode X, then I'm all for that sort of thing. A little bit of appreciation for the sheer compute power we all have at our finger tips these days can go a long way.
* get off my lawn *
Yeah, seems like as Logan's Run hits the big 5-0, its basic premise needs chopping by the big computer with lasers, again!
I got made redundant at 50.
The engineering director said I was overpaid and incapable of learning anything new.
Then kept me on for the full 3 months, while everyone else who was made redundant got gardening leave.
Needless to say I sat in the corner signed up for a few online courses and practiced interview questions.
Got a job offer on the second interview paying more.
Looking back the work environment had become quite toxic and I should have exited years ago.
I've been saying that for years, and I know of many good IT people from 35 onwards who have ended up making career changes because of that attitude.
But I got made redundant a few years back because they thought I was too old/in wrong location/paid too much, knew (important) legacy stuff etc. etc.
Within less than 3 months weeks of leaving them, I was snapped up and spent a few more years being paid more, with less stress, predictable hours and recognition of the value of my experience and knowledge.
When I left them, I decided it was time to go and retire.
I told my prospective employer during the interview process that the job, should I be offered it, would be my last. He looked a bit puzzled. I told him that when I'd left, it would be to retire.
When the time came, I gave them 6 months notice. I'd been there 4.5 years when I said 'I'm done'.
I walked out on the friday afternoon and that night, I was on a ferry to Santander and a biking holiday.
I never felt the need to go back to paid work. I retired in Sept 2016, almost 10 years ago.
I'm busier than ever these days.
"I'm busier than ever these days."
If it's your cup of tea to travel and do a lot of biking, cheers.
I've always done work that I really enjoy which has changed over the years. I've scaled back how much work I will accept since I have to accept I just can't keep the same pace as 10 years ago, but it means I've really been able to improve my photos and charge more for more money than I made cranking out quantity. The product development work I do has slowed down as customers have dropped off over the years and I haven't been going out and finding many more. I feel I keep getting better at it so I've upped my charges and that's been fine so I'm concerned I've been leaving money on the table.
Something new has been buying tech at estate sales and reselling it. There's lots of aerospace companies around and many of the employees that retired from them stayed in their paid-for homes. They've left behind shops full of electronics, tools, books and trinkets that are worth good money. Since I know what the stuff is, I can sort out good deals from bad when bidding against other people and a few of the companies that do the estate liquidations will let me re-visit the properties after the sales and "help clear out" the remaining stuff that will often be headed for landfill. I handle wiping computers for them and other services in trade. You never know what's in the fruit basket until you get the pineapple off the top. The additional run through without loads of other people around has let me find all sorts of valuable stuff. I'm not talking money for a night at the cinema either. A recent haul has been exceptionally good with a re-visit possible in a week where I know there will a car load more worth a few grand.
The estate sale lark might be my main source of revenue over time as I reinvent myself again in a way that I can keep up with. My mantra has to always keep work interesting and to try new things. Acting was fun, but I didn't see a long term career in it. Still got to be in a few feature films. Being a roadie for a number of years was good experience, but not easy. That was before the internet and cell phones. The last few gigs I did some years ago as a drum tech for a good friend was really exhausting. I was just filling in for his regular guy that had a medical issue. No way I could have done lighting or sound. I won't even try to get a sheet of 18mm birch ply onto the table saw without help.
My friend had a job wrap up and after sending in resumes to many jobs he asked his recruiter buddy what he could change to help things.
The recruiter reviewed his resume and told him to not show any more than the last 5 years experience on the resume unless they were specifically asking for proof of longer experience.
He told him it flagged him as old...
"The recruiter reviewed his resume and told him to not show any more than the last 5 years experience on the resume unless they were specifically asking for proof of longer experience."
When I was out shopping for "real" jobs, I tailored my resume for each one. I dropped graduation dates for a simple entry of the degree I received and the university, not the year. I kept my resume in long form with two versions of past job descriptions, long and short. I wanted to make sure I wasn't leaving unexplained gaps, but if the job wasn't relevant to the one I was seeking, that entry would be very short. At the bottom I put a short paragraph of other things I'd done in the past that might help. I would put down my early roadie experience if I was applying for a field service job. It was a long time ago, but it's high-pressure field service. No need to mention food service jobs or working at the local.
Keeping in mind that experience comes from a lack of wisdom only for the people with enough ... I'm not sure what word so let's say intelligence, though that might be wrong, to learn something from it. Also, wisdom only grows when people learn from experience more than once.
People who have a lot of experience and learned from it are often the most wise and capable, but I've also known old people who decided that experience is boring and to stop bothering with that years ago. In the tech space, that meant people who would refuse to consider running Linux servers because, based on their experience from the late 1990s, that's not really a thing anyone of our size would bother with. In that place, the young people were better than the old ones just in the sense that the young people bothered to consider options. I've also met young workers who decided to get started on that plan early. Praising experience is great, but don't automatically assume that age or tenure at a job means there is experience.
Reminds of a saying: "Good judgement comes from experience, experience comes from exercising bad judgement." Getting burned by some undocumented or poorly documented "feature" leaves a lasting impression on one's mind - and someone fresh out of school is unlikely to have come across these "features".
"Slavery' was a thing for thousands of years of human society, and still is a thing today. "
Human slavery, and then we found a way to make mechanical machines be our slaves, and then computers/automation and maybe now, AI. People are still made slaves, but not as openly and to the same extent. We're are trying to go from carbon being our bitch to Silicon/Aluminum. The drive is on.
It's not only wages - sure I may have experience that makes me several orders of magnitude more effective in my work than a new graduate, but I also have decades of learning that I have rights, and that there are things my employer cannot and should not demand of me, and things I don't have to do if they don't pay me extra for them. That is one weird trick employers hate.
In industries were everything is completely and properly documented, there is no reason why a younger employee could not match, or exceed, the productivity of a senior employee.
At least that's the theory. In over 40 years of contracting and working at Fortune 500 companies, I never saw it happen.
I have never worked at a company where everything was documented either completely or properly. Even companies which had exceptionally good documentation (and they do exist) were lucky if the documentation covered 80% of their processes. And if they did, then younger employees still had to absorb literally thousands of pages of process in addition to technical knowledge.
In companies without exceptional documentation, which was the norm, knowledge was usually gained only through experience. That only happened when the employee encountered a case that wasn't covered by the documentation, and discovered the process. And the more undocumented processes there were, the longer it would take to find all the cases. By the time they finally did learn them, they had become the senior employees themselves.
That's why it's a running joke in most corporations that management will say things like "as you all know", and all the employees laugh or roll their eyes.
I've described the process at many of the companies I worked at as being "lore based development", only to have management angrily tell me that was nonsense, their processes were fully documented. When I ask them to show me, this usually devolves into an hour of searching, usually terminating in "that's funny, I was sure it was in the wiki", "wait, that's not right, that changed four years ago", or it will just say something like "ensure DB is set up properly with correct permissions" with no explanation of what proper or correct means, or how to do it.
The problem many companies have is that senior employees don't know how much they know, and management assumes that knowledge is easily reproducible. It's not.
"....were everything is completely and properly documented, there is no reason why a younger employee could not match, or exceed, the productivity of a senior employee."
I don't think that can be entirely right. A totally new and totally inexperienced employee is never going to have the productivity potential of an experienced one, but with access to the complete documentation , an inexperienced employee can very probably become as productive as an experienced one much more quickly, and can then probably overtake the experienced employee due to a younger, more active brain, not already stuck in a rut, and having a new, fresh approach to the tasks in hand.
However, I don't think the ability to exceed the productivity of a very experienced employee is guaranteed, and most younger employees are not likely to become highly productive until they have become the experienced employee.
Documentation is also massively helped by the older experienced employees being willing to take the time and trouble to help show the inexperienced how the job is done - it seems to me that there are a significant number of older experienced people who are unwilling to help the younger inexperienced ones (and before anyone starts; I am one of the oldies :)).
A totally new and totally inexperienced employee is never going to have the productivity potential of an experienced one
I said a younger employee, not a new and totally inexperienced one.
There's a huge difference between those. An engineer who has been in the company for three years is younger than a senior who's been there for thirty years, but they aren't totally inexperienced.
The only thing I'd have to change to write that exact post is "In over 35 years of writing bespoke software..." One of the first things I'll ask is for any relevant procedures. Only once has the result anything but a blank look. And that's with more than a couple of accountancies/bookeepers over the years. By the time scope/spec is finished, they have procedures :)
> "ensure DB is set up properly with correct permissions"
Hey! Have you been reading my HowTos?
Usefully documented, not so much.
I once was handed a project where I was told there a build process document. I thought the document was corrupt, since it was only 113 bytes.
It turned out that "Buildprc.doc" was actually a text file, not a Microsoft Word document. This was MS DOS days, before the .DOC extension was associated with Word. But still, 113 bytes?
The documentation, in its' entirety was:
Make sure network drives are mapped correctly
Make sure the J: drive has enough space before starting the build
No one had any idea what "correct" drive letters were , or what was "enough space".
Unmentioned was the fact that the code was a PVCS archive, let alone what it was called, where it could be found, what compiler, libraries, operating system, etc. was needed to build it.
"....were everything is completely and properly documented, there is no reason why a younger employee could not match, or exceed, the productivity of a senior employee."
Except of course that the younger employee would have to read the documentation and fully commit it to memory first whereas the senior employee would have that knowledge at his/her fingertips making them more productive from the git-go. Also the older employee would be more familiar with normal company processes and so better understand why things are done in a particular way.
You simply can't beat experience with little to no experience when it comes to productivity assuming equal commitment to the job which seems to be self evident.
One of my colleagues in a former employment had the job of finding out the following:
1 What are we providing to the $customer?
2 What are we billing the $customer for?
2 What are we contracted to provide to the $customer and at what prices?
He was often 'hindered' in this due to frequently having clients where we had 'lost' the written contract*, were providing services on the basis that 'someone from their team phoned us up one day and asked us to provide an extra', and even finding out that we were charging them for services we had terminated years ago or were not billing them for and never had.
He saved the company millions. But very rarely did any of the two above agree, and he never found one where all three were in agreement.
* When I left I had to send them a copy of my written contract specifically the clause concerning my notice period so I paid the correct amount of tax on my retirement lump sum because they had lost their copy and had not bothered to take an electronic backup.
"He was often 'hindered' in this due to frequently having clients where we had 'lost' the written contract*,"
That's too much for words. No contract, no way to get the client to pay. If that client runs up a fancy bill and insists that it was included in their contract, how could you show them that's not the case or present it in court to get an order for payment?
With my photography, I have three levels. Low price jobs are "on a handshake". I'd never take them to court as it would be more than the billing in time/money. Medium jobs are on my standard contract that I paid a blood sucking lawyer to polish for me. There isn't much wiggle room for negotiation or it's more money in blood sucking lawyers to do properly. High paying jobs are negotiable and I pay my attorney to make it all nice and tidy. Almost nothing in product development or consulting is done on a handshake. There will be some sort of contract with everything laid out. Anything on a contract is on paper and in my files going back way too far but I'm too lazy to spend a full day at the shredder. Maybe when I build up the garden in spring and will bulk up soil with the shreds. I may also look into making starter pots from it.
Maybe my experience is different than most. At a startup we hired a pretty good tech writer. She'd interview the developers and actually ran the software. She was paid well. This was chip P&R software that really needed good documentation. But as I stated, generally I found it was the AE's that read it, and would answer the customer Q's. Customer did not usually read the manual.
I have been called upon to write documentation for internal software for a few years now.
It's not easy. You need to write the docs for the people who have never worked with the software, not for the people who've been working with it for years (or more) and who just need a reminder. I was specifically told that my documentation would be read by new hires. That practically added double the number of pages to the purely technical side because I had to make sure that the new hire understood the interface (and its quirks) that he was working with.
As a result, I have the greatest respect for people who do that job for a living, without ever actually working with the product.
It's not easy, especially when you can't help but ask yourself : is anybody really reading this ?
It's not easy. You need to write the docs for the people who have never worked with the software, not for the people who've been working with it for years (or more) and who just need a reminder.
This is key. Senior employees often don't know how much they know. Many equate institutional knowledge with intuitive. That's where the dreaded "as you all know" comes from . They know, so they assume everyone else does, as well.
I routinely found something incomprehensible, and spent days investigating it and/or reverse engineering it. When I was done, I would then document this lore either in a wiki, or whatever process document archive the company had. If there was no wiki or archive, I'd email it to the team.
And every time, I would (a) be told by my team lead/group lead/manager that I had wasted time we didn't have on needless documentation because "everyone already knows that", and (b) numerous other engineers would thank me for documenting it saying things like "I could never figure that out" or "oh that's what that does".
And very often I would get (c) engineers from other departments asking followup questions. When I asked how they had found out about my wiki/document/email that hadn't been sent to their department, they would say that they had been asking my team lead/group lead/manager about it for months, and he finally replied to them by pointing to my writeup.
Yes, the same my team lead/group lead/manager who said I had wasted time on needless documentation was getting continuous requests on how the "obvious" function worked would refer people to the "needless" documentation they said I shouldn't have bothered writing because it wasn't needed. The irony was lost on them.
That last fact was mentioned in several third party audits, by the way. One summarized the audit by saying "it's a good thing you hire external contractors, since it seems they are the only ones who document anything; your internal people certainly don't"
I feel your pain re:
"And every time, I would (a) be told by my team lead/group lead/manager that I had wasted time we didn't have on needless documentation because "everyone already knows that"
I'm keen to document stuff on the wiki (maybe because I am older and aware how important it is that people can easily find useful info as it helps them be more productive) and never assume anything is "obvious".
The senior person* invariably removes a lot of (IMHO useful info) from my documentation.
Ironically, plenty of team members have told me that they look at wiki history & if they see the lead is most recent edit & I was previous editor (so the most recent edit will be a pared to the bone page), they know to go back in the history and look at my version as it will be the useful version with plenty of handy contextual information that does not assume reader has knowledge of everything.
* much younger than me (I'm autistic and so actively avoid promotions / seniority positions, so used to younger "leads" with enthusiasm but sweet FA experience - just leave me alone and let me get on with the difficult coding problems that others gave up on & producing proper documentation of what I have done thanks)
The senior person* invariably removes a lot of (IMHO useful info) from my documentation.
I was working for team A, and told by management I would be transferred to team B on July 1st, start of 3Q. That shouldn't be a problem, as our project should be wrapped up by April, or May at the latest. All we needed was the architect components in the DLL he'd promised by early April.
It became obvious the architect wasn't going to make his dates, so I wrote the functions I expected him to write (the API was still undefined) and hardcoded values into the code so that our downstream users could test our component. We couldn't go into production with it, of course, but we wouldn't hold up the project.
As the end of June rolled around, and there was still no DLL, I wrote up everything I could in the code for my successor, with lots of comments like "when the DLL is available, replace the Blipvert() function call below with whatever the framework requires; they should be the same parameters, although unit may be different".
In mid August, the team A manager demanded a meeting with me, saying the project was a mess because (a) I had hardcoded everything rather than using the proper DLLs, and (b) hadn't documented anything.
So, there was a meeting with me, manager A, manager B, and the director that we all reported to.
The manager may not have cared that the DLL wasn't ready before I left the department, but the director did. He pointedly asked manager A what he expected me to have done, and to "get your stuff together" with respect to schedules, although with a more pointed, but not el Reg friendly term.
As for my lack of documention, we went into the source code repository and checked my last commits. Sure enough, there was a ton of comments and explanatory text, even some process and state diagrams in block text. So what was the complaint?
Well, after my last commit, there a few others, by the architect. He'd checked out my sources, deleted the comments, and checked them back in. We compiled both my last version and his most recent one. They were identical. So why the hell were the comments deleted?
Because "comments can get out of date and confuse people", apparently. And "if you write the code properly and use good variable names, you don't need comments".
So my explanations of the architect's use of bidirectional stateful adaptable unary functors was completely unnecessary, as they were simple to understand.
After discovering that the architect had been scrubbing the code library clean of comments, team A developers starting checking the history, and discovered a ton of documentation.
I was not transferred back, and my team B manager commented that he "thought you [sic] were kidding" about the other team.
I checked in on that company years later. Manager A and the architect are still there, with completely different teams, and apparently, the company is still having documentation problems. I'm not surprised.
"I have been called upon to write documentation for internal software for a few years now."
I always reckoned that user documentation for internal software should be written by the user department with help from the developers as needed. The reason being that using it is part of the department's operations, not something separate. What they should be writing is documentation of how to do the job and that should include what to do on the computer as it occurs in the job.
"It's not easy. You need to write the docs for the people who have never worked with the software,"
When I was building documentation for the rockets we were building, I did it three ways based on likely scenarios that might come up. It was also helpful for me and turned out to be worth an even million bucks one time. It took time to create the docs, but I felt it saved far more time and I also used the overall concepts as templates for our test stands. It was a PIA to try and trace wiring based on classic documentation. If I could have something that listed a connector with a pin by pin description, I could do a continuity check between the LOX tank pressure sender and the multi-pin connector I'd just disconnected to verify that the section of wiring wasn't the issue. Another page had connections sorted by function. The internal wiring docs listed wire colors and both ends of where the wire went sorted two ways. Given more time and I would have automated some of the docs so the master doc would flow the data to alternate ways of looking at it. I got chewed out for spending time on documentation but I ignored that.
The engagement of a technical writer/author/editor/ghostwriter is also something I’ve done. It makes it very clean to everyone that preparing “user” documentation is their full-time job, so they can’t be reprioritised onto other “more important work”…
Having this person who isn’t a (software) domain expert, meant they asked the developers questions and got them to explain and so better understand the intended purpose and usage of their code. Whilst it wasn’t always easy, it ensured the final documentation was a consistent and well organised corpus.
From the comments here, it seems this is atypical in IT.
Which DB is it? Which vendor? Which document?
I've seen new hires handed procedures that told them to "initialize the DB in the test fixture", and they've stumbled around like blind men with white canes trying to find would what test figure to use, where it was, what database they were supposed to initalize, how they were supposed to do that, what the account name and passwords were, etc., because absolutely nothing was written down, and "everyone knows".
One friend, on his first day, was handed an incomprehensible four paragraph test procedure he was supposed to run. It included phrases like "start the machines in the correct order". He spent a week learning, and then documenting what needed to be done. It ended up being 15 pages of detailed instructions.
The manager rejected it as "too much detail" with the kicker line being "if we document this test procedure with that much detail, people will expect us to document all procedures with that much detail".
YES! YOU DO!
I should mention that this was in a company when, where a tester left, they threw out all of his test results because they were unreproducible. It was fully accepted that "the only people who can run the test procedures are the people who wrote the test procedures". That's an actual quote from the manager of the testing department.
A department (in a big german semiconductor automotive company wete changing ate vendor. I wrote up how to develop a program on the new system.
There was a lot of wiki pages, but they only covered parts of the process. I combined them all with the missing details i had found.
As i was leaving (gladly) i gave my boss the docs and asked him to read it and i'd expand on the unclear bits.
I never heard any more. They also had to go from windows to RHEL linux.
Best of luck, because they are going to need it.
Sort of correct !!!
The problem is as follows:
1. New young employees think they know everything and can out-think the oldies as a matter of course ... because Oldies are OLD.
2. Because of 1. there is no incentive to read anything that has been produced by the Oldies because it is OLD, and of course 'Out of Date'.
3. The Oldies stopped documenting everything as it takes too much time, they are 'busy', and they 'know it anyway'.
4. New young employees only learn that the premise of their thinking is wrong with age/experience ... as they get closer to being an OLDIE.
5. The New young employees evolve into 'proto-oldies' and have the same foreboding about the next influx of New Young Employees.
6. goto 1.
:)
The first casualty of (usually imposed from above by the clueless) ludicrous deadlines is always documentation.
Even when there may be a small window to deal with some "technical debt", its generally code refactor, rather than documenting the undocumented.
Not helped by policies such as "no comments in code as they get out of date" ... yes, there is that risk (not of code review includes validating comment accuracy), but at least it gives a noob a lot more clue than zero comments!
"In industries were everything is completely and properly documented"
You can't document everything. It's impossible unless the tasks are repetitive and simple. No amount of documentation will include all the techniques used to develop code, for example. No documentation records "well we had this problem x number of years ago and carried out action y to solve it". Experience is the learning of ways of working and applying them to new processes and problems.
"And the more undocumented processes there were, the longer it would take to find all the cases."
I would think that if there are too many cases, there's something wrong. I have to whack the washing machine in a certain spot as the mechanical timer has an area it doesn't want to move past on its own at the end of the rinse cycle. I don't fix it as I'd likely just cause more issues and I'm the only one that uses it or I'd have to teach everybody in the household. For a process at a company, it should be repaired so it works as expected and there no need for a work around. I have to agree that S happens and there needs to be way to keep going even if it means a kludge for the time being. That takes understanding the process at a deep level, which is going to take time. Maybe that can be documented, but maybe not. The solution is to not sack the people that know how everything works to save a few groats. Management is parasitic and they should understand that. Without people that do the actual work, there is no business. Managers can be bought on the open market and plugged in with far less fuss.
"Treat age as a strategic variable in the same way firms now treat gender, skills, or succession risk."
Gender? Really? Still flogging the tired old trope that women are somehow less valuable, less reliable, less productive, moody, etc. Ad nauseam. Or did I miss the point of gender being a "strategic variable"?
But you are forgetting that 'Age' means 'Higher Salaries' and that is what tends to drive out the Oldies !!!
The invalid thought that 'youth, vigour and excitement' will compensate for 'real knowledge & skills' is used to calm the 'disquiet' in the back of the mind that something is being 'missed' !!!???
:)
"The driven out oldies then return as freelancers being paid properly for knowing things the inexperienced younglings don't."
Don't we just.....
Not just properly paid. There are bonuses for the desperation to get something fixed before the big boss comes to visit.
On an hourly basis, I charge something like 5x what I was paid previously, plus expenses and a minimum.
It's always a good test to see if offered pay goes up if you are "currently busy with another project" and how soon do they need this questions.
Yes, you have missed the point. The point is that having a mixed team (mixed across all variables) is actively better than have a homogenous team. A team that comes at a problem from a variety of different backgrounds is more likely to find a good solution than a team which is entirely homogenous.
But your selection of the team members should be based on skills NOT age.
Adding young members to a team does not add anything useful IF you ignore skills.
They may become useful in time BUT usually the addition of young limited skilled members to teams simply unbalances the team for a while.
Take on new members, of course, but don't pretend it is for some reason to do with finding a 'better' solution !!!
It is only for the sake of saving money !!!
All 'pure' managers 'know' ... All techies are interchangable ... of course :) ... skills come with the 'Job Title' not experience !!!???
:)
"peak performance occurs between the ages of 55-60"
Silly then, for my then employer to let me go at 52. Mind you I had started to show failings. It was one of those events where large numbers of staff are gathered together to be motivated by having their intelligence insulted but taken to new extremes. Even the celebrity TV presenter brought it to MC it had the grace to look embarrassed. I failed to suspend disbelief and to conceal disgust.
Great outcome. I went on to exercise my peak powers very rewardingly in freelance.
It may well be the case that older staff are more experienced, but we often come with added health conditions (aka 'co-morbidities'). My father was a teacher and later the headmaster of a state comprehensive school.
He retired at 60* on the basis that the colleagues he knew who had worked to the age of 65 died around the age of 70. He died aged 96 and 6 months, having collected his index linked teacher's pension for a full 36 years.**
It is all very well saying that heterogeneous teams are best, but what really makes the difference is competent management caring for their staff. I'd like to see that in a 'Management Consultancy' report.
* I got out at 58, and am enjoying the prospect of a long retirement. The amount I'd have to be paid to go back to the hell-hole of paid employment would be vastly more than even my genius*** would be worth.
** I am also looking to spend 'Dad's' money on having a bit of fun. He was quite the miser :-)
*** PhD in pure maths
I worked for a small family run electronic engineering company, and we agreed I'd retire when I was no longer enjoying it - I retired at 70. I still drop in on the office for a chat sometimes, and also get a bottle of my fave tipple from them every Christmas.
I'm quite chuffed that the bench I used to work at (when not on the road) is still set up the same way - seems the guy who works there now likes it the way it is.
... you had both.
Always two there are, the senior and the junior.
I learned the ropes from greybeards who could transmit an entire FTP file upload by rubbing their cardigans and and using the static to touch the token ring cable in the right timing and sequence. What am I saying? "FTP?" Ha! We used kermit and we liked it! Over a phone line. Or X.25, if you knew the right people.
Then I became the greybeard (sans facial hair because I'd look like Catweasel not Gandalf, like that guy -> without the Windows), and passed it on to enthusiastic and excited juniors in my turn.
The corporate masters with their MBAs destroyed that and are desperately hoping that "junior + LLM" can achieve the same thing.
And they will be bitterly disappointed.
Or, and this is quite possible, they will readjust their expectations to find it quite acceptable. Which, in turn, will end up proving that Idiocracy was, in fact, a documentary.
I think I can guess which path we'll end up with . . .
Having been the oldie around younger teams, the phenomenon of re-inventing the wheel was painful to witness. Where I could, I mentored, but it was a drop in the ocean.
Certainly in the UK, around the late 70's and accelerating through the 80's it appeared policy to expunge tranches, then swathes of employees in their 50's then late 40's from workforces.
The result was mass re-inventions of the wheel, always buckled.
Why? It seemed to me they (and latterly me, and soon to be you) were perceived as a threat to authority and expensive to retain compared to a spotty youth. When the lineage between shop floor and management was severed, even to the lowest rungs, then a grease monkey with a contrary opinion could not be brooked by an MBA in a suit.
An MBA who would explain that apprenticeships were expensive and it would save a shilling to poach employees who had been trained on someone else's shilling. No apprentices = no need for those expensive opinionated gaffers either. I have seen no evidence that this has slowed, or reversed.
An expert is merely someone who has made every conceivable mistake in a very narrow field. Having one around is extraordinarily valuable, if a threat.
Contrarily, for the few remaining 'experts' there is a fine judgement in allowing others to make a known error and come to their own realisation, or correct them, or correct and explain why it is an error and demonstrate - and just being tired with the whole shitshow, wash your hands damn the brave new world and let them get around to the wheel eventually, however misshapen, while you screw Finance with a trick the dinosaurs laughed at, but they couldn't follow with radar... idiots.
Much like child rearing really, if it takes a village, but there isn't one, whither the child? As others mentioned , that's institutional knowledge lost.
Those who genuinely wish to learn will embrace prior knowledge and experience - if it's there, and bemoan the lack where it is not (sadly a minority) I certainly hung on the word of every gaffer I could coax into imparting knowledge in exchange for a cold beer, even if I did have to filter for 'war stories' and 'windups'
Others are just content to bang the rocks together and hope something vaguely wheel-like fall off, hence the popularity of AI "Hey ChatGPT, how did the elders stop those sort of circle things from falling off"
around·the carousel three and bit times so you ought you to have seen it all before… thrice.
Even if you were a slow learner you have got it by the third time and if you only had a five minute attention span you would have been projected into management well before the second rotation.
In my advanced years I often feel like Douglas Adams' plummeting bowl of petunias (accompanied by gormless doomed cetaceans.)
Yes, but why exactly do you think that? I'd speculate that we would know a lot more about the nature of the universe than we do now if you would just explain that thought a bit more ... ! ;)
"es, you;d think it would have been documented for future generations wouldn't you ?"
Things that work get documented. Things that don't work get remembered by people that have been at the company for some time, until none of them are at the company any longer. Lather, Rinse, Repeat.
The LLM thing seems to be that experienced developers can use it because they understand the code. So companies stop hiring junior devs. Where do experienced developers come from? Is the future that in 20 years, nobody knows how anything works and has no idea how to fix it?
I remember in the late 90s/early 2000s people going on about the "demographic timebomb". Because some folks spotted that people who were in their 60s in 2005 would be in their 80s in 2025. As a result, the welfare budget (mostly pensions) and the NHS would be taking a beating. But no government would ever get elected on the basis of admitting that the choices were tax rises, pension cuts or some sort of Carrousel system (Logan's Run).
Expecting a society that only cares about the next quarterly results, the next election, tomorrow's stock price to do anything about a problem like global warming seems naive. Also, have a nice day.
I was 63 when I was 'let go', I'm now 64, I've been in IT 30+ years, the last two in IT logistics getting replacement parts and engineers to site.
Yes I have experience but it goes out the window when your sat in front of the 'hiring team' who are around the same age as some of my grand kids.
This report is utter puerile rubbish with no grounding in the realities of life, just saying :-)
"Study confirms experience beats youthful enthusiasm. Research shows productivity and judgment peak decades after graduation"
^ That's really good to hear but these are unfortunately the people who these days are most likely to be made redundant. Ultimately, that won't benefit the company as they will lose that great experience and new younger hires will not be able to benefit from their wisdom and experience.
I was made redundant after more than 11 years, because after a strategic review, my skills didn't meet the skills matrix requirements, I was given a right to reply, but as I pointed out, how after 11 years of being there, did I all of a sudden not meet the skills requirements - I was also not given a copy of the skills matrix - and when did they ever talk to me about this and offer me training.
Anyway after a week, which allowed me to re-assign tickets and do a proper handover, update doco etc. I was gone.
7 weeks later, I received an SMS that my offsider had tendered his resignation, this same guy my bosses even admitted, just sat next to the Exec. Assistants and legal ladies all day, on YouTube and Reddit all whilst I was doing 80% of the workload, doing my stuff and fixing his stuff ups.
I ended up getting a job with a much better employer and am on $35,000 AU more. So in my case it was for the best.