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.
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.
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.
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.
My approach to bullet journaling is brutal simplicity: I don't use colors except to mark an error. 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
- 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 prodis too vague of a task description. For example, I would break this into several smaller tasks,
Troubleshoot prod bugand
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 foodor
Walk the dog
- If more than 5 tasks belong to a single project, pull them into their own project tracker.
- Zero-index numbered lists. E.g. 0. First item 1. Second item. 2. Third item.
- Mark sub-sections with dots and numbers. E.g. 0. Top Section. 0.0 First Sub Section. 0.1 Second Sub Section
-as a list item, as it is a reserved key in the bullet system. Use dots instead.
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.
- 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.
0.8 Mistakes and Edits
- Red ink is strictly for error correction.
- Cross out errors with a single line. Make any necessary corrections or updates with red ink.
- 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.
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.
- Durations should be listed for each project that have a deadline.
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 durations listed in days with a stated deadline.
- 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.
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.
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.
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.
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.
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.
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.
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.