I started programming when I was 7, I'm 45 next month :)
The one thing in the programming world that is almost 100% applicable to almost every article like this ( and many other topics ) is..... it depends.
I'm fortunate in that for most all my career I have spanned many technologies from embedded systems to the latest crazes on the web. Mostly what becomes redundant is language syntax and framework. If your programming career is largely centered around these then you become redundant pretty quick (or super valuable when critical systems are built with them then need maintenance forever ).
Frameworks come and go so if you spend a lot of time creating solutions that shuffle data from a DB to a screen then shuffle data back into a DB.... then a majority of your programming skills will become redundant relatively quickly. ( maybe a half life of 4 years? ). But often when you are doing this, the real skill is translating what people want into software solutions, which is a timeless skill that has to be built over a number of projects.
If you work in highly algorithmic areas, then not a lot of your skills become redundant. Though you may find libraries evolve that solve problems that you had to painfully do from scratch. However that deep knowledge is important.
Design, the more complex a system is to engineer (that isn't provided to you via a framework), the more likely you will have skills that won't go redundant. Design knowledge is semi timeless. My books on cgi programming circa the mid nineties are next to useless, but my GOF Design Patterns book is still full of knowledge that anyone should still know. OOSC by Betrand Meyer is still full of relevant good ideas. My books on functional programming from the 80s are great. The Actor model which has its history in the 70s is getting appreciated by the cool kids using elixir/erlang
Skills in debugging are often timeless, not sure there's any technique I'd not use anymore. ( though putting logic probes on all the data and address lines of a CPU to find that the CPU has a bug in it's interrupt handling is not often needed now )
spend a lot of time creating solutions that shuffle data from a DB to a screen then shuffle data back into a DB.... then a majority of your programming skills will become redundant relatively quickly
This is kind of astonishing, isn't it? When this kind of "CRUD" data bureaucracy has been going on for decades. There's no fully general solution yet? We're doomed to keep reinventing it regularly?
Debugging is really one of the core skills of programming that should be explicitly taught.
The tech industry has certain weird persistent prejudices. One of them is a prejudicial attitude to "CRUD" despite its importance and relative complexity compared to how it is perceived. Another is a fetish for unnecessary code optimization and scalability.
The obsession for newness is another one, obviously.
The power of software is that you can create specific solutions. There are plenty of fully general solutions out there but they're not tuned to exact needs of the user. For that you need programmers and programming.
Things have actually gotten a lot better but, as the technology improves, so do the demands of users. I do a lot of CRUD but it's all highly specialized. An hour of my time coding a very customized way of shuffling data from database to the UI will save hundreds of people hundreds of hours.
The one thing in the programming world that is almost 100% applicable to almost every article like this ( and many other topics ) is..... it depends.
I'm fortunate in that for most all my career I have spanned many technologies from embedded systems to the latest crazes on the web. Mostly what becomes redundant is language syntax and framework. If your programming career is largely centered around these then you become redundant pretty quick (or super valuable when critical systems are built with them then need maintenance forever ).
Frameworks come and go so if you spend a lot of time creating solutions that shuffle data from a DB to a screen then shuffle data back into a DB.... then a majority of your programming skills will become redundant relatively quickly. ( maybe a half life of 4 years? ). But often when you are doing this, the real skill is translating what people want into software solutions, which is a timeless skill that has to be built over a number of projects.
If you work in highly algorithmic areas, then not a lot of your skills become redundant. Though you may find libraries evolve that solve problems that you had to painfully do from scratch. However that deep knowledge is important.
Design, the more complex a system is to engineer (that isn't provided to you via a framework), the more likely you will have skills that won't go redundant. Design knowledge is semi timeless. My books on cgi programming circa the mid nineties are next to useless, but my GOF Design Patterns book is still full of knowledge that anyone should still know. OOSC by Betrand Meyer is still full of relevant good ideas. My books on functional programming from the 80s are great. The Actor model which has its history in the 70s is getting appreciated by the cool kids using elixir/erlang
Skills in debugging are often timeless, not sure there's any technique I'd not use anymore. ( though putting logic probes on all the data and address lines of a CPU to find that the CPU has a bug in it's interrupt handling is not often needed now )