De PARA-methode voor engineers: kennis organiseren op basis van actie
Organiseer notities op basis van actie, niet op onderwerp.
Het indelen van notities op onderwerp lijkt logisch, totdat je notities over PostgreSQL in vijf verschillende mappen hebt en de ene die relevant is voor het probleem van vandaag, niet kunt vinden.
Het probleem is geen gebrek aan discipline. Het probleem is dat organisatie op basis van onderwerp de verkeerde vraag stelt. “Waar gaat dit over?” is handig voor bibliotheken. Voor engineers is de betere vraag: “Wat doe ik hier mee?” Dat is de premisse van PARA.
PARA is een eenvoudig viervakken-systeem gecreëerd door Tiago Forte als organisatorische ruggengraat van zijn Building a Second Brain-framework. Het idee is dat alle informatie in vier categorieën kan worden gesorteerd: Projects (Projecten), Areas (Domeinen), Resources (Bronnen) en Archives (Archief). Elke categorie vertegenwoordigt een ander niveau van uitvoerbaarheid, en dat onderscheid bepaalt waar elke notitie thuishoort.
Deze gids past PARA specifiek toe op engineer-werk — codebases, documentatie, leermateriaal en de spanning tussen actief projectwerk en lange-termijnreferenties.
Het probleem met organisatie op basis van onderwerp
De meeste engineers organiseren kennis op dezelfde manier als ze code organiseren: per domein.
databases/
postgresql/
redis/
api/
rest/
graphql/
devops/
kubernetes/
terraform/
Die structuur heeft zin als je doorheen bladert. Hij faalt wanneer je iets nodig hebt voor een specifieke taak. Je herinnert je een nuttige notitie over de veiligheid van database-migraties, maar die kan overal zitten: databases/postgresql/, devops/deployments/, api/versioning/, of nergens, omdat je hem ergens tijdelijk hebt opgeslagen.
Onderwerp-mappen dwingen je om te beslissen waar kennis thuishoort voordat je de context ervan begrijpt. PARA stelt die beslissing uit — in plaats te vragen waar iets over gaat, vraagt het wat je er momenteel mee doet.
De vier vakken
Projects (Projecten)
Een project is actief, tijdsgebonden werk met een gedefinieerd resultaat.
Voor engineers zijn projecten dingen zoals:
Facturatie-service migreren naar queue v2
PostgreSQL upgraden van 14 naar 16
Architectuur-beslisnotitie schrijven voor redesign van auth-service
Rate limiting implementeren op openbare API
Artikel publiceren over distributed tracing
Elk project heeft een voltooide staat. Als je klaar bent, gaat het project naar Archief. Als je er niet actief aan werkt, is het geen project.
De cruciale beperking: een projectnotitie mag alleen bevatten wat je nodig hebt voor dat project. Referentiemateriaal hoort in Bronnen. Herbruikbare concepten horen in je Zettelkasten of persoonlijke notities. Projectnotities zijn werkdokumentatie, geen kennisopslag.
Areas (Domeinen)
Een domein is een voortdurende verantwoordelijkheid zonder deadline.
Voor engineers omvatten domeinen:
Systeemarchitectuur
Infrastructuurbetrouwbaarheid
Code review-kwaliteit
Professionele ontwikkeling
API-ontwerpstandaarden
Beveiligingsstatus
On-call verantwoordelijkheden
Mentorschap
Domeinen raken nooit af. Je bent altijd verantwoordelijk voor infrastructuurbetrouwbaarheid. Je houdt altijd van je professionele ontwikkeling. Het verschil tussen een project en een domein is dat domeinen geen exit-criteria hebben — het zijn dingen die je onderhoudt, niet dingen die je voltooit.
Een nuttige regel: als je je kunt voorstellen dat je het kunt uitrollen of het ticket kunt sluiten, is het een project. Als het gewoon onderdeel is van wat jouw rol inhoudt, is het een domein.
Resources (Bronnen)
Bronnen zijn referentiemateriaal dat je hebt verzameld omdat het later handig kan zijn.
Voor engineers:
API-documentatie bladwijzers
Cheat sheets
Benchmarkresultaten
Architectuurschema's voor third-party systemen
Conferentiepraatjes die je wilt terugzien
Bibliotheekdocumentatie
Onderzoeksartikelen
Interessante blogartikelen
Bronnen hebben geen actieve plek in je huidige werk. Ze worden verzameld omdat je verwacht ze uiteindelijk nodig te hebben. De belangrijke discipline hier is dat bronnen zich niet moeten voordoen als projecten. Een verzameling van Kubernetes-documentatie is een bron. Een lopende taak om “Kubernetes te leren voor de platformmigratie” is een project.
Archives (Archief)
Archief bevat alles wat niet langer actief is.
Items verhuizen naar Archief wanneer:
- Een project is voltooid of geannuleerd
- Een verantwoordelijkheidsdomein van eigenaar wisselt
- Bronmateriaal te verouderd is om nog nuttig te zijn
- Je iets wilt behouden, maar het niet nodig hebt in de actieve vakken
Archief is geen verwijdering. Het is opslag met lage wrijving voor dingen die hun actieve leven hebben beëindigd. De regel is simpel: als je jezelf afvraagt of iets in Archief zit, is dat prima. Je hebt archiefcontent zelden urgent nodig.
PARA in de praktijk voor engineers
Hier is een concreet voorbeeld van hoe de PARA-structuur van een engineer er in Obsidian uitzien kan:
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/
De mapstructuur zelf is niet heilig. Wat telt, is de discipline om notities in de juiste categorie te plaatsen op basis van hun relatie tot je huidige werk.
De kennis van een typische engineer kaarten
Veel engineers beginnen met een ongedifferentieerde hoop notities. Migreren naar PARA vereist een enkele audit-pass:
Projects — alles met een ticket, een deadline, of een deliverable waarnaar je momenteel werkt.
Areas — terugkerende verantwoordelijkheden die jouw rol definiëren.
Resources — referentiemateriaal dat je hebt verzameld zonder een specifiek project op het oog.
Archives — alles anders.
Een werkende regel: bij twijfel, archiveer het. Je kunt het altijd later ophalen. Een overvolde Projects-map is schadelijker dan een onderbenut Archief.
PARA en Zettelkasten: een praktische hybride
PARA en Zettelkasten worden vaak vergeleken als concurrerende systemen. Ze concurreren niet. Ze lossen verschillende problemen op.
Zettelkasten is voor ideeën. Het vangt atomaire concepten op, linkt ze op betekenis en laat begrip ontstaan uit de verbindingen. Zettelkasten-notities zijn niet gekoppeld aan projecten — ze behoren tot geen enkel actief vak. Een notitie over idempotentie van toepassing op tien verschillende projecten, verleden en toekomst.
PARA is voor actie. Het organiseert werkcontext rondom wat je actief doet, waarvoor je verantwoordelijk bent, of wat je verzamelt voor later gebruik.
Een praktische hybride:
Projects/
billing-queue-migration/
migration-plan.md
open-questions.md
→ links naar Zettelkasten: [[Idempotentie-sleutels maken van herhalingen veilige operaties]]
→ links naar Zettelkasten: [[Outbox-patroon scheidt persistentie van levering]]
Areas/
architecture-standards/
current-adr-index.md
→ links naar Zettelkasten: [[Database-beperkingen zijn concurrency-control]]
Resources/
benchmark-results/
q1-2026-postgres-benchmarks.md
In dit model bevatten PARA-mappen werkdokumentatie en context. Zettelkasten-notities bevatten herbruikbare kennis. Projectnotities linken naar Zettelkasten-concepten — het project gebruikt het concept zonder het te bezitten.
Dit is duurzamer dan proberen PARA de rol van Zettelkasten te laten spelen. Projecten eindigen. Concepten blijven.
Veelvoorkomende falen
Overmatig archiveren
Sommige engineers gebruiken Archief als een stortplaats voor alles wat ze zich schuldig voelen weg te gooien. Wanneer Archief groot en ongeordend wordt, verliest het zijn waarde. Archief moet voltooide werk in redelijke staat bevatten, geen grafveld van ongeordende notities.
Een periodieke archiefcheck — elk kwartaal werkt goed — houdt het beheersbaar. Verwijder duplicaten. Consolidatie. Vraag je af of de oude projectnotitie nog iets bevat dat de moeite waard is om te behouden als een Bron of Zettelkasten-notitie voordat je het archiveert.
Areas die stortplaatsen worden
Wanneer Areas groeien zonder snoeien, beginnen ze eruit te zien als een onderwerp-gebaseerd mapsysteem. Een Area genaamd databases/ die ongeordende notities van drie jaar bevat, is geen verantwoordelijkheid — het is een hoop.
Houd elk Area strak. Een domein moet iets vertegenwoordigen waarvoor je actief verantwoordelijk bent, niet een onderwerp waarvoor je breed interesse hebt. Interesse gaat naar Bronnen. Verantwoordelijkheid gaat naar Areas.
Resources die groeien zonder review
Bronnen zijn makkelijk te verzamelen en makkelijk te vergeten. Een bladwijzerdump in Resources/ met 400 ongeordende links is moeilijker te gebruiken dan een bladwijzerbeheerder. Bronnen moeten licht worden gecureerd — verwijder verouderd materiaal, behoud het signaal.
Het wekelijkse review overslaan
PARA werkt het beste met een wekelijkse tien-minuten review van je Projects-map. Voor elk actief project:
- Is dit nog steeds actief?
- Wat is de volgende concrete actie?
- Is er iets dat naar Archief moet?
Zonder die review accumuleren Projects verouderde entries en verliest het systeem zijn waarde als een actueel overzicht van je werk.
Implementatie in Obsidian
Obsidian is een natuurlijke fit voor PARA omdat mappen direct corresponderen met de vier vakken en Dataview-query’s projectstatus automatisch kunnen tonen.
Een basisopstelling:
vault/
├── Projects/
├── Areas/
├── Resources/
├── Archives/
└── Zettelkasten/ ← conceptnotities, vrij gelinkt
Een eenvoudige Dataview-query om actieve projectnotities te tonen:
LIST FROM "Projects"
WHERE !contains(file.path, "Archives")
SORT file.mtime DESC
Tags kunnen status markeren zonder bestanden te verplaatsen:
tags: [project, active]
tags: [project, paused]
tags: [project, done]
Wanneer een project is voltooid, tag het als done, verplaats dan de map naar Archives/JAAR-QN/. Eenvoudig, controleerbaar, omkeerbaar.
Implementatie in platte bestanden
Je hebt Obsidian niet nodig. PARA werkt even goed in een Git-repository met platte 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 geeft je geschiedenis, diff, zoekfunctie en draagbaarheid. Dat is vaak meer dan genoeg voor een persoonlijk systeem.
Wanneer PARA zin heeft
PARA is geschikt wanneer:
- Je meerdere actieve projecten tegelijkertijd beheert
- Je snel iets moet vinden dat betrekking heeft op het werk van vandaag
- Je een systeem wilt dat map-vriendelijk is en tool-agnostisch
- Je het combineert met een Zettelkasten- of conceptnotitie-laag voor herbruikbare ideeën
PARA is minder nuttig wanneer:
- Je werkt aan één langlopend project zonder duidelijke vakken
- Je voornamelijk onderzoekswerk doet zonder actieve deliverables
- Je voorkeur hebt voor emergent structuur boven expliciete categorisering
Voor engineers die een mix doen van actief projectwerk en lange-termijn leren, dekken PARA en Zettelkasten samen de meeste gevallen: PARA voor context, Zettelkasten voor denken.
Beslisframework
Wanneer een nieuwe notitie arriveert, stel deze vragen in deze volgorde:
- Is dit gekoppeld aan iets waarnaar ik actief werk? → Projects
- Is dit onderdeel van een voortdurende verantwoordelijkheid waar ik eigenaar van ben? → Areas
- Is dit referentiemateriaal dat ik later nodig kan hebben? → Resources
- Is dit afgerond of inactief? → Archives
- Is dit een herbruikbaar concept of idee dat niet aan enig project is gekoppeld? → Zettelkasten
Dat is de volledige beslisboom. Vijf opties. Een regel per optie. Het duurt ongeveer tien seconden per notitie.
Eindgedachten
PARA werkt omdat het aansluit bij hoe engineers kennis daadwerkelijk gebruiken — niet voor browsen, maar voor actie. Je opent je notities niet om te zien wat er in databases/ zit. Je opent ze omdat je nu aan een specifiek probleem werkt, en je hebt het relevante materiaal snel nodig.
De discipline om actieve projecten te scheiden van referentiemateriaal, en beide van voltooid werk, vermindert de cognitieve overhead van het onderhouden van een persoonlijke kennisdatabase. In combinatie met een persoonlijk kennismanagement-basis en een Zettelkasten voor concept-niveau notities, geeft PARA je de organisatorische ruggengraat die alles vindbaar houdt wanneer het er toe doet.
Begin met één map per vak. Voer één audit uit om je bestaande notities te sorteren. Review Projects wekelijks. De rest volgt vanzelf.
