Pattern Overuse
Applying a design pattern where the problem it solves does not exist, adding indirection and vocabulary without benefit.
Patterns are solutions to recurring problems, and a solution applied without the problem is pure cost: more files, more indirection, and a reader who must understand the pattern before understanding the code.
Recognisable symptoms: a factory that constructs exactly one type; a strategy interface with a single implementation; an abstract base class introduced "in case we need another"; an observer where a direct call would do; and a repository that exposes the ORM unchanged.
The underlying error is speculative generality — building for a second case that does not exist. An abstraction derived from one example encodes that example's accidents, and when the second case arrives it usually does not fit, so the abstraction is either bent or replaced. Duplication is cheaper than the wrong abstraction, and it is reversible in a way the wrong abstraction is not.
The useful discipline is to apply a pattern when the problem has actually appeared — the third similar case, the real second implementation, the genuine need to vary behaviour at runtime.
Patterns retain a second value that survives this caution: shared vocabulary. Saying "this is a circuit breaker" or "we used a strangler fig here" conveys a great deal in three words, and that is worth learning them for even when they are not being applied.