Eat-Through-Rectum-Myth
Maybe this is actually about "programmers" as opposed to "software engineers". I consider myself a software engineer and this means I aim for a proper piece of software as opposed to "something which barely works but gives management immediate gratification".
What does proper software mean ? Here's a non-exhaustive list
+ has proper structure from a computer-science and from the domain point of view
+ intent of programmer can be inferred from source and comments with reasonable effort (e.g. use FUCKING MEANINGFUL variable names among many other things)
+ uses at least moderately efficient data structures and algorithms from the vast body of known algorithms (e.g. hashtables instead of O(n^2) loops)
+ tries to be as human-readable as possible (e.g. nicely formatted text files instead of binary abominations)
+ comes with a vast body of domain-knowledge documents checked into source control along with the source code, documentation, technical design, help files and so on
+ code is self-checking its invariants and premises quite frequently, will bomb if something wrong
+ code will bomb as soon as something fishy is being detected
+ code WILL NEVER "try to continue despite some cancer detected"
+ software engineer has made a large number of smart "high-level" decisions which are reflected in the structure of the system
+ code will have its own library system to facilitate re-use whenever possible. This will reduce lines of code and allow engineers to spend more time per line of code and in the end improve quality.
+ software will not use stupid forms of genericity (now, here comes the art, what is "stupid" ?)
+ will have a useful error reporting system/conventions
+ uses proper parser techniques to read data structures from files or the network
Now, how do you acquire the skills to build (it is much more than the process of "writing" or "programming") proper software ? It definitely does NOT come from the latest buzzword set of (GWT/JS/Ajax etc etc). It comes from experience, from lots of failed or semi-failed attempts. It comes from long hours of reading technical reports of HP labs, of the DEC technical journal and similar publications. Of course it is all based on a proper education in computer science and I definitely do NOT think you can replace those basics by "experience". You need both: proper education and many, many years in software engineering practice.
Let me shout this at you:
STARTING WITH AGE 40,YOUR CODE WILL START TO NOT SUCK ENTIRELY.
So, the first 15 years will be invested into your education and working off your silly ideas of being the center of the universe and being something extremely special and your little knowledge of some arcane M$ technology being something extremely special.
So, the whole notion of "old programmers...obsolete" is just fucking hilarious. It might resonate with the latest dumb idea of "spotting management talent early and developing it", but it is like eating food with you ass. Very inefficient. Start eating with your mouth and start hiring experienced engineers. Both is much more efficient that doing it in reverse.