Why the PARA method doesn't work for developers

It was eleven at night and I was staring at a Claude conversation — the one that had just generated the Postgres migration script I needed — trying to decide which of four folders it belonged in. Project? It would outlive the project. Area? I don't have a "prompting" responsibility. Resource? In what sense. Archive? It wasn't finished. I closed Notion and went back to Googling. That was the night I gave up on PARA for developer work.

The problem was not that I was using PARA wrong. The problem was that PARA was designed for a different kind of worker, doing a different kind of work, storing a different kind of knowledge. Trying to force developer artifacts through its four folders produces exactly what every developer who has tried PARA eventually produces: a graveyard of half-organized notes and a quiet return to Googling.

What is the PARA method?

PARA is an organizational framework created by Tiago Forte in 2017 as part of his Building a Second Brain methodology. It sorts every piece of information you keep into four top-level categories: Projects (efforts with a deadline and a defined outcome), Areas (ongoing responsibilities like "health" or "finances"), Resources (topics of interest and reference material), and Archives (everything inactive). The promise is that any note, any file, any document fits cleanly into one of those four buckets, and you never have to think about taxonomy again.

For a knowledge worker — writer, consultant, researcher, student — this works remarkably well. Their work is shaped like PARA. A book draft is a Project. Their running consulting engagement is an Area. The articles they're reading are Resources. Last year's finished proposals are Archive. The four buckets match the four shapes of knowledge-worker information almost perfectly.

For a developer, the four buckets match almost nothing.

Why PARA works for knowledge workers

Credit where it is due. PARA's core insight — organize by actionability, not by topic — is genuinely useful when your work is project-bounded. If every significant thing you do is a discrete deliverable with a start and an end, the "is this still active?" axis is a good way to sort. You know whether you're working on something, responsible for it, interested in it, or done with it. Four states, four folders, one decision per note.

This is why PARA gained traction in consulting, writing, and the creator economy — industries where the unit of work is a project and the unit of value is a polished output. It was never designed for people whose unit of work is a bug fix and whose unit of value is a pattern recognized across thousands of small encounters with the same underlying problem.

Why PARA doesn't work for developers

Developer knowledge doesn't have four shapes. Browse any Hacker News thread on how programmers take notes and you see it immediately: a dozen incompatible approaches, no consensus system, and one recurring line — "I haven't found a silver bullet that makes all of that feel coherent." The reason is not lack of discipline. It is that developer knowledge has at least five shapes, and none of them fit PARA cleanly.

Bug fixes. A CORS error you solved on the Stripe webhook is not a Project — it took ninety seconds. It is not an Area — "debugging" is not an ongoing responsibility in any useful sense. It is not a Resource — you didn't read about it, you solved it. And the moment you put it in Archive, you have buried it in the place you explicitly never look. The bug fix has no natural PARA home, so most developers put it nowhere, and then re-solve it six months later.

AI conversations. The Claude thread that generated the exact regex you needed, the ChatGPT exchange that finally explained how structuredClone() handles cyclic references, the Cursor session that unblocked a gnarly refactor — where do these go? They are not Projects (they outlive any single project). They are not Areas (you don't have a "prompting" responsibility). They are Resources only in the most tortured sense. PARA has no shape for them because PARA predates the problem. Building a Second Brain was written before LLMs existed. The second brain does not know what to do with a Claude conversation. So the great conversations do not get saved, and next week you are rewriting the same prompt from scratch — or worse, accepting a weaker one because you cannot remember what the good one looked like.

Code snippets. A snippet for debouncing a React hook is not project-bounded. It's not an Area. It's arguably a Resource, except that Resources in PARA are topics of interest — articles and reference reading, not fragments of code you want to reuse. Most PARA devotees end up with a Resource folder called "snippets" that becomes a write-only graveyard, because there is no structure inside the folder to support retrieval.

Tech decisions. You chose Clerk over Auth0 six months ago. Where does the reasoning live? "Why we picked Clerk" is not a Project — the decision is made. It is vaguely an Area (authentication is an ongoing concern), but filing it there loses the decisional context the moment someone else needs to understand the trade-off. It is definitely not a Resource. And the moment it goes to Archive, it is dead to you — which means the next time someone asks "why Clerk?" you will not find the answer. PARA actively punishes the one type of note developers most need to preserve.

Domain knowledge. Everything you know about "payments" or "authentication" or "the internal billing service" — the accumulated understanding of a specific technical territory — is the most valuable thing a developer can store. PARA has no home for it at all. It spans projects, crosses areas, and refuses to be archived. Domain knowledge is the point of being experienced, and PARA cannot hold it.

The category collision

Here is the underlying reason PARA fails for developer work, stated precisely.

PARA organizes knowledge on one axis: actionability over time. Is this thing active, ongoing, reference, or done? That is the only question PARA asks, and the answer determines the folder.

Developer knowledge needs two axes. The first is artifact shape — is this a bug, an AI prompt, a snippet, a decision, or a note? Each shape has its own retrieval pattern. You search for bugs by error message. You search for prompts by what you wanted to generate. You search for snippets by language and framework. You search for decisions by the technology involved. Collapsing all five into one axis destroys every one of those retrieval patterns.

The second axis is domain — what technical territory does this belong to? Authentication? Payments? The internal billing service? The e-commerce platform? Domain is the connective tissue. A bug fix in the payments domain should be reachable from the domain page, regardless of which project taught you or when you learned it.

PARA has one axis. Developer knowledge needs two. That is not a configuration problem. That is a structural mismatch. No amount of tagging, nested folders, or creative interpretation fixes it — you are trying to serialize a graph into a tree.

What developers need instead of PARA

The working version is not PARA with extra tags. It is a schema shaped around the actual artifacts developers produce, indexed by the actual questions developers ask.

Five databases, minimum:

1. Bug Solutions — indexed by symptom and technology, not by project. You will search for the error message, not the sprint.
2. AI Conversations — indexed by what you wanted to generate, tagged by tool (Claude, ChatGPT, Cursor, v0, Copilot) and category. The ones you reuse get starred.
3. Code Snippets — indexed by language and framework, with dual source tracking: where you found it and where it lives in your own codebase.
4. Tech Decisions — lightweight architecture decision records. The decision, the alternatives, the why, the date. The why is the load-bearing field.
5. Notes — atomic observations. "TIL that Promise.allSettled doesn't short-circuit on rejection" is a note. "Had a productive day" is not.

Then one connective structure:

6. Domains — the technical territories your knowledge applies to. Each domain links back to the bugs, snippets, prompts, decisions, and notes that belong to it. This is the second axis PARA lacks.

This is not a refinement of PARA. It is a different shape entirely — organized by artifact and domain, not by actionability. A bug fix in the payments domain is reachable from the Bug Solutions database (indexed by symptom) and from the Payments domain page (indexed by territory). Two retrieval paths, both cheap, both cheaper than re-Googling.

PARA vs a developer-shaped system

The cleanest way to see the difference is point by point.

Dimension	PARA	Developer-shaped system
Primary axis	Actionability — active, ongoing, reference, archived	Artifact shape — bug, snippet, prompt, decision, note
Secondary axis	None. Each folder is flat internally.	Domain — payments, authentication, billing, e-commerce
Bug fixes	No natural home. Usually lost to Archive.	First-class, indexed by symptom and technology
AI conversations	Not supported by design — predates LLMs	First-class, linked to prompt, tool, and outcome
Tech decisions	Lost in Areas or killed by Archive. The "why" evaporates.	First-class ADR format, context preserved indefinitely
Code snippets	Flat Resource folder, no retrieval structure	Indexed by language and framework, dual-sourced
Domain knowledge	Nowhere to put it. Spans all four categories.	The connective tissue — an explicit hub
Retrieval pattern	Folder browsing	Multi-axis search by symptom, domain, tool, or tech
Designed for	Knowledge workers, consultants, writers, students	Engineers shipping with AI tools in a modern stack
Origin	Tiago Forte, 2017, pre-LLM	2026 workflows with Cursor, Claude, ChatGPT, and v0

The takeaway is not that PARA is bad. It is that PARA is the right tool for a different job. Asking a developer to use PARA is like asking a carpenter to organize their tools by which client requested them, instead of by what the tool does. You can do it. You can probably make it work. But you will spend more energy fighting the system than using it, and eventually you will give up and leave your tools on the bench.

So should developers use PARA at all?

Use it for the parts of your life PARA was designed for — your calendar, your finances, your writing drafts, your non-code projects. These are knowledge-worker artifacts and PARA genuinely handles them well. There is no reason to throw the whole method out.

But do not try to file your code, your bugs, your AI chats, or your tech decisions into it. That is not the job PARA was built for. Developer knowledge has a different shape, and it needs a system that respects the shape instead of flattening it.

The replacement does not have to be complicated. Five databases plus a domain index is enough to start. The goal is not comprehensiveness. It is retrieval — a working path from "I need that thing I figured out six months ago" to "here it is, in five seconds."

I wrote more about how to build a developer knowledge base that actually works, and about why compounding your notes matters more than productivity. If you want the schema already built — nine databases, wired through relations, with thirty example entries already in the boxes — it is the system I use myself, called StackMind.

PARA was the right idea for 2017. Developer knowledge in 2026 needs a different one.