In that 40 years, you will have seen all sorts of things come to the fore and then fade back into the background as the next "big" thing comes along. What most have not seen is that these are tools that we can use to solve the problem-space problems placed before us. The point about abstraction and choosing the right abstraction for the problem at hand requires each of us to be able to communicate clearly with the problem domain subject matter experts and understand what they need from us.
Understanding what kinds of abstractions are available to us and how to apply is important. There is a proviso however, and this is where even though two problems may seem to be similar and could be usefully use the same abstraction, one must understand the problem space ramifications of those abstractions as the divergences can often come back and bite you.
Over the decades, many tools have been developed and each of them has some use in our toolbox, whether it be top-down design, bottom-up design, refactoring, objects, values, functional programming, assembly programming, static typing, dynamic typing, etc., etc., etc.
They do not have universal application, unless of course, your favourite is a hammer and everything is a nail. These tools allow us to solve different kinds of problems in a less laborious way.
If anything, the last forty years has shown me that, as a whole, each generation of programmers is unable to learn from the previous generations. We get so caught up in our various wars over which languages or techniques are the bee's knees that we often forget that we are supposed to become craftsmen and craftswomen, able to solve the problems placed before us using whatever tools are available.
Each of us will have favourite tools, but we had all better be prepared to be competent and pick up whatever tools we are given and solve the problems before us.
Understanding what kinds of abstractions are available to us and how to apply is important. There is a proviso however, and this is where even though two problems may seem to be similar and could be usefully use the same abstraction, one must understand the problem space ramifications of those abstractions as the divergences can often come back and bite you.
Over the decades, many tools have been developed and each of them has some use in our toolbox, whether it be top-down design, bottom-up design, refactoring, objects, values, functional programming, assembly programming, static typing, dynamic typing, etc., etc., etc.
They do not have universal application, unless of course, your favourite is a hammer and everything is a nail. These tools allow us to solve different kinds of problems in a less laborious way.
If anything, the last forty years has shown me that, as a whole, each generation of programmers is unable to learn from the previous generations. We get so caught up in our various wars over which languages or techniques are the bee's knees that we often forget that we are supposed to become craftsmen and craftswomen, able to solve the problems placed before us using whatever tools are available.
Each of us will have favourite tools, but we had all better be prepared to be competent and pick up whatever tools we are given and solve the problems before us.