What a pattern is for

A design pattern is a named solution to a problem that recurs. The value is mostly that it is named: saying "this is a factory" communicates in three words what would otherwise take a paragraph, and that shared vocabulary is what patterns actually buy you.

They are descriptions, not prescriptions. Patterns were catalogued by observing what experienced developers kept doing, not invented as rules to follow. Somebody who reads the catalogue and then looks for places to apply patterns has the relationship backwards, and the result is code with more structure than the problem required.

The right sequence. Write the simple thing. When it becomes awkward in a specific way, recognise that the awkwardness has a name, and apply the pattern that addresses it.

The common failure. A junior developer discovers patterns and produces a system with six abstractions where two functions would have done. This is worse than the naive version, because now the reader has to understand both the problem and the machinery built around it.

The second failure, less discussed, is not recognising a pattern you are reinventing badly. A great deal of confusing code is a half implemented observer or strategy that nobody named.

Know them well enough to recognise them in other people's code and in library documentation, which is where you will meet them most.

And accept that some are language specific. Several classic patterns exist to work around limitations that modern languages do not have, and using them anyway adds ceremony for nothing.