At the same time young employees keeps repeating mistakes made already by programmers that were around in the 70's, 80's and 90's.
At some point in their careers, all programmers, after spending a month hunting down a heap corruption, or a race condition, or some other bug nasty like that, come to the realisation that they are spending more time fixing mistakes than writing code. At this moment, most, but not all programmers follow a very logical path of reasoning. They think to themselves, "well, if this code took me 1 week to write, then 4 to fix, that is five weeks, what if I spent 3 weeks writing it carefully, then it would be done right away and I wouldn't have to fix it, I could have been done two weeks earlier!".
From that moment on, this programmer becomes all but useless to their current and future employers.
"Why?" Seasoned veterans may ask. "It saves time in the long run! You are just focussing on the short term results, being distracted by smoke and mirrors and building upon pillars of sand!"
Well, that is occasionally the case, but not usually. What is more often the case is when something is implemented it is either not what we needed or not implemented how it should have been implemented. When something is more or less built, nomatter how badly it is built, it is so clear and obvious what we needed instead and how it should have been made. If you had done that useless feature badly in 1 week, it could have been thrown out and we could have moved on. Sure, your experience might have told you that this was a waste of time, great, could you have told everyone what we really need? Are you going to take the reigns and pull the project in the right direction, or are you just going to be content in doing nothing in preference to doing some useless task?
The thing is, sure, you might do the right thing, in the right way the first time and the twenty year old across the room probably will do the wrong thing, in the wrong way the first and maybe even the second time. However, are you so positive that you will be finished before that twenty year old has finished his third and correct solution? Are you sure that what you build will be better than what the twenty year old builds after two attempts? Is your stable and clean version so much more useful to your team than the twenty year old's buggy first attempt that they will be happy to go without even seeing it for another few weeks, when they could have continued using it as a prototype or placeholder for a less buggy version.
Anyway, a few general maxims to stay relevant as you get older: 1) bad code is not so hard to rewrite 2) useless code is even easier to delete 3) if you're stumped on a problem, just try something, if it's wrong, you'll find out very soon. 4) no amount of experience, no amount of guile, no amount of planning or foresight can compare to a little intuition, a flurry of activity and being willing to make mistakes.