- try to write code that can be easily unit tested
- composition over inheritance
- immutable over mutable + avoid side effects
- avoid recursion unless your data is recursive
etc. etc.
To paraphrase Brooks, no pattern or methodology is gonna make development "more productive, more reliable or simpler". All patterns and methodologies require a skilled practitioner, but someone skilled enough can even eschew them and still make good software, so in the end they don't really matter.
The point of patterns/methodologies is purely to facilitate communication between experts, not to guide.
In the end, good software is not about following recipes, especially complex recipes. It's a craft.
As for where do we go, what we need is the foundation for personally re-discovering and internalising those same methodologies and patterns, rather than blindly following them. Sweezyjeezy already enumerated some ideas above, and I have done the same in the past: https://news.ycombinator.com/item?id=27987498
The more general purpose it purports to be the vaguer and more misapplied it will end up being.
DDD could be a lot better as a movement if it tried to limit its scope a bit.
Until then, we have to stick to patterns that are very simple, easy to teach and have wide pits of success. We also have to lean heavily on systems that easy to replace and easy to refactor, and can be managed by the few very experienced devs. That's why platforms like Ruby on Rails did so well, even though they can be divisive.