Skip to content

Gary's Records

Preface

Why this is a story, not a manual

This book is not a manual.

It does not start by listing features, defining concepts, or explaining how a system works in abstract terms. Instead, it starts with a place, a business, and a small group of people trying to make things work.

That choice is intentional.

Most business systems fail to explain themselves not because they are too complex, but because they begin at the wrong level. They start with terminology, configuration, and structure — long before the reader has encountered a real problem that makes those things necessary.

This book takes the opposite approach.

What Gary’s Records is

Gary’s Records is a small, independent record store.

It is not special. It is not optimized. It is not “designed” to demonstrate a system.

It is simply a real business with real work: customers, products, orders, history, edge cases, and growth.

That makes it useful.

Because the problems Gary encounters are the same problems that appear in almost every business, regardless of industry:

  • figuring out what belongs together
  • keeping track of relationships
  • knowing what is true now versus what was true before
  • preventing mistakes instead of fixing them afterward
  • helping others do the right thing without constant supervision

The record store is not the point. It is the anchor.

Why this book uses a story

Systems are usually explained from the outside in: features first, usage second, understanding last.

This book works from the inside out.

Each chapter starts with a situation that feels reasonable. Something Gary does that makes sense at the time. Something that works — until it doesn’t.

Only when a concrete problem appears do we introduce structure.

Only when structure becomes unavoidable do we name it.

This mirrors how understanding actually develops: through consequences, not definitions.

The main characters

You will meet four recurring characters throughout the book.

Gary

Gary owns the record store.

He has strong intuition about his business and a clear sense of what should work. He starts with pen and paper, moves to spreadsheets, and gradually realizes that his problems are not about tools — they are about structure.

Gary represents:

  • business intuition
  • reasonable first attempts
  • the limits of informal systems

If something feels confusing to Gary, it is probably confusing to the reader as well.

Sam

Sam is a computer science student who helps Gary think things through.

He does not introduce solutions prematurely. He does not win arguments by authority. He does not turn every conversation into theory.

Instead, Sam makes consequences visible.

He represents:

  • system thinking
  • structural trade-offs
  • explaining why constraints exist

Sam never replaces Gary’s understanding. He helps refine it.

Lisa

Lisa works part-time in the store.

She is competent, attentive, and practical. She does not design systems, but she is affected by them every day. When structure is unclear, she feels it first — through hesitation, workarounds, and questions that should not require asking.

Lisa represents:

  • everyday execution
  • downstream effects of decisions
  • the cost of implicit rules

She makes invisible problems visible.

Hank

Hank works in the store on an hourly basis.

He is friendly, informal, and focused on getting through the day. He follows instructions when they are clear, but he does not stop to interpret intentions or edge cases. If the system allows something, Hank assumes it is allowed.

Hank represents:

  • casual usage
  • what happens when rules are implicit
  • why defaults and restrictions matter

Hank does not break the system on purpose. He shows what breaks naturally when structure is missing.

How the chapters work

Each chapter focuses on a specific problem Gary encounters as the store grows.

The pattern is consistent:

  1. A situation that feels familiar
  2. A solution that seems reasonable
  3. An edge case that exposes a limitation
  4. A discussion about structure and consequences
  5. A concept is named — lightly, and only when needed

You are not expected to memorize terminology.

You are expected to recognize patterns.

How to read this book

This book is meant to be read in order.

Not because the later chapters are “advanced”, but because each chapter builds intuition that the next one depends on. Skipping ahead may still make sense — but it will feel thinner.

If you already understand structured systems, this book may feel slow at first. That is also intentional. It is designed to slow down reasoning, not accelerate configuration.

If you are new to structured systems, this book should feel grounded, not overwhelming.

Either way, the goal is the same:

To help you understand why systems need structure — before asking you to work with one.

What comes next

The story begins before anything is built.

Before systems. Before explanations. Before structure is named.

Just a store, a door that hasn’t opened yet, and a day about to start.

Chapter 1: A normal day at Gary’s Records