Aggressively Document Your Life

You are forgetting almost everything that happens to you. Not in a vague, philosophical, “memories fade” sense. In a measurable, researched, mathematically predictable sense. Hermann Ebbinghaus demonstrated in 1885 that humans lose roughly 50% of newly learned information within the first hour. 70% within 24 hours. After a month, you retain maybe 10% of what you experienced, unless you did something to intervene.

That project you finished three months ago? The architecture decisions you made, the tradeoffs you weighed, the bugs that cost you two days? Most of it is already gone. The meeting where you explained your reasoning to the team? You remember having the meeting. You don’t remember what you said. The book you read in October that “changed how you think about X”? You remember the feeling. You don’t remember the argument.

This isn’t a personal failing. This is the default behavior of human memory. Your brain is an aggressive garbage collector, and it does not ask permission before running.

Documentation is the intervention.

Not journaling (though that counts). Not blogging (though that counts too). Documentation. The deliberate, systematic act of writing down what you do, what you learn, what you decide, what you build, and what you think, in a form you can search later.

This is a manifesto for doing it aggressively. For treating documentation not as a nice-to-have professional habit, but as a core life practice on par with exercise, sleep, and compound investing. For understanding that the person who documents relentlessly is playing a fundamentally different game than the person who relies on memory.

Here’s the case.

I. You are losing years of your life to entropy

Let’s put real numbers on this.

Say you’re 28 years old. You’ve been working in software for 6 years. In that time, you’ve probably completed somewhere between 30 and 100 meaningful projects, depending on how you count. You’ve read hundreds of articles, dozens of books, watched conference talks, debugged gnarly problems, had conversations that shifted your thinking.

How much of that can you actually recall in useful detail right now?

If you’re like most people: almost none of it. You have impressions. Vibes. “Yeah, I dealt with something like that before.” But the specifics? The exact approach you used, the error messages you saw, the alternatives you rejected and why? Gone.

This is not a memory problem. This is an information preservation problem. And the difference matters because memory problems are hard to solve (your brain does what it does), but information preservation problems have been solved for literally thousands of years. The technology is called writing things down.

The Ebbinghaus forgetting curve isn’t some obscure finding. It’s been replicated extensively, most notably in a 2015 PLOS ONE study by Murre and Dros that confirmed the original results with modern methodology. The curve is exponential and steep. But here’s the part people miss: the curve applies to information you don’t review or reinforce. The moment you write something down, you’ve created a retrieval path. The moment you write it down in a searchable, organized system, you’ve built an external memory that doesn’t decay.

Your biological memory follows an exponential decay function. A written record follows a step function: it either exists or it doesn’t. And if it exists, it’s as fresh on day 1,000 as it was on day 1.

Every week you go without documenting your work, your decisions, your learning, you are permanently losing information that took you real time and real effort to acquire. That’s not a metaphor. That’s the math.

II. Documentation is not what you think it is

When most people hear “document your life,” they picture a journal. A diary entry before bed. Maybe a blog post once a month if they’re ambitious.

That’s a small slice of what I mean. Here’s the full taxonomy of documentation that matters:

Type	What it captures	Example
Work logs	Daily record of what you did, what you decided, what blocked you	“Spent 3 hours debugging the WebSocket reconnection. Root cause: server was sending close frame before client acknowledged.”
Decision records	The reasoning behind non-obvious choices	“Chose Postgres over DynamoDB for this service because we need ad-hoc queries and the data model is relational. Accepted the tradeoff of managing schema migrations.”
Learning notes	What you learned from a book, talk, course, paper, or conversation	Notes on a specific chapter with your reactions and applications, not highlights
Project write-ups	Post-completion summary of what you built, why, what worked, what didn’t	A retrospective written within a week of shipping
TIL (Today I Learned) entries	Small, atomic facts or techniques you picked up	“TIL: git log --all --oneline --graph gives you ASCII art branch visualization”
Debug journals	The path you took to solve a hard problem	Step-by-step from symptom to root cause, including dead ends
Meeting notes	What was discussed, what was decided, what are the action items	Not a transcript. The three things that mattered.
Idea logs	Raw ideas, half-formed thoughts, things to explore later	“What if we used content-addressable storage for the asset pipeline?”
Reading annotations	Your marginalia, reactions, and connections while reading	“This connects to what I read in Designing Data-Intensive Applications about partition tolerance”
Code commit messages	Searchable history of what changed and why	Not “fix bug” but “Fix race condition in session cleanup: timer was firing before connection close handler completed”

That’s ten distinct types of documentation, and most people do zero of them systematically. Maybe they write decent commit messages sometimes. Maybe they keep a notebook that they lose or never re-read.

The point is not to do all ten. The point is to recognize that “documentation” is a much wider practice than most people realize, and even adopting two or three of these consistently puts you in a radically different position than doing none.

III. The people who document obsessively are winning

Let me show you some specific examples of people who practice aggressive documentation, and what it’s gotten them.

Simon Willison maintains a TIL (Today I Learned) repository that, as of early 2026, contains over 575 entries. Each one is a small, searchable note about something he learned that day. He also maintains a blog at simonwillison.net where he writes longer-form posts. The TIL repo alone is a staggering resource, not just for him but for the thousands of people who stumble across it via search engines. But the primary beneficiary is Willison himself. He has a searchable, timestamped record of his own learning across years. When someone asks “didn’t you figure out how to do X?”, he doesn’t rely on memory. He searches his own archive.

This is not a hobby. This is competitive infrastructure. Willison’s documentation practice is part of why he’s one of the most effective independent developers in the Python and AI ecosystem. He can build on top of what he learned three years ago because he wrote it down three years ago.

Andy Matuschak takes a different approach. His working notes (notes.andymatuschak.org) are organized as “evergreen notes,” meaning they’re designed to evolve, accumulate, and connect over time rather than being timestamped diary entries. Matuschak writes every morning as part of his daily practice, revising and linking existing notes rather than always creating new ones. The result is a living knowledge graph of his thinking about memory, learning, tools for thought, and education.

Here’s what’s interesting about Matuschak’s system: the notes are written primarily for himself, as a thinking environment. He shares them publicly as an experiment, but the value is in the practice, not the audience. The act of writing and revising forces him to refine his thinking in a way that reading alone never does.

Gwern Branwen (gwern.net) is perhaps the most extreme example. His site contains hundreds of deeply researched essays on topics ranging from genetics to darknet markets to anime recommendations, each one extensively footnoted, cross-referenced, and maintained over time. Gwern’s stated goal is “durable, self-documenting hypertext” that resists link-rot and stylistic drift for decades. His pages have popup annotations, archived links, and explicit confidence tags on claims. The result is a personal encyclopedia that serves as both a reference for others and an external memory system for himself.

Patrick Collison (CEO of Stripe) maintains several public lists on his personal site: a bookshelf, a list of people he finds interesting, a collection of questions he’s thinking about. These are documentation artifacts. They’re searchable records of his intellectual interests and reading over time. They also serve a networking function: people who share those interests find him through them.

Derek Sivers created the /now page concept, which is a simple page on your personal site describing what you’re currently focused on. This spawned nownownow.com, a directory of people maintaining /now pages. It’s a lightweight form of life documentation that thousands of people have adopted. The value is both personal (forcing yourself to articulate what matters to you right now) and social (signaling to others what you’re available for).

None of these people are doing the same thing. Willison writes atomic TIL snippets. Matuschak writes evolving evergreen notes. Gwern writes exhaustive essays. Collison maintains curated lists. Sivers maintains a status page. But they’re all doing the same underlying thing: creating persistent, searchable, externalized records of their thinking and doing.

And they’re all benefiting from it in ways that compound over time.

IV. Documentation compounds. Memory doesn’t.

This is the core economic argument, and it’s the one that should change your behavior if nothing else does.

Memory is a depreciating asset. What you know right now is the peak. Tomorrow you’ll know less of it. Next month, less still. Your biological memory follows an exponential decay curve. The half-life varies by type of information and by individual, but the direction is always down.

Documentation is a compounding asset. Every entry you write increases the total value of your archive. And unlike most compounding systems, the rate of compounding increases as the archive grows, because the probability that a new entry connects to something you wrote before goes up with the size of the archive.

Let me make this concrete.

Say you start keeping a work log on January 1st. By March, you have 60 entries. In April, you face a bug that reminds you of something you dealt with in February. You search your log, find the entry, and save yourself two hours. That’s a small win.

Now fast-forward three years. You have roughly 750 work log entries. You’re interviewing for a new job. The interviewer asks you to describe a time you navigated a difficult technical decision under uncertainty. Most people fumble through a half-remembered anecdote. You open your archive, search “tradeoff” or “decision” or the name of the project, and pull up the exact decision record you wrote at the time, including the alternatives you considered, the risks you identified, and the outcome.

That’s not a small win. That’s a structural advantage.

Now fast-forward ten years. You have thousands of entries across work logs, decision records, learning notes, project write-ups, and TIL snippets. You’re trying to write a conference talk. Or mentor a junior engineer. Or start a company. Or write a book. Every one of these activities is dramatically easier when you have a decade of searchable, organized documentation to draw on.

Here’s the compounding math in simplified form:

Year	Entries (est.)	Searchable connections	Memory of oldest entries (unaided)
1	250	Low (small corpus)	~50% retained
3	750	Medium (patterns emerge)	~10% of year 1 retained
5	1,250	High (dense cross-references)	~5% of year 1 retained
10	2,500	Very high (personal knowledge base)	~1% of year 1 retained

The gap between the “documented you” and the “undocumented you” gets wider every single year. At year 10, the undocumented version of you has effectively lost access to 99% of the specific details of their early career. The documented version has lost none of it.

This is the same logic behind compound interest in finance. Small, consistent deposits into a system with positive feedback loops produce outsized returns over time. The earlier you start, the larger the advantage. And like compound interest, the benefits are invisible in the short term and overwhelming in the long term.

V. “But I don’t have time to document”

This is the objection I hear most often. Let me be direct: it’s wrong, and here’s why.

First, the time cost is much lower than people imagine. A daily work log entry takes 5 to 10 minutes. A decision record takes 15 minutes. A TIL entry takes 2 minutes. We’re talking about 15 to 30 minutes per day for a documentation practice that covers work logs, decision records, and TIL entries. That’s less time than you spend in your least useful meeting of the day.

Second, documentation saves time. Every hour you spend writing down how you solved a problem is an hour you don’t spend re-solving it six months later. Every decision record you write is a conversation you don’t need to re-have when someone asks “why did we do it this way?” Every debug journal entry is a trail you don’t need to re-trace.

The people who say they don’t have time to document are the same people who spend 45 minutes re-deriving something they already figured out because they didn’t write it down. The time argument against documentation is like the time argument against exercise: it sounds reasonable until you realize the activity pays for itself and then some.

Third, and this is the part people really resist: documentation is thinking. Writing a decision record isn’t overhead on top of the actual work. It IS the work. The act of articulating why you chose Option A over Option B forces you to confront whether you actually have good reasons or whether you’re just going with your gut. Sometimes you start writing the decision record and realize you haven’t actually decided yet. The writing surfaces the gap.

Andy Matuschak has written about this directly. His morning writing practice isn’t a supplement to his research. It’s how the research happens. The notes are the thinking, not a record of thinking that happened elsewhere.

This is the strongest version of the argument for documentation: it doesn’t just preserve your past thinking. It improves your present thinking. The overhead is negative.

VI. “But nobody will read it”

Good. Write it for yourself.

The audience for your documentation is you, six months from now. You, two years from now. You, during a job search. You, onboarding a new team member. You, writing a performance review. You, trying to remember what the hell you were thinking when you made that architecture decision.

The fact that other people might benefit is a bonus, not the point. Simon Willison’s TIL repo has become a public resource, but that’s a side effect of his personal practice, not the reason for it. Gwern writes primarily for his own reference and happens to publish it.

If you’re only willing to document things that have an audience, you’ve confused documentation with content creation. Content creation is about serving a reader. Documentation is about serving yourself. They’re different practices with different motivations and different quality bars.

Content creation asks: “Will someone find this interesting or useful?” Documentation asks: “Will I need this information again?”

The second question is almost always yes. That’s why you should write it down.

Now, here’s the flip side. If you do decide to make your documentation public (a blog, a TIL repo, a digital garden), the career benefits are enormous, and they’re orthogonal to the personal benefits. Public documentation is the single most effective way to demonstrate competence to people you’ve never met. Your resume says you’re good at distributed systems. Your blog post walking through how you debugged a consensus failure, with timestamps and dead ends and the actual solution, proves it.

Hiring managers, conference organizers, open source maintainers, potential co-founders: these people are all looking for evidence of how you think. Public documentation is that evidence.

But again: the primary audience is you. If you never publish a word, the personal benefits alone justify the practice.

VII. “I’ll just remember the important stuff”

No, you won’t.

This is the most dangerous objection because it feels true. Of course you’ll remember the important things. The big project. The major decision. The career-defining moment.

But you won’t remember them with the fidelity you think you will. You’ll remember that you made the decision. You won’t remember the three alternatives you rejected or the specific data that tipped you toward Option A. You’ll remember the project shipped. You won’t remember the key insight that unblocked the hardest part. You’ll remember the meeting happened. You won’t remember the exact concern your colleague raised that turned out to be right six months later.

This is because human memory doesn’t work like a file system. It works like a lossy compression algorithm that runs continuously. Every time you recall a memory, you’re actually reconstructing it from fragments, and the reconstruction process subtly alters the memory itself. This is well-established in cognitive psychology. Elizabeth Loftus’s work on memory distortion showed that the very act of remembering changes what you remember.

You don’t just forget things. You remember them wrong. And you’re confident about it.

The only defense against this is an external record created at the time of the event, before your memory had a chance to compress and distort it. A work log written the same day. A decision record written while the context is fresh. A debug journal written during the debugging, not after.

If you wait until something feels important enough to document, you’ve already lost most of the detail. The time to document is now, not when you’ve decided it matters. You can’t predict what will be important in five years. The whole point is to capture broadly so that future-you has the raw material to work with.

VIII. The tools don’t matter (much)

People spend months evaluating Obsidian vs. Logseq vs. Notion vs. Apple Notes vs. a plain text folder. This is procrastination disguised as preparation.

Here’s what actually matters for a documentation system:

Requirement	Why
Searchable	If you can’t find it, it doesn’t exist
Low friction to write	If it takes more than 30 seconds to start a new entry, you won’t do it
Portable	You need to be able to get your data out. No vendor lock-in on your own thoughts
Durable	The system should work in 10 years, not just today

That’s it. Four requirements. Every serious tool on the market meets these. Plain markdown files in a folder meet these. A text file called worklog.md that you append to daily meets these.

Here are some reasonable options, not because the tool matters, but because having a specific recommendation removes one more excuse:

Tool	Best for	Format	Portability
Plain markdown files + git	Engineers who want total control	.md files	Perfect (it’s just files)
Obsidian	People who want linking and graph views	.md files (local)	Excellent (local files)
Logseq	People who think in outlines and want block-level references	.md files (local)	Excellent (local files)
A private GitHub repo	People who want version history and search	.md files	Good (git-based)
Apple Notes / Google Keep	People who want zero setup	Proprietary	Limited but adequate
A blog (Hugo, Astro, Jekyll, etc.)	People who want public documentation	.md files	Excellent

My recommendation for engineers: plain markdown files in a git repo. You already know the tools. You already have the workflow. There is no learning curve. Create a folder, create a file, write in it, commit. Done.

The system that gets used beats the system that’s theoretically superior. If the tool you pick creates enough friction that you stop writing, switch to something simpler. The tool is the least important part of this entire practice. The writing is what matters.

IX. A practical system that takes 15 minutes a day

Alright. You’re sold (or at least willing to try). Here’s a concrete system.

The daily practice (10-15 minutes):

At the end of each workday, open your work log file and write three things:

## 2026-02-14

**Did:** Debugged the WebSocket reconnection issue. Root cause was the
server sending a close frame before the client acknowledged the previous
message. Fixed by adding an acknowledgment check before initiating close.

**Decided:** Going with Postgres for the new service instead of DynamoDB.
Need ad-hoc queries and the data model is relational. Accepted the
tradeoff of managing schema migrations manually.

**Learned:** `git stash --include-untracked` also stashes new files,
not just modified tracked files. Been losing new files to stash for months.

That’s it. What you did, what you decided, what you learned. Takes 10 minutes. Some days the “decided” or “learned” sections will be empty. That’s fine. Some days all three will be long. That’s fine too. The format is flexible. The habit is not.

The weekly practice (15-20 minutes, Friday afternoon):

Skim the week’s daily entries and write a short weekly summary. What was the main thing you worked on? What progress was made? What’s still open? This takes 15 minutes and produces a document that’s invaluable for performance reviews, status updates, and remembering what you did three months ago.

## Week of 2026-02-10

Shipped the WebSocket reliability improvements. Reconnection now handles
server-initiated disconnects gracefully. Latency p99 dropped from 340ms
to 210ms after the connection pooling change.

Open: Still need to figure out the authentication token refresh race
condition. Parked it for next week.

The project practice (30-60 minutes, at project completion):

When you finish a meaningful project, write a short retrospective within one week. What was the goal? What approach did you take? What worked? What would you do differently? What did you learn?

This is the highest-value documentation you can produce, and it’s the one most people skip because “the project is done, let’s move on.” The project retrospective is where the compound interest kicks in hardest. Three years from now, when you face a similar problem, this document is worth more than the code you wrote.

The ongoing practice (2 minutes, whenever you learn something):

TIL entries. Keep a file or a folder. When you learn something specific and useful, write it down immediately. Don’t wait. Don’t tell yourself you’ll remember. Write it now.

## TIL: CSS `text-wrap: balance`

Distributes text evenly across lines in headings.
Only works on blocks with 6 or fewer lines.
Supported in Chrome 114+ and Firefox 121+.

That’s the whole system. 15 minutes a day, 15 minutes on Friday, an hour after each project, and 2-minute TIL entries as they come up.

X. What documentation makes possible (that nothing else does)

Once you have a few months of documentation, new capabilities unlock that are impossible without it.

Grep your own career. Need to find that time you dealt with a database migration that went sideways? grep -r "migration" ~/docs/worklog/. Need to remember which project you used that specific library in? Search for it. Your documentation becomes a queryable database of your professional history.

Performance reviews write themselves. Most people stare at a blank performance review form and try to remember what they did for the last six months. With a work log, you open the file, skim the entries, and pull out the highlights. Instead of writing “I think I worked on improving reliability,” you write “Reduced WebSocket reconnection failures by 73% (from 12/day to 3.2/day) by implementing acknowledgment-based close sequences. Measured over 30 days in production.” Specifics beat impressions every time.

You become the person with the answer. In every engineering org, there’s someone who always seems to know why things were done a certain way. “Oh yeah, we tried that approach in 2024, it didn’t work because of X.” That person isn’t smarter than everyone else. They just wrote things down. Be that person.

You can teach from experience, not just theory. When you mentor someone and they hit a problem you’ve seen before, you can say “I wrote about this, let me find it” and hand them the exact context, including the dead ends and the reasoning. That’s 10x more useful than vague advice from memory.

Your writing gets better. This is the sneaky one. Documentation practice is writing practice. If you write 200 words a day in your work log, that’s 73,000 words a year. After three years, you’ve written a novel’s worth of prose. Your writing will improve whether you intend it to or not. Clarity of writing and clarity of thinking feed each other. The documentation habit trains both.

LLMs become dramatically more useful. This one is specific to right now, to 2026. If you have a personal corpus of your own writing, your own decisions, your own learning notes, you can feed that to an LLM and get personalized assistance that’s impossible without it. “Given my notes on the authentication architecture from January, help me evaluate this new approach.” The LLM can work with your context instead of generic knowledge. Your documentation becomes training data for your own personal AI assistant.

XI. The counterarguments, and why they’re mostly wrong

“What about privacy?”

Valid concern, easily addressed. Don’t publish things you want to keep private. The default should be private documentation in a system you control (local files, encrypted backup, private repo). You choose what to make public, if anything. The argument that documentation is risky because someone might see it is like the argument that saving money is risky because someone might steal your wallet. Yes, take basic precautions. No, that’s not a reason to stop saving.

“Documentation creates a false record. I might write down something incorrect and then trust it later.”

This is actually the strongest objection, and it deserves a real response. Yes, your documentation might contain errors. But memory contains more errors, and you can’t go back and check memory against reality. A written record at least gives you something to audit, question, and correct. Memory gives you a false sense of certainty about information that’s been silently degraded.

The mitigation is simple: date everything, note your confidence level when it matters, and update entries when you discover you were wrong. A corrected document is infinitely more useful than an uncorrected memory.

“This is over-optimization. Not everything needs to be recorded.”

Correct. Not everything needs to be recorded. But way more needs to be recorded than most people think. The cost of recording something you’ll never need again is a few minutes of writing. The cost of not recording something you’ll need later is hours of re-derivation, or worse, making the same mistake again because you forgot you already learned better.

The failure mode of over-documenting is wasted minutes. The failure mode of under-documenting is wasted days. The asymmetry is massive.

“This turns life into a performance.”

Only if you’re documenting for an audience. If you’re documenting for yourself, in a private system, there’s no performance. There’s no audience to perform for. This objection conflates documentation with content creation (again). They’re not the same thing.

“I tried journaling once and stopped after two weeks.”

Journaling is a specific, emotionally-oriented practice that doesn’t resonate with everyone. Documentation is broader and more utilitarian. If journaling didn’t stick, try work logs. If work logs feel tedious, try TIL entries. If TIL entries feel too small, try project retrospectives. The practice has to match your personality and your work. But “I tried one specific form of documentation and it didn’t work” is not evidence that documentation as a category doesn’t work.

XII. Start today. Not tomorrow. Today.

Here’s what I want you to do right now. Not after you finish reading this. Not after you’ve evaluated twelve tools. Not after you’ve designed the perfect system. Right now.

Open a text file. Name it worklog.md. Write today’s date. Write one sentence about what you worked on today. Save it.

That’s it. That’s the whole first step.

## 2026-02-14

Worked on the checkout flow redesign. Spent most of the afternoon
debugging a state management issue where the cart was clearing
itself on page navigation.

Tomorrow, open the same file. Add another entry. The day after, another. Don’t worry about organization. Don’t worry about tags. Don’t worry about whether you should use Obsidian or Logseq or Notion. Just write, in a file, what you did and what you learned.

After a week, you’ll have seven entries. You’ll look at them and think “huh, that’s a useful record.” After a month, you’ll search the file for the first time and find something you’d already half-forgotten. After three months, you’ll start relying on it. After a year, you’ll wonder how you ever functioned without it.

The best time to start documenting your life was ten years ago. The second best time is today.

Every day you wait is another day of experience, learning, and thinking that gets fed into the exponential decay function of human memory and never comes back. The cure costs 15 minutes a day. The disease costs you everything you’ve ever learned and done, slowly, silently, permanently.

Start the file. Write the entry. Begin.