Anti-Patterns

"An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive."

1 Examples from non-CS

Bicycle shed: Giving disproportionate weight to trivial issues
Escalation of commitment: Failing to revoke a decision when it proves wrong
Peter Principle: Continually promoting otherwise well-performing employees up to their level of incompetence, where they remain indefinitely
Stovepipe or Silos: An organizational structure of isolated or semi-isolated teams, in which too many communications take place up and down the hierarchy, rather than directly with other teams across the organization
Ninety-ninety rule: Tendency to underestimate the amount of time to complete a project when it is "nearly done"

Abstraction inversion: Not exposing implemented functionality required by callers of a function/method/constructor, so that the calling code awkwardly re-implements the same functionality in terms of those calls
Big ball of mud: A system with no recognizable structure.
Input kludge: Failing to specify and implement the handling of possibly invalid input
Call super: Requiring subclasses to call a superclass's overridden method
God object: Concentrating too many functions in a single part of the design (class)
Sequential coupling: A class that requires its methods to be called in a particular order. (?)
Poltergeists: Objects whose sole purpose is to pass information to another object
Boat anchor: Retaining a part of a system that no longer has any use
Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. Also can refer to erasing the Stack trace during exception handling, which can hamper debugging.
Lasagna code: Programs whose structure consists of too many layers.

https://en.wikipedia.org/wiki/Anti-pattern A few selected items are given above. Software Engineering section: Required Reading.
https://sourcemaking.com/ has most of the above materials presented well.