My wife kept a movie notebook. Not a spreadsheet, not an app, a physical notebook where she wrote down what we watched. It went back to 2023 and ran to about 275 entries.
A few weeks ago she sat down and typed the whole thing out so I could pull it into a project I was building. When I opened her file, the first thing I noticed was that 275 handwritten entries collapsed to 235 unique titles.
Forty duplicates. And the question of what to do about them ate an entire afternoon.
The schema was the easy part
I build data systems for a living, so my instinct was to reach for the obvious answer. A repeated title in a watch log means a rewatch. Keep both. Rewatches are signal. We loved that movie enough to see it twice, and a good log should remember that.
That instinct was wrong, and it took a conversation to find out.
When I asked her about it, she explained how she'd actually made the list. She wasn't logging in real time. She was reconstructing three years of viewing from memory, page by page, and when you rebuild a list from memory you double-count. You write down a movie, forget you wrote it, and put it down again forty pages later. The duplicates weren't rewatches. They were the fingerprint of how the list got made.
So the right call was to drop them. Not because a dedup script said so, but because the person who wrote the list told me what the mess meant.
The judgment is the work
Here is the part that stuck with me. That decision is completely invisible in the finished product. The database has 235 clean rows. Nobody looking at it will ever know that forty of them almost survived, or that a five minute conversation is the only reason they didn't.
This is the thing about data work that no tutorial prepares you for. The schema is trivial. Titles, dates, ratings, a nullable field for the ones we couldn't date. I wrote that in ten minutes. The real work was a single judgment call about what a duplicate means in this specific list, made by this specific person, for this specific reason.
You cannot infer that from the data. The data looks identical whether a duplicate is a rewatch or a transcription error. Only the human who made the artifact can tell you, and if you don't ask, you will confidently import forty lies and call it done.
Every dataset you have ever touched is full of decisions like this. Someone decided what counted, what got merged, what got thrown out. Those decisions are the actual content. The rows are just where they landed.
Build it like it will last
The second decision was where to put it.
The lazy version was easy. Dump the list into a note, or open a Letterboxd account, and move on. I did neither. I built it as a real, first-class part of my own website, with its own tables, its own screens, its own place in the site I already run.
I gave myself one rule while building it. The movie data never lives inside the page's config. Pages come and go. You redesign, you delete a section, you move things around. If the record of three years of watching lives inside the layout of one page, it dies the first time you tidy up. So it lives in its own tables, where it survives the page, can show up in more than one place, and can be queried like it matters.
Because it does matter. That notebook is a small record of how two people spent their evenings for three years. My wife kept it by hand. The least I can do is store it like it's worth keeping, instead of renting a slot in someone else's product that will change its terms, its features, and its export format whenever it feels like it.
There is a version of this whole project that is faster and requires no code at all. But the fast version treats the record as disposable. The point was never speed. The point was that this thing deserved to be built properly, on ground I control.
The takeaway
Two lessons, and they turn out to be the same lesson.
When you turn something handwritten into something structured, the format is the easy part. The hard part is understanding what the mess means, and the only way to learn that is to ask the person who made it. Respect the artifact enough to interrogate it.
And when the artifact is yours, build it like it will outlast the tool you built it in. Your records deserve to be first-class. Not a field in someone else's schema, not a row in a product that answers to shareholders, but a real thing that lives where you can reach it.
The forty duplicates are gone. But I know exactly why they were there, and that knowledge is worth more than the forty rows ever would have been.