Organizing notes by topic sounds logical until you have notes on PostgreSQL in five different folders and cannot find the one that matters for today's problem.

The issue is not discipline. The issue is that topic-based organization asks the wrong question. "What is this about?" is useful for libraries. For engineers, the better question is "What am I doing with this?" That is the premise of PARA.

PARA is a simple four-bucket system created by Tiago Forte as the organizational backbone of his Building a Second Brain framework. The idea is that all information can be sorted into four categories: Projects, Areas, Resources, and Archives. Each category represents a different level of actionability, and that distinction drives where every note lives.

This guide applies PARA to engineering work specifically — codebases, documentation, learning material, and the tension between active project work and long-term reference.

The Problem With Topic-Based Organization

Most engineers organize knowledge the way they organize code: by domain.

databases/
  postgresql/
  redis/
api/
  rest/
  graphql/
devops/
  kubernetes/
  terraform/

That structure makes sense when you are browsing. It breaks down when you need something for a specific task. You remember a useful note about database migration safety, but it could be in databases/postgresql/, devops/deployments/, api/versioning/, or nowhere because you saved it somewhere temporary.

Topic folders force you to decide where knowledge belongs before you understand its context. PARA delays that decision — instead of asking what something is about, it asks what you are currently doing with it.

The Four Buckets

Projects

A project is active, time-bound work with a defined outcome.

For engineers, projects are things like:

Migrate billing service to queue v2
Upgrade PostgreSQL from 14 to 16
Write architecture decision record for auth service redesign
Implement rate limiting on public API
Publish article about distributed tracing

Every project has a completion state. When you finish, the project moves to Archives. When you are not actively working on it, it is not a project.

The key constraint: a project note should only contain what you need for that project. Reference material belongs in Resources. Reusable concepts belong in your Zettelkasten or personal notes. Project notes are working documents, not knowledge stores.

Areas

An area is an ongoing responsibility without a deadline.

For engineers, areas include:

System architecture
Infrastructure reliability
Code review quality
Professional development
API design standards
Security posture
On-call responsibilities
Mentoring

Areas do not finish. You are always responsible for infrastructure reliability. You always care about your professional development. The difference between a project and an area is that areas do not have exit criteria — they are things you maintain, not things you complete.

A useful rule: if you can imagine shipping it or closing the ticket, it is a project. If it is just part of what your role means, it is an area.

Resources

Resources are reference material you collected because it might be useful later.

For engineers:

API documentation bookmarks
Cheat sheets
Benchmark results
Architecture diagrams for third-party systems
Conference talks you want to revisit
Library documentation
Research papers
Interesting blog articles

Resources have no active home in your current work. They are collected because you expect to need them eventually. The important discipline here is that resources should not masquerade as projects. A collection of Kubernetes documentation is a resource. A running task to "learn Kubernetes for the platform migration" is a project.

Archives

Archives contain everything that is no longer active.

Items move to Archives when:

• A project is complete or cancelled
• An area of responsibility changes hands
• Resource material is too outdated to be useful
• You want to preserve something but do not need it in the active buckets

Archives are not deletion. They are low-friction storage for things that have finished their active life. The rule is simple: if you find yourself wondering whether something is in Archives, that is fine. You rarely need Archives content urgently.

PARA in Practice for Engineers

Here is a concrete example of what an engineer's PARA structure might look like in Obsidian:

Projects/
  billing-queue-migration/
  postgresql-16-upgrade/
  rate-limiting-rfc/
  blog-distributed-tracing/

Areas/
  architecture-standards/
  infrastructure/
  on-call-runbooks/
  career-development/

Resources/
  api-references/
  database-cheatsheets/
  benchmark-results/
  conference-notes/

Archives/
  2025-q4-projects/
  deprecated-services/
  old-runbooks/

The folder structure itself is not sacred. What matters is the discipline of placing notes in the right category based on their relationship to your current work.

Mapping a Typical Engineer's Knowledge

Many engineers start with an undifferentiated pile of notes. Migrating to PARA requires a single audit pass:

Projects — anything with a ticket, a deadline, or a deliverable you are currently working toward.

Areas — recurring responsibilities that define your role.

Resources — reference material you collected without a specific project in mind.

Archives — everything else.

A working rule: when in doubt, Archive it. You can always retrieve it later. An overcrowded Projects folder is more damaging than an underused Archive.

PARA and Zettelkasten: A Practical Hybrid

PARA and Zettelkasten are often compared as competing systems. They are not competing. They solve different problems.

Zettelkasten is for ideas. It captures atomic concepts, links them by meaning, and lets understanding emerge from the connections. Zettelkasten notes are not tied to projects — they belong to no active bucket. A note about idempotency applies to ten different projects, past and future.

PARA is for action. It organizes working context around what you are actively doing, responsible for, or collecting for later use.

A practical hybrid:

Projects/
  billing-queue-migration/
    migration-plan.md
    open-questions.md
    → links to Zettelkasten: [[Idempotency keys turn retries into safe operations]]
    → links to Zettelkasten: [[Outbox pattern separates persistence from delivery]]

Areas/
  architecture-standards/
    current-adr-index.md
    → links to Zettelkasten: [[Database constraints are concurrency control]]

Resources/
  benchmark-results/
    q1-2026-postgres-benchmarks.md

In this model, PARA folders hold working documents and context. Zettelkasten notes hold reusable knowledge. Project notes link to Zettelkasten concepts — the project uses the concept without owning it.

This is more durable than trying to make PARA do the job of Zettelkasten. Projects end. Concepts stay.

Common Failures

Over-Archiving

Some engineers use Archives as a dump for anything they feel guilty discarding. When Archives become large and unsorted, they lose their value. Archives should contain completed work in reasonable shape, not a graveyard of unsorted notes.

A periodic archive sweep — quarterly works well — keeps it manageable. Delete duplicates. Consolidate. Ask whether the old project note still contains anything worth keeping as a Resource or Zettelkasten note before archiving it.

Areas Becoming Dumping Grounds

When Areas grow without pruning, they start to look like a topic-based folder system. An Area called databases/ that contains unsorted notes from three years is not a responsibility — it is a pile.

Keep each Area tight. An area should represent something you are actively accountable for, not a topic you are broadly interested in. Interest goes into Resources. Accountability goes into Areas.

Resources Growing Without Review

Resources are easy to collect and easy to forget. A bookmark dump in Resources/ with 400 unsorted links is harder to use than a bookmark manager. Resources should be curated lightly — remove outdated material, keep the signal.

Skipping the Weekly Review

PARA works best with a weekly ten-minute review of your Projects folder. For each active project:

• Is this still active?
• What is the next concrete action?
• Is there anything to move to Archives?

Without that review, Projects accumulate stale entries and the system loses its value as a current view of your work.

Implementation in Obsidian

Obsidian is a natural fit for PARA because folders map directly to the four buckets and Dataview queries can surface project status automatically.

A basic setup:

vault/
  ├── Projects/
  ├── Areas/
  ├── Resources/
  ├── Archives/
  └── Zettelkasten/     ← concept notes, linked freely

A simple Dataview query to surface active project notes:

LIST FROM "Projects"
WHERE !contains(file.path, "Archives")
SORT file.mtime DESC

Tags can mark status without moving files:

tags: [project, active]
tags: [project, paused]
tags: [project, done]

When a project completes, tag it done, then move the folder to Archives/YEAR-QN/. Simple, auditable, reversible.

Implementation in Plain Files

You do not need Obsidian. PARA works equally well in a Git repository with plain Markdown:

knowledge/
  projects/
    2026-billing-migration/
      README.md
      migration-plan.md
      decisions.md
  areas/
    architecture/
      adr-index.md
  resources/
    databases/
      postgres-16-release-notes.md
  archives/
    2025/
      feature-x-launch/

Git gives you history, diff, search, and portability. That is often more than enough for a personal system.

When PARA Makes Sense

PARA is well suited when:

• You juggle multiple active projects at the same time
• You need to quickly find what relates to today's work
• You want a system that is folder-friendly and tool-agnostic
• You combine it with a Zettelkasten or concept-note layer for reusable ideas

PARA is less useful when:

• You work on a single long-running project with no clear buckets
• You are primarily doing research-oriented work with no active deliverables
• You prefer emergent structure over explicit categorization

For engineers doing a mix of active project work and long-term learning, PARA and Zettelkasten together cover most cases: PARA for context, Zettelkasten for thinking.

Decision Framework

When a new note arrives, ask these questions in order:

1. Is this tied to something I am actively working toward? → Projects
2. Is this part of an ongoing responsibility I own? → Areas
3. Is this reference material I might need later? → Resources
4. Is this finished or inactive? → Archives
5. Is this a reusable concept or idea not tied to any project? → Zettelkasten

That is the full decision tree. Five options. One rule per option. It takes about ten seconds per note.

Final Thoughts

PARA works because it matches how engineers actually use knowledge — not for browsing, but for acting. You do not open your notes to see what is in databases/. You open them because you are working on a specific problem right now, and you need the relevant material to surface quickly.

The discipline of separating active projects from reference material, and both from finished work, reduces the cognitive overhead of maintaining a personal knowledge base. In combination with a personal knowledge management foundation and a Zettelkasten for concept-level notes, PARA gives you the organizational backbone that keeps everything findable when it matters.

Start with one folder per bucket. Run one audit to sort your existing notes. Review Projects weekly. The rest will follow naturally.