I think we've learned that there's a lot more to developing software than "make XYZ work": can we onboard new devs without driving them mad (readable, logically structured, documented)? is it testable? do we have up to date dependencies?
I think we've learned that there's a lot more to developing software than "make XYZ work": can we onboard new devs without driving them mad (readable, logically structured, documented)? is it testable? do we have up to date dependencies?
I am the same type of person. Solving a problem and creating a great product can be very rewarding and is my primary motivation.
There have been times in my career where I have been thinking more about how I could sneak in a new technology in a project. In those cases it was a sign that the things I worked on were not motivating enough, or a bad work environment. I'm more aware of how these things affect me now that I have the benefit of hindsight.
Dark matter code can be clean or spaghetti. New shiny code can be clean or spaghetti. Implying that there is a causal relation between dark matter and spaghetti is disingenuous I would say.
Of course, code written for the new shiny framework from two weeks ago is at most two weeks old and thus hasn't had time to accumulate cruft. But that doesn't say anything about the quality of the developers.
I would say if code is really old and still receives new features, the developers must have been doing something right! Take (GNU) Emacs as an example, it's from 1985 or so I think, and now speaks LSP.