Not only does no-one at all talk about them, most of the design patterns themselves were harmful and are now completely unnecessary due to functional language features being available in modern languages.
Design patterns are like TDD, no-one wants to come out and admit it, but they were really, really bad outside of theory.
InitiatorFactoryFactory I do not mourne thee!
I really enjoyed this talk from Deconstruct 2017: "Patterns Failed. Why? Should We Care?" I recommend giving it a watch: https://www.deconstructconf.com/2017/brian-marick-patterns-f...
In modern C# you won't see hide nor hair of Factories, Singletons, etc.
Expect modern Java to be the same in a few years.
That team can't commit to anything and yet make regular sweeping changes to the framework depending on whatever the current flavour of the month is. This month it's DI, DI, DI.
They've been incredibly inconsistent since ScottGu left.
But getting lost in a sea of abstraction is easy, it makes you a better architecture astronaut than the one that's sitting on a Tesla now on the orbit listening Bowie's music. Looks good, makes you feel an expert, but really it's almost as bad as selling snake oil.
We programmers, as a whole, should have a code of ethic conduct and a better moral ethos.
Some particular patterns have fallen out of favor, like the "Singleton" which is problematic since it is hard to unit test. Instead dependency injection is preferred these days, although DI has its own issues. Some patterns have become so entrenched that some languages have added built-in support for them, which means, I guess, they are not really "patterns" anymore but "idioms".
Other patterns like say the "adapter" or "strategy" patterns are ubiquitous in OO and will be forever, whether you call it a pattern or not.
I heard of shops that were forbidding code that couldn't be shoehorned into one of the patterns already enshrined within the Gang-of-Four book (even though the book says repeatedly that it is not an exhaustive collection of patterns).
So DPs are bad because, on average, they tend to be an indicator of bad engineering practices, such as cargo-culting and political games. They can be used for good, but if you are considering a position in a pattern-heavy shop it's probably worthwhile doing research into what their engineering org is like.
I don't think being aware of design patterns is a bad idea. In the end, they are just recurring solutions for architectural issues that many developers independently invented to solve them. They just get a bad rep because people applied them even if it wasn't necessary.
However, just like Asdfbla said: People started to use it as a kind of manual and applied the patterns no matter the problem. Again, the problem is more the people than the idea...
The problem is that people all too often see the passing tests and think, "Great, I'm done!". They don't take the time to evaluate whether they have thought of all cases.
It's better to have some test cases, rather than no test cases. Even if only the golden path is tested, that's still better than nothing.
I'm merely trying to point out a weakness in the practice of "test driven development", where you write tests before you implement the functionality.
Since you already have tests while you work, it's really easy to just treat them as a checklist, and once all tests pass it feels like you are done.
But in reality, once the feature is done, that's when the hard QA work starts. You need to review the code, make sure you considered all error conditions, check if your assumptions hold throughout the execution of the program, ensure that your code is resilient to unexpected user input, etc.
TDD might be a valuable part of a development/QA workflow, but just introducing TDD on its own is not going to make your product any better.