Bullet Journal

The Bullet Journal (BuJo) is often presented as a notebook-based productivity system. I find that description too narrow. Its most useful property is not task management by itself, but the deliberate cycle of capturing information, reviewing it, and deciding what still deserves attention.

I use the method as a lightweight external memory: tasks, events, notes, questions, intentions, impressions, project fragments, and reflections can all be recorded in the same chronological stream without requiring a complex application or rigid schema.

The method

The core method developed by Ryder Carroll is deliberately small. It combines:

rapid logging: short entries written as they occur;
a small set of signifiers that identify the type or state of an entry;
an index and collections for finding related material;
future, monthly, and daily logs for different time horizons;
migration: unresolved items are consciously moved, scheduled, or discarded;
regular reflection on what has been written.

The important point is that a Bullet Journal is not a pre-filled planner. The structure exists to support decisions, not to prescribe in advance what every page must contain.

Why I use it

Digital task managers are very good at storing tasks indefinitely. That is also one of their weaknesses: an item can remain in a database for months while requiring almost no conscious decision from its owner.

The Bullet Journal introduces useful friction. An unresolved item eventually has to be considered again. If it is migrated, it is rewritten or explicitly moved. If it is no longer useful, it is dropped. The cost is tiny, but it forces a decision.

Handwriting also changes the interaction. There are no notifications, badges, automatic prioritisation rules, or application state to maintain. The page is quiet. I can mix a technical note, an appointment, an idea, a question, and a task without first deciding which application or database should own each one.

I therefore do not use the BuJo as a replacement for every digital tool. Calendars, source control, searchable documentation, and automation remain better suited to many tasks. The journal is the place where attention is captured and reviewed.

Rapid logging and my key

I keep the rapid-logging vocabulary compact, but extend it beyond the minimal task/event/note distinction when a symbol makes later review clearer.

Signifier	Meaning
`•`	task
`○`	event
`^`	appointment
`/`	delegated task
`\`	task in progress
`=`	emotion, feeling, or impression
`~`	intention
`?`	question or uncertainty
`??`	confusion
`!?`	surprise or something unexpected

Task state is represented separately. A completed task is marked as completed; an abandoned task is visibly crossed out rather than silently deleted. Migration and scheduling use the usual directional notation, including > for migration and < for scheduling.

The exact symbols matter less than consistency. Their purpose is to let a page remain terse while still carrying enough semantics to be useful during review.

Logs and time horizons

My journal uses several complementary levels.

Future log

The future log holds items that belong to later months. It is deliberately coarse: its role is not to predict every day of the year, but to keep future commitments and intentions visible until the corresponding month becomes active.

Monthly log

The monthly level provides the calendar context and a place to collect tasks, intentions, events, and subjects that matter during the month. At the end of the month, unresolved material is reviewed rather than mechanically copied forward.

Weekly log and reflection

I use an explicit weekly layer. It is useful for planning at a scale larger than one day while remaining concrete enough to review what actually happened. Weekly migration also prevents the daily log from becoming a graveyard of old tasks.

Daily log

The daily log remains the least structured page. It is essentially a dated writing surface for rapid logging. I deliberately avoid productivity fields such as mandatory priorities, habit trackers, scores, or predefined categories. If something matters, it should be written because it matters, not because a template demands that a box be filled.

Migration as a decision

Migration is the part of the method I consider most important.

An unfinished task has several possible outcomes: do it, schedule it, delegate it, migrate it, or abandon it. Re-encountering the item is therefore a small review of whether it still deserves time and attention.

This is why I do not want software to migrate journal entries automatically. Automatic rollover would preserve the task while removing the decision, which is precisely the useful part of the mechanism.

Reflection

A chronological log is valuable while it is being written, but reflection turns it into something more than a record.

I use weekly, monthly, and annual reflection pages to look for unfinished work, recurring concerns, useful decisions, unexpected events, and intentions that either survived contact with reality or did not. The objective is not self-scoring. It is to regain context that is easily lost when days are treated as isolated units.

Paper, software, and the reMarkable

A paper notebook has substantial advantages: it is durable, immediate, independent of software, and requires no power. Its main limitation for my use is structural. A fixed number of physical pages makes it awkward to reserve space in advance for a full year of monthly, weekly, daily, project, and reflection material.

The reMarkable 2 preserves handwriting while allowing the journal itself to be generated as a large hyperlinked PDF. That makes it possible to prepare an entire annual structure without estimating how many sheets each section will consume.

The compromise is intentional: software generates the infrastructure, but does not perform the journaling.

Automate the journal, not the journaling.

Dates, ISO week numbers, calendars, page creation, and internal links are good automation targets. Writing, migration, abandonment, interpretation, and reflection should remain manual.

My reMarkable implementation

I maintain a free-software generator for the journal I use on the reMarkable:

The generator creates a complete year with annual, monthly, weekly, and daily views, reflections, project and collection pages, and internal PDF navigation. Its purpose is not to turn the Bullet Journal into another application. It is to remove repetitive layout work while keeping the actual method manual.

Limits

This approach is not universally better than paper or software.

A reMarkable is proprietary hardware, depends on electricity, and cannot match the long-term simplicity of a paper notebook. A PDF is also deliberately less dynamic than a database-backed application, and handwriting is less searchable than structured text.

Conversely, a conventional task manager is much better when tasks need shared state, reminders, dependencies, queries, integrations, or machine processing.

I use the Bullet Journal where its constraints are useful: personal attention, short-form capture, deliberate migration, and reflection. The fact that it does less is part of the design.