Patterns, Anti-Patterns & Diagrams

Some design problems show up so often that proven solutions to them have earned names: design patterns. Their dark mirror — common-looking solutions that reliably cause trouble — are anti-patterns. And teams communicate both using simple diagrams.

You won't drill these here. The goal is to recognize what a pattern is (a shared vocabulary for a recurring solution), what an anti-pattern is (a recurring mistake to avoid), and that a quick sketch usually beats heavy formal notation.

Chess is the easy analogy. Experienced players recognize named openings — well-studied sequences of moves — and play them instantly instead of reinventing each game. Design patterns are named openings for recurring software problems.

Design Patterns

A design pattern is a named, reusable solution to a problem that comes up again and again. It's not code you copy and paste — it's a shape of a solution you adapt to your situation. The real value is the shared vocabulary: when one developer says "let's use an observer here", another instantly pictures the structure, without a long explanation. Patterns let teams discuss design in shorthand.

A Few to Recognize

You don't need to master them, just to have heard the names. A singleton ensures there's only ever one of something (one settings manager for the whole app). A factory is a piece whose job is to create other things, so the rest of the code doesn't have to know the messy details of how. An observer lets parts subscribe to an event and react when it happens. Hearing these names and knowing they're "named, common solutions" is plenty for now.

Anti-Patterns

An anti-pattern is the opposite: a solution that looks reasonable but reliably leads to trouble. Spaghetti code is tangled, jump-everywhere logic with no clear structure. A god object is one giant class that tries to do everything, so it touches the whole system and can't be changed safely. A big ball of mud is a whole system with no discernible architecture. Naming anti-patterns helps teams spot and call out a predictable mess before it sets.

Pattern (good shape)	Anti-pattern (mess to avoid)
Focused modules with clear jobs	God object — one class does everything
Clean, traceable flow	Spaghetti code — tangled, jump-everywhere logic
A recognizable architecture	Big ball of mud — no structure at all

Diagrams That Communicate

Designs live in people's heads until they're drawn, so teams sketch them. Most of the time a few boxes and arrows — this part calls that part, data flows this way — communicate more clearly than any formal notation. There's a formal language called UML (Unified Modeling Language) with strict symbols, but in practice a clear, informal sketch on a whiteboard usually wins. The point of a diagram is to be understood, not to be correct in a notation.

On Cadence, when a checked-off habit needs to update the streak, refresh the screen, and maybe fire a reminder, Marcus recognizes the observer pattern — those parts subscribe to the "habit checked off" event and each react on its own. He also dodges an anti-pattern: rather than pile all that logic into one giant "habit manager" class (a god object), he keeps each reaction in its own focused module. A name in each hand — one to reach for, one to avoid.