My brutalist bullet journal flow geared towards utility and productivity.

4 years ago, I discovered the bullet journal. I was in a code bootcamp at the time, and was looking for a system to organize myself while I went through the program. I dabbled with a variety of setups and flows, but it took me a while to find what I wanted to stick with.

Bullet journals stood out from everything else I had tried, though. To date, it's the only organization system I've stuck with in my life that I feel actually helps. I tried several other "productivity systems" before landing on bullet journaling, but I haven't looked back.

This post will focus on my method to bullet journaling and how I approach mine as a software engineer. What I use, what I don't use, and the style that I take with mine.

Notebook

I use a Leuchtturm 1917 Dotted. Previously I used a Rhodia Dot Web notebook. Both of them are top quality and I recommend either of them as every day notebooks, however the Leuchtturm has been my favorite.

Pens

I use Muji pens. There is always a red and a black Muji gel pen in my backpack. I used a Lamy Safari for a while but fountain pens are honestly a pain in the ass. I switched to purely just a black gel pen and haven't looked back. Ballpoint is perfectly acceptable, too. If I'm not using my Muji pens, I like a good Pilot Extra Fine G-2 or something similar.

Style Guide

This year, for the first time, I'm starting off my bullet journal with a defined style guide. I had this idea a few months ago, but I haven't had the chance to start a new notebook until now. My trusty Rhodia Web Dot book is right at the end of it's life and we're coming up on a new decade. I sat down and created the style guide that I decided I'd try for this year, based on my previous two years of experience and process. I'll post pictures of mine, but I'm also going to post the copy of my style guide here.

A Living Document

The Style Guide I'm writing intends to be a living document, amendable and updatable at any time I decide that a new rule should go in. It's meant to grow with me, and I intend to let it.

Brutal Simplicity

My approach to bullet journaling is brutal simplicity: I don't use colors, I don't have a rigid system, I don't really like keeping a strong set of ideas. The key to my bullet journaling was to use one color of pen for everything to keep it dead simple. I only ever have to have a black pen on me to start.

Since I don't use color, the shape and form of my notebook becomes much more important. I've taken a very grid-based approach to my notebooks, with lines and boxes being the preferred units of separation and organization.

I carry my bullet journal with me everywhere I go, which results in me bullet journaling almost every day without much thought. Even weekends get their own spreads and trackers depending on what I'm doing for the day.

0.1 Date Formatting

  • Prefer three letter month abbreviation and two digit day. For example, Dec. 12 format for month / day.
  • Year is optional but recommended. Dec. 12 2019
  • Use explicit four digit year. 2019

0.2 Completion

  • Bullets get crossed out with an X
  • Don't use checkboxes. They're messy.

0.3 Task Definition

  • Tasks should be small, precise, and actionable items. Fix prod is too vague of a task description. For example, I would break this into several smaller tasks, Troubleshoot prod bug and Push fixed code to staging for testing.
  • Each task description should not be longer than one line. Reword or rewrite it for clarity and brevity.
  • Descriptions should start with a verb. E.g. Buy dog food or Walk the dog
  • If more than 5 tasks belong to a single project, pull them into their own project tracker.
  • Keep your daily number of tasks fairly small and focus on finishing them. I have a place for "general chores" that fall outside of daily tasks but still need to be tracked.

0.4 Numbering

  • Zero-index numbered lists. E.g. 0. First item 1. Second item. 2. Third item. This is mostly programmer preference but I adhere to it.
  • Mark sub-sections with dots and numbers. E.g. 0. Top Section. 0.0 First Sub Section. 0.1 Second Sub Section
  • Avoid - as a list item, as it is a reserved key in the bullet system. Use dots instead. Dashes are reserved for Notes, not tasks or list items.

0.5 Formatting and Typography

  • Top level items and titles get double underlines.
  • First level headings should be in all uppercase.
  • Second level headings get no underline and are in capital case, but get a sub section number.
  • Use straight lines for separation.

0.6 Spirit

  • Prefer explicit over implicit.
  • Allocate only the space you need.
  • Use the notebook for scratch paper and ideas - it's a playground, not an academic paper.
  • Objective is better than subjective.
  • Write questions down.
  • Be deliberate or be exact.

0.7 Days of the Week

  • Short form prefers three letter abbreviations. E.g. Mon. Tue.
  • Start weeks on Mondays and end them on Sundays. Again, this is personal preference but it lets me separate the week from the weekend.

0.8 Mistakes and Edits

  • Cross out errors with a single line. Make any necessary corrections or updates with the same pen next to the striked out text.
  • The crossed out error should still be legible, but clearly marked as incorrect or out of date.
  • Mistakes are good. They mean you were doing something or learned something.
  • If it's not just a grammatical error or misspelled word, if it's an actual larger mistake - make a note about it and why it was a mistake, add context to it, draw lines to related tasks, etc... Examining our failure and mistakes is one of the best ways we grow.

0.9 Trackers and Sub Projects

  • Each tracker and sub-project should have a stated deadline for completion and a goal for the project. Even if it's incredibly obvious, writing down the goal helps you to think more clearly about each task's purpose.
  • If a list or group of items approaches 20+ items, pull it out into a sub-project or tracker.

0.10 Color and Shape

  • All items and notes should be in black ink. Blue is acceptable only if no other pen is available to you.
  • Red is strictly reserved for errors and retroactive updates. No other colors are used with any meaning in this style guide.
  • Dots are the preferred list item. Do not use dashes - since they are a reserved key in the bullet system.
  • Use boxes and lines rather than colors to visually separate.
  • Boxes are the atomic unit of organization.
  • Lines are the preferred unit of separation.
Perfection is when there is nothing else to remove.

0.11 Time and Duration

  • Projects should have duration listed in days with a stated deadline. Thinking about things in terms of days, working days, and deadlines can help you see a project's timeline more clearly and make it more real.
  • When creating project timelines, use elapsed time. It makes estimating and reasoning about time easier. E.g. T-6 days or T+2 Days. Source: Mission Elapsed Time
  • Time should be in 12 hour U.S. format. If I was feeling real fancy, I might switch to 24 hour format, but for now I'm not trying to be that guy.

Flows

There are a few different flows I use regularly in my notebook. By no means are they original, but here's how I've altered some of them to fit my process better.

War Room

This is the style of tracker I use when I'm on a tight deadline with a  large, complicated, or collaborative-heavy chunk of work to do. It has to be open ended because it will change, but it also has to be rigid enough to have a process and goal.

If the project involves more than myself, I list their names across the top of the grid as the X axis. Down the Y axis I list tasks, starting from the top and placed in the column for who they're assigned to.

When each task is completed, it gets crossed out and a new task is added to update their progress and current task.If I'm working alone, the X axis becomes the categories of work, and the Y axis is a set of tasks for that category

Key Points

  • War rooms have a stated goal at the top
  • They get their own spread
  • They should be wrapped up after they're done and notes about what occurred should be added.
  • Remember to write down your mistakes.

Gantt

I use a Gantt style chart whenever I have a project with many sub-tasks that will likely last for several months. I start with a whole spread, and then mark a deadline as T0. Timelines extend backwards from the deadline. For example, if I'm starting a month (30 days) before my deadline, T-30 would be "today", and T0 would be the deadline. I usually leave a little bit of space after T0 for delays and overdue delivery.

Each horizontal row in the chart becomes a task or project, with a start and end date drawn to match the main timeline. This is useful for visualizing what tasks remain, and how long it will take. More importantly, it makes it easier to see how a late delivery of one task will effect everything else.

I've found this makes it easier to identify bottlenecks in delivery and deployment deadlines.If a task depends on another, then an arrow gets drawn between those two tasks. This helps see the visualization of what's serial and what's parallelized.

Calendar

I refuse to draw out a calendar grid. I think it takes too much time. Instead, I just write the dates out in two columns. I make a calendar spread at the start of each month.

Below my two column calendar, I write my monthly goals and upcoming projects or deadlines. I do this once a month when I pay my bills and it's the best way to handle my monthly chores.

Subject Notes

It's common for me to devote a spread to research on a topic over a period of time. My philosophy with notes is that they help you visualize and brain-dump the information you're consuming, but they also help you to remember what you're reading much better. Studies show that you're much more likely to remember something if you write it down.

I recommend writing down keywords, underlining them, and writing down parseable bites of what you're researching or studying. If you find a new term, write it down and then go learn more specifically about that term. Write down what you find out and map it all together.

Don't hesitate to write down even obvious pieces of information. The point of notes is to help your brain and even if it seems pointless, you're processing that information at a lower level.

The best approach I've found to writing notes is to follow a Zettelkasten method with a Cornell note taking twist. I like to brain dump everything I think about a topic, key ideas, key problems, etc... and then go back and refine them into my own words later on in my Zettelkasten (I use Obsidian for this part). That's beyond the scope of this post but I'll write about that soon.

Key Points

  • Use the Cornell note-taking method for a whole spread
  • Condense it down later into your own words - that's the most important part.
  • Write down key terms, key ideas, key problems in the document while you're taking notes.
  • Keep a list of questions for yourself and answer them while you're learning and reading.

Mind Maps

When I dive into a new code base, I like to dedicate a spread to sketching out how all the pieces of the codebase work together as I dig through it. I've found this helps a lot with uncovering design flaws, reasoning about the capabilities of a given system, and understanding the code at an abstract level.

When I'm working on APIs (both programmatic and HTTP APIs) I like to draw out mind maps of how they work. They can help visually identify issues in a way that might not be apparent at the code level.

My mind maps are free-handed and often messy by necessity. I'm not trying to make a perfectly drawn out diagram of the system - I'm drawing out something as I understand it. That understanding will change and I'll update the map as I go. This part of the process can be useful for identifying problems. Asking myself "What problems did I run into when I tried this?" is a solid way to identify hotspots.

Pro Tip: Once you're done with the first draft, do it again and make it cleaner and more detailed after your first understanding of how it works. Take a picture of it, add it to your zettel or whatever other method you're using. You'll have a finished, mostly-accurate depiction of your architecture / layout / whatever you were mind-mapping at this point in time, and you'll have a much better mental model of it.

2020 Experiments

For the next year, I'm going to be trying a few new things in my bullet journal flows and tools.

I ordered a small aluminum ruler that I can keep in my journal that will aid with drawing straight lines and act as a second bookmark. If I find it becomes too much clutter, I'll take it out.

This year I want to try using more trackers, so I'm going to document some of those trackers in upcoming posts.