<- Back To Patterns

About Patterns

A pattern is a reusable way of thinking about a problem.

In software engineering, patterns are often used to describe recurring design, architecture, data, infrastructure, workflow, and delivery problems.

A pattern is not a law.
It is not a framework.
It is not proof that something is automatically good.

A good pattern says:

I have seen this shape of problem before.
This approach often works. These are the trade-offs.
Here is when I would, and would not, use it.

That is the point of this section.

It gives names to useful approaches, conventions, warnings, and trade-offs that come up more than once.

Most of the patterns here are about software engineering.

But the idea is bigger than software. Other disciplines have patterns too. Electricians, builders, mechanics, gardeners, cooks, and engineers all learn repeated shapes of work. They learn what holds up, what fails later, and which shortcuts are only shortcuts because someone else pays the cost.

Problem

A lot of technical work involves explaining the same shapes over and over again.

Why structure data this way? Why split a system like that? Why avoid this shortcut? Why is this simple-looking option risky?

Without a shared name, every discussion starts from zero.

That wastes time, but it also hides the real decision. People end up debating the explanation instead of the trade-off.

A named pattern gives people a handle. It lets the conversation move from:

What are you even talking about?

to:

Does this pattern actually fit our situation?

That second question is where the useful thinking starts.

Pattern

A pattern is not invented from nothing.

It is recognised.

You see the same shape of problem appear in different places, with similar solutions, similar trade-offs, and similar ways it can go wrong.

When that repeated shape is useful enough to explain again, it is worth writing down as a pattern.

A pattern should explain:

• the problem
• the context
• the approach
• why it works
• where it breaks
• when to use it
• when to avoid it
• related patterns and anti-patterns

The goal is not to make every idea sound academic or official.

The goal is to capture useful experience in a practical, linkable form.

A good pattern should help someone understand the shape of the problem faster, without pretending the answer is automatic.

Why Patterns Work

Patterns work because they compress experience into a name.

Once something has a name, it becomes easier to discuss. Instead of re-explaining the whole thing every time, you can point to the pattern and spend the conversation on whether it applies.

That is the useful bit.

Not the clever name.
Not the diagram.
Not the feeling of sounding official.

The value is the shared understanding behind it.

A pattern is useful when it helps people ask better questions:

• What problem are we solving?
• What constraints matter here?
• What failure modes are we accepting?
• What are we optimising for?
• What are we making harder later?

A pattern should speed up thinking, not replace it.

Where Patterns Come From

Patterns are not supposed to be random ideas with official-sounding names.

A useful pattern is usually discovered before it is named.

It comes from repeated observation:

• systems that worked
• systems that failed
• designs that kept appearing
• trade-offs that kept repeating
• mistakes that kept causing the same pain
• experienced people noticing the same shape of problem in different places

Some patterns come from academic research.

Some come from books, conference papers, and formal catalogues.

Some come from industry practice, open-source projects, postmortems, architecture reviews, and hard-won operational experience.

The important part is not whether the pattern came from a university, a book, a production system, or someone’s garage.

The important part is whether the pattern has earned its name.

A pattern is stronger when:

• it has been seen in more than one place
• it solves a recurring problem
• the context is understood
• the trade-offs are known
• the failure modes are documented
• people can explain when not to use it

A weak pattern is just a preference wearing a badge.

A strong pattern is compressed experience.

Patterns Outside Software

Software engineering has many well-known patterns: design patterns, architecture patterns, data patterns, deployment patterns, workflow patterns, and operational patterns.

But patterns are not only a software thing.

A builder learns which joins are strong.
An electrician learns which connections stay safe over time.
A mechanic learns which fixes are reliable and which ones come back as repeat failures.
A gardener learns which layouts, soil choices, and watering habits survive real weather.

The common thread is reuse.

A pattern can describe a database layout, a service boundary, a deployment workflow, a wiring habit, a garden setup, a 3D printer upgrade, or a way of organising tools in a garage.

The discipline changes.

The idea stays the same:

This shape appears often enough that it is worth naming.

Anti-Patterns

An anti-pattern is a reusable mistake.

It is something that looks like a solution but usually creates pain later.

Anti-patterns matter because they are often attractive. If they were obviously terrible, people would not keep choosing them.

An anti-pattern might be tempting because it is:

• familiar
• fashionable
• easy to approve
• easy to explain
• already available
• convenient in the short term
• similar to something that worked somewhere else

That last one is important.

Many anti-patterns start life as patterns used in the wrong context.

The visible shape looks right, but the reason behind it does not apply.

For example, soldering wires can look neat, skilled, and permanent. In the right context, soldering is useful. But if a connection relies on solder for mechanical strength, heat, movement, and time can turn a tidy-looking joint into a failure point.

The anti-pattern is not “solder is bad”.

The anti-pattern is trusting the visible solution while ignoring the hidden failure mode.

Software has the same problem everywhere.

A shared database can look simpler.
A spreadsheet can look faster.
A giant service can look easier to manage.
A queue can look like decoupling.
A rewrite can look like progress.
A meeting can look like alignment.

Sometimes those choices are right.

Sometimes they are just future pain with a clean label.

Pattern Danger

Patterns become dangerous when people treat them as rules.

A pattern that works in one context can be expensive, pointless, or harmful in another. This is especially true when people copy the visible shape without understanding the reason behind it.

That is cargo-cult engineering.

The question should not be:

Is this a recognised pattern?

The better question is:

Does this pattern fit the problem, constraints, people, and failure modes in front of us?

Engineering judgement lives in that gap.

A pattern should never be used as a shortcut for not thinking.

Use This Pattern When

Use named patterns when:

• the same explanation keeps coming up
• the trade-offs matter
• the idea is useful across more than one project
• the topic is too durable to be a throwaway note
• you want to link to an explanation instead of rebuilding it every time
• naming the idea would help people have a better conversation

Patterns are especially useful when they make a decision easier to explain, question, and improve.

Avoid This Pattern When

Avoid turning something into a pattern when:

• it only happened once
• it is just a personal preference with no useful reasoning
• the context is too specific to reuse
• the name makes the idea sound more proven than it is
• the pattern hides more than it explains
• people are likely to copy the shape without understanding the trade-off

Not every thought needs a name.

Some things can just be notes.

Summary

Patterns are reusable explanations.

Anti-patterns are reusable warnings.

Both are useful when they help people understand trade-offs faster.

Both are dangerous when they become shortcuts for not thinking.

The point is not to collect fancy names.

The point is to make useful decisions easier to explain, question, and improve.

Patterns | About Patterns

<- Back To Patterns

Published: 19/06/2026 UTC

Updated: 19/06/2026 UTC