As software engineers, we spend our days designing database schemas. We normalize tables, set up foreign keys, and obsess over data integrity. It’s beautiful, logical, and it works perfectly in production.
So, naturally, when I started building my own productivity system in Notion, I applied the exact same logic. I created a relational masterpiece. I had a Tasks table with a relation to Projects, which was related to Areas of Life. I had rollups, formulas, and linked views.
It looked like a well-architected microservice. It was also completely useless.
The Problem with Over-Normalization
In databases, over-normalization leads to slow queries because you have to JOIN 10 tables just to get one piece of data.
In productivity, over-normalization leads to decision fatigue. If I wanted to add a task like "Buy milk," I had to decide: Is this a project? Is it an area? What's the energy level? What's the priority?
I was spending 15 minutes a day just doing data entry. My brain was spending more energy managing the system than actually doing the work. I was experiencing massive "cognitive load" just trying to open my dashboard.
The Refactor: The Flat Table
I decided to refactor my entire system. I deleted all the relations and rollups.
Now, my task manager is a single, flat table. It has only three columns:
Task Name (String)
Status (Select: To Do, In Progress, Done)
Date (Date, optional)
That's it. No complex JOIN logic. No dependencies.
If I need context, I just write it in the task name (e.g., "Buy milk for Project X"). I use a simple filter: Status != Done. When a task is checked off, it disappears from my view.
Why This Works Better Than Relational Databases
Low Friction: Adding a task takes 2 seconds.
No Dependency Hell: If I don't update my "Life Areas" database, my daily task list still works perfectly.
Mental Clarity: A flat list is easy to scan. A relational dashboard requires cognitive parsing.
The Lesson
We love building complex systems because it makes us feel like good engineers. But good engineering is about solving a problem with the least amount of complexity necessary. Your personal life doesn't need a relational database. It needs a list.
If you want to see how I structure this minimalist approach (with a few clever formulas for prioritization), I’ve shared my exact schema in the ADHD Daily Planner.
How do you structure your tasks? Are you a relational database person or a flat list person? Let me know!
Top comments (10)
Flat, and for the same reason, but the date column is the one thing I would not make optional.
Status tells you what is left. Status plus a date tells you whether you are moving or just re-filing the same six tasks every week. And the cheap version of that is not a rollup, it is a view: Status != Done, Date within the past 7 days, no grouping. If that view is thin, the system is flattering you.
I do not run my life in Notion, so take this from the record-keeping side rather than the productivity side. I keep a log of which piece of work is credited to whom and when, and the flat version of it survives because I only ever ask two questions: when, and which one. The moment I want "what changed between these two entries" I need a relation for exactly one field. Default flat, and add the relation the day you catch yourself doing the join by hand.
Also, "Buy milk for Project X" in the title is not a hack. It is denormalization with a comment attached, and every database does it for a reason.
The Status != Done, Date within the past 7 days view is brutal and brilliant. It’s the ultimate BS detector for a productivity system. If that view is empty, you aren't making progress, you're just playing musical chairs with your tasks. Definitely stealing this metric!
Steal it, it's free. One warning from having run a version of it: the view rewards small finished things and punishes long ones.
A three-week job sits in that list with a date older than seven days, so it looks stale even on a day you actually moved it forward. It quietly trains you to chop real work into pieces small enough to keep the view green. I keep one deliberately red row now, so the metric can't tell me hard work is nothing.
You seem to already know which views earn their place and which are decoration. What's the one view in your own setup that has survived the longest?
Keeping one deliberately red row so the metric doesn't gaslight you into thinking hard work is nothing... that is a brilliant psychological hack.
To answer your question: my longest-surviving view is a simple "Due in the next 14 days" filter (based on the actual deadline, not the last edited date). It survives because it's completely agnostic to how long a task has been sitting there. It doesn't punish slow-burn projects; it just tells me what's actually on fire. The 7-day view is great for momentum, but the deadline view is what keeps me employed!
The deadline view and the momentum view are answering different questions, and you have them doing exactly that: one for the thing on fire, one for whether you actually moved.
One thing worth flagging about the red row: a 14-day filter hides slow work just as efficiently as a 7-day one, it just hides it further ahead. What makes both of those views survive is that neither one has an opinion. A rank, a streak, a score, those all die inside a month, because there is something there that can be disappointed. A filter on a fact cannot be.
So I will ask the obvious follow-up: what is the slow-burn project that those 14 days are protecting right now?
"Filters on a fact cannot be disappointed" is a brilliant line—I'm definitely stealing that.
To answer your question: my 14-day view is currently protecting a massive, slow-burn legacy code refactor. If I looked at it through a 7-day momentum lens, I'd feel terrible every day because the "progress" is just quietly migrating files and fixing tests without any immediate visible result. The 14-day window lets it breathe without letting it get forgotten.
A refactor like that has no daily result on purpose, so the number I would watch is not the diff. It is the count of files that no longer know the old thing exists. One less every few days, and no single day looks like progress.
Mine is twelve portraits of women the record credited to someone else. The only number going down is the list of names it got wrong, and nobody comments on any of them. The quiet parts of both jobs are the parts actually working.
"The quiet parts of both jobs are the parts actually working." That is such a beautiful and profound way to put it. Real progress rarely looks like a highlight reel. Watching that count of files (or incorrect names) slowly tick down is the purest measure of technical debt being paid off. It's invisible labor, but it's the most important kind.
This is an excellent illustration of a principle that extends far beyond software engineering: the sophistication of a system should be measured by how effectively it serves its purpose, not by how many features or layers of complexity it contains.
What makes your experience particularly interesting is the distinction between technical efficiency and cognitive efficiency. A relational database may be beautifully structured from an engineering perspective, but a personal productivity system operates under a different constraint: human attention. Every additional field, category, and decision introduces a small cognitive cost. Individually, these costs seem insignificant, but collectively, they can create enough friction to discourage someone from using the system altogether.
There is also a fascinating behavioral psychology component here. Research on cognitive load and decision-making suggests that unnecessary mental demands can interfere with task performance. When organizing a task becomes more complicated than completing it, the productivity tool has effectively become another task competing for our limited attention. We can become so invested in optimizing the process that optimization itself turns into a sophisticated form of procrastination.
I particularly appreciate your decision to eliminate unnecessary relationships rather than simply automate them. Automation can make a complicated system faster, but simplification can eliminate the need for that complexity altogether. That is an important distinction, especially in an era when we are constantly encouraged to add more tools, integrations, dashboards, and AI-powered features to our workflows.
To answer your question, I lean toward the flat-list approach for everyday execution, with structured organization reserved for projects that genuinely require it. A simple list makes it easier to capture an idea immediately, identify the next action, and maintain momentum. For larger initiatives involving multiple deadlines, dependencies, or collaborators, a relational structure can provide meaningful value. The key is knowing when that additional structure earns its place.
Perhaps the most useful metric for evaluating any productivity system is not how much information it can organize, but how little attention it requires before we can begin doing meaningful work.
After all, the purpose of a productivity system is not to become another impressive project we maintain. It is to make progress on the projects that actually matter.
"Optimization itself turns into a sophisticated form of procrastination" is the most painfully accurate sentence I’ve read all week. It's so easy to fall into the trap of building the "perfect" system—adding tags, creating dashboards, linking databases—only to realize you've spent three hours organizing your tasks instead of actually doing them. This is a great reminder that the best system is the one that gets out of your way.