Day 50 — The 7-40 Challenge

February 24, 2026

I spend my days writing SQL, griping at people about their data, and making sure systems talk to each other the way they’re supposed to. It’s not glamorous. Nobody’s making a movie about the guy who finds the duplicate vendor records.

But here’s the thing nobody tells you about data management — it’s storytelling. And I don’t mean that in a fluffy, motivational-poster kind of way. I mean it structurally. The same brain that queries a database is the same brain that builds a fictional world. Let me show you what I mean.

In a database, every table needs a primary key. That’s the unique identifier that connects one set of information to another. A vendor’s tax ID, an employee number, a transaction code. Without it, you’re just staring at rows of disconnected facts that don’t mean anything.

Characters work the same way. Tiffany Grant, the protagonist of my novel Phase Defiant, has a primary key — and it’s not her name or her abilities. It’s her relentless need to ask questions. She doesn’t accept things at face value. That trait is what connects her to every relationship, every conflict, and every turning point in the story. It’s also what connects her to Thomas, because he’s wired the same way. When those two primary keys match up, suddenly you can JOIN the tables together and the story gets a whole lot richer.

Speaking of JOINs — in SQL, when you join two tables, you take partial pictures and combine them into something complete. One table might show you a vendor’s name and address. Another shows you their payment history. A third shows you the contracts. Individually, they’re just fragments. Joined together, they tell you exactly who that vendor is, what they do, and whether or not they’re worth keeping around.

Fiction works the same way. Tiffany by herself is one dimension of the story. Thomas by himself is another. The organization watching them is another. But when those plotlines JOIN — when characters realize they’re not alone and start working together — the story gets bigger than any one of them. That’s not a coincidence. That’s architecture.

Now, let’s talk about dirty data. In my world, dirty data is the stuff that doesn’t add up. Duplicate records, missing fields, values that shouldn’t exist, timestamps that make no sense. And here’s what most people don’t realize — dirty data tells you a story too. It tells you where the organization cut corners, where they stopped paying attention, and sometimes where somebody’s actively hiding something.

Fiction has dirty data too. It’s called the villain.

A good villain in a story does the same thing bad data does in a database — they either hide incompetence or they hide something more sinister. They lead you to believe something that isn’t true so they can achieve their own ends. And just like a senior analyst can spot a counterfeit record the way a bank teller can feel a counterfeit bill, an experienced reader can feel when something’s off in a story. The details don’t add up. Someone’s motives don’t match their actions. That’s dirty data, and it means someone in the story is lying to you.

I’ve heard that bank tellers who handle money all day long can spot a fake bill the moment it hits their fingers. They don’t need to hold it up to the light. They just know. I’ve seen the same thing in data. When you’ve worked with it long enough, you know when something’s wrong before you can even articulate why. The flow is off. The connections don’t make sense. And that instinct — that pattern recognition — is the exact same muscle I use when I’m writing fiction and something in the plot doesn’t feel right.

Here’s one more parallel, and then I’ll stop nerding out. There’s a principle in AI and data science: garbage in, garbage out. If your data is poorly managed, your AI is going to make erroneous assumptions based on bad connections. It won’t understand your business. It won’t see the truth. It’ll confidently give you wrong answers because the inputs were wrong.

Storytelling has the same rule. If you skip the world-building, if you don’t lay down the framework, if you don’t know who your character is and what they want and what’s standing in their way — you end up with a plot that confidently goes nowhere. The architecture of a good story is the same as the architecture of a good database. Character wants something. Adversity stands in the way. A guide shows them a path. They move toward victory or experience defeat. That’s the character arc. That’s also, if you squint at it, a pretty decent data flow diagram.

I say all of this because I spent a long time thinking I had to be one thing. Technical or creative. Analytical or artistic. SQL or storytelling. The truth is, they’re the same skill wearing different clothes. Both require you to see patterns. Both require you to connect things that look unrelated. Both require you to know when something doesn’t add up and have the courage to say so.

So if you’re the person who spends all day in spreadsheets and databases and you think you’re not creative — you’re wrong. You’ve been telling stories with data your whole career. You just didn’t call it that.

And if you’re the creative person who thinks data is boring — come sit with me for an hour. I’ll show you a database that reads like a thriller. We can finds some villains lurking for sure.