Introduction

You’re midway through debugging a gnarly race condition or designing a subtle API. The right idea finally clicks — the edge case, the invariant, the data flow that makes everything sane. You tell yourself: “I’ll implement this right after I finish this one thing.”

Twenty minutes later, it’s gone.

Not totally gone, just… fuzzy. You remember you had a good idea, but not the exact reasoning. The details that made it obviously correct are now a vague hunch. You either:

• Re-derive the thought (slower, and not always as good), or
• Shrug and move on, hoping it wasn’t critical.

This is workflow-level technical debt: losing track of tricky ideas because your brain is juggling too many moving parts.

The Three-Reminder Rule is a simple way to stop that from happening. It’s not another productivity religion. It’s a lightweight, tool-friendly approach that treats your tricky coding thoughts as first-class artifacts — before they’re code.

The Core Idea: The Three-Reminder Rule

The Three-Reminder Rule is a small system with a big payoff:

Any tricky or subtle coding idea must exist in at least three places before you consider it “safe.”

Those three places are:

1. In your head – the active idea you’re currently reasoning about.
2. In a quick capture – a message, scratch note, or card with enough detail to reconstruct the thought.
3. In your knowledge system – a tagged, cross-referenced note that you can reliably find again.

You don’t need a huge knowledge-management setup. You just need:

• One place for fast capture (chat, scratch pad, notes file), and
• One place that acts as external memory (a simple card-file or notes system with tags and links).

The aim isn’t to write beautiful documentation. The aim is to:

• Separate thinking from writing, and
• Make sure good ideas survive long enough to be implemented, refined, and reused.

Why You Keep Losing Good Ideas (And Why Speed Isn’t the Answer)

Most of us try to fix this by “coding faster”:

• “As soon as I realize the right API, I’ll just implement it immediately.”

But there are two big problems with this:

1. Implementation speed only matters if you’re implementing the right thing. If your understanding is still evolving, rushing to code is just premature optimization at the workflow level. You’re optimizing for throughput before you’ve stabilized correctness.
2. Your brain is a terrible scratchpad. When you’re coding, debugging, context switching, reading logs, and communicating with teammates, your working memory is saturated. Subtle logical constraints and insights are the first things to fall out of your head.

Instead of trying to think and implement at the same time, the Three-Reminder Rule pushes you to split the workflow:

• First, think and capture the idea.
• Then, when it’s stable enough, implement it.

This separation is what makes tricky ideas durable.

Step 1: Let Tools Handle the Mechanical Stuff

One quiet source of mental overload: writing things down feels expensive. You think:

• “I don’t have time to write a long explanation right now.”
• “If I capture this, I should make it tidy, documented, and presentable.”

Drop that expectation. Modern tools can handle the mechanical side later:

• AI assistants can turn rough bullet points into documentation or comments.
• Formatters and linters keep code style consistent without you thinking about it.
• Snippet tools and templates make it trivial to scaffold repetitive patterns.

Your job, in the moment, is to focus on the logical structure of the idea:

• What problem does this solve?
• What invariants must hold?
• What edge cases or failure modes exist?
• How does this affect other parts of the system?

Write just enough that you or future-you (or a teammate) can reconstruct that logic. Don’t polish. Don’t over-explain. Capture the logic; let tools polish later.

Step 2: Use Developer-Friendly Messaging for Fast Capture

The first external reminder should be frictionless. If it’s clunky, you won’t use it in the middle of a debugging session.

Great options include:

• A dedicated Slack/Discord channel like #scratch-ideas
• A personal DM-to-self thread in your team chat
• A local scratch.md or ideas.md file
• A note in Obsidian/Notion with a hotkey

The key requirement: good code formatting support and quick access.

Your fast capture might look like this:

[IDEA] multi-tenant cache invalidation
- Problem: per-tenant cache entries overlap; invalidation is currently global.
- Insight: key-space can be (tenant_id, resource_id) + version token
- Invariant: tenant A’s invalidation never touches B’s keys
- Edge case: tenant deletion -> must sweep all keys w/ their tenant_id
- Question: how does this interact with background warm-up jobs?

TODO: try modeling this as a “cache policy object” injected per tenant.

This is not a spec. It’s not final documentation. It’s a thinking artifact:

• Enough context to rehydrate the idea later
• Enough structure that you can search for it
• Enough detail to ask better questions about it tomorrow

That’s reminder #2.

Step 3: Build a Lightweight Card-File as External Memory

Fast capture is great, but chat streams and scratch files are chronological junk drawers. Good ideas vanish into history quickly.

That’s where reminder #3 comes in: a card-file or note system.

You can implement this using:

• Plain text/Markdown files in a folder
• A note app (Obsidian, Logseq, Notion, etc.)
• Even physical index cards, if you like analog systems

Each “card” (or note) should be tiny and focused:

• One idea, pattern, bug, or edge case per card
• A short title
• Tags and/or an ID number
• Links or references to related cards

Example (as a markdown card):

# multi-tenant-cache-invalidation

**Type:** pattern
**Tags:** caching, multi-tenant, invariants

## Problem
Global cache invalidation is too coarse for multi-tenant systems. One tenant’s updates shouldn’t evict another tenant’s cache entries.

## Idea
- Cache key: (tenant_id, resource_id, version_token)
- Per-tenant invalidation by bumping tenant-specific token or namespace
- Invariant: invalidation scope must be tenant-bounded.

## Notes
- Related: [cache-invalidation-strategies](2024-03-02-cache-strat)
- Check how this interacts with background warmers.

This is your external memory. You don’t need to remember the details — you just need to know that the idea exists and can be resurfaced.

Step 4: Add Tags and Cross-References (So Ideas Resurface)

Scattered reminders are helpful; a coherent knowledge system is powerful.

The trick is simple: every time you add or revisit a card, add at least one of:

• A tag (e.g., #caching, #concurrency, #testing, #migration)
• A cross-link to something related

Over time, your tag index (or search by tag) becomes a map of your thinking:

• Looking into #caching surfaces old bugs, patterns, and design notes.
• A new concurrency problem reminds you to check all notes tagged #race-condition.

You’ve effectively built a personalized, evolving developer wiki focused on your hardest-won insights.

This is where the Three-Reminder Rule really pays off:

1. The idea exists in your head when you first discover it.
2. It exists in your immediate capture (chat/scratch), so you don’t lose it mid-session.
3. It exists in a durable, cross-referenced card, so you can find it weeks or months later.

Putting It Together: A Practical Workflow

Here’s a realistic way to use the Three-Reminder Rule day-to-day:

1. While thinking through a tricky problem

   • Stay in your dev environment.
   • When a key idea surfaces, immediately drop a rough note into your capture tool.

2. After the session (or when you pause)

   • Skim your scratch messages.
   • Promote the important ones to individual cards/notes.
   • Tag and link them.

3. When starting related work later

   • Search your notes by tag/topic.
   • Reuse earlier reasoning rather than starting from zero.

4. When implementing

   • Refer to your card while coding.
   • Let tools (AI, templates, doc generators) turn your logic into polished comments or docs if needed.

The overhead is small — a few minutes per day — but the benefit compounds. You waste less time re-deriving the same insights and make fewer logic regressions.

Conclusion: Make Ideas First-Class Citizens

Most developers measure productivity by lines of code merged or tickets closed. But the real lever, especially for tricky systems work, is the quality and survivability of your ideas.

The Three-Reminder Rule treats those ideas as first-class citizens:

• You don’t trust your brain as the only storage location.
• You separate thinking from implementing to avoid workflow-level premature optimization.
• You leverage tools to handle formatting and polish, so you can focus on logic.
• You use messaging tools and a card-file system as a lightweight external memory that keeps hard-won insights alive.

You don’t need a complex PKM setup or a fully curated internal wiki. You just need a simple rule:

If it’s tricky enough that losing it would hurt, give it at least three reminders.

Adopt that rule, and you’ll find yourself reusing sharper ideas, writing safer code, and spending less time thinking, “Didn’t I solve this once already?”