I must have read at least a dozen books and a hundred articles on productivity over the course of my life.

After all that reading, here are the two tools I actually use to stay productive (as an engineer):

• My startup routine
• And my work journal

I can puff out my chest and tell you I used these tools most days for the last twelve months. I really do these things!

Let me show you how I use both of these tools.

My Startup Routine

At the top of my work journal, I have a checklist for my startup routine:

On the mornings I use this checklist, I feel organized and in control. But more importantly, I set myself up for success in some key ways (which I will explain soon).

By contrast, one morning I jumped straight into some on call shenanigans, and skipped my checklist. It sidelined my entire day: I ended up disorganized and less productive.

☹️

So the startup routine is important. And here’s how it goes down.

First, I arrange my tabs and windows. This bit serves a similar function to making your bed—an easy win to get your personal flywheel going for the day.

Then, I run the command `start_working` in my terminal and let it run in the background while I continue with the checklist. (`start_working` is an alias I set up to pull master, run migrations, and run some Flexport-specific commands.)

This helps me dodge an opportunity to get distracted. In the past, I would run this command only when I wanted to start coding. I’d then have to wait a few minutes for the aliased commands to finish running—the opportunity to get distracted that I avoid now.

Next, I basically review and clear my inboxes—Calendar, Slack, code reviews. I find it useful to batch code reviews a few times a day.

After I check my calendar, I schedule work sessions for the day through Focusmate, around my meetings. Focusmate is an app that lets you book hour-long work sessions with strangers, and well, I need the accountability 😂

Interestingly, since I’m using Focusmate, I’m implicitly scheduling most hours of my day, doing what our fellow productivity nut Cal Newport calls time blocking.

His reasoning:

Some people ask why I bother with such a detailed level of planning. My answer is simple: it generates a massive amount of productivity. A 40 hour time-blocked work week, I estimate, produces the same amount of output as a 60+ hour work week pursued without structure.

Moving on, the last task of my startup routine is to write down my tasks for the day.

I’ll start a new daily entry in my journal:

And then write down my tasks:

It’s important to break down big nebulous todos into small well-defined todos—“next actions”, if you want to get all GTD about it. Compare the ill-defined task “Add multi day selection to scheduled reporting” to the concrete task “Add a migration to add a days field to the report schedule model”.

Sometimes I’ll get as granular as “Check out this git branch” or “Open the UI” in my todo lists. Because later in the day, when willpower is low, it’s hard to get into big, nebulous tasks.

Like our lord and savior Sam Altman, I re-transcribe these checklists every day, instead of just copying items over.

OK. Now I’ve completed my startup routine!

I usually feel pretty good at this point, having finished the foreplay I’m excited to get into the actual work 😂

My Work Journal

My work journal is just dated entries of free form text. I don't explicitly try to enforce any structure.

But I tend do three things with my work journal: dump state, take notes, and debug code.

Dumping State

Here’s the most important thing I do in my work journal:

Before I pause work—be it for lunch, a meeting, or the end of the workday—I jot down what I was working on and what I was thinking.

The book Getting Results calls this “dumping state”, and this lets me easily re-enter the task later.

State dumps. Do them all the time.

A few examples:

Sometimes, I don’t just dump state, I also journal and take notes as I work. But only when I feel it’s necessary—when I feel I have too much information to keep in working memory.

Taking notes

When I do record my thoughts and notes, it ends up handy, since I produce a natural documentation I can revisit myself or share with others. For example, when I’m reading code in a new part of codebase, and the code is particularly complex, I’ll take notes.

One time, I took notes on how the filters in our product worked, deep diving into an older part of our codebase. This was an example where it was too much to keep it all in working memory.

Here are my notes:

Months later, I used these notes when I needed to touch this code path for a different project. And a month after that, a coworker asked how filters work, and I was able to just pass him my notes!

OK but I’ve left out the biggest use of my work journal, which is when I’m debugging code.

Debugging code

I use my work journal to debug code especially when it’s one of those issues take the better part of a day or more to debug. I talk to my journal, and treat it like the rubber duck from rubber duck programming.

Here’s an example:

I often save the commands I put into the local or production Rails console and their results, which comes in handy when reproducing an issue later.

FYI I’m head over heels for Notion because it supports syntax highlighting for code snippets 😍

In any case, if I’ve written up my train of thought in this way, I can pick up the debugging task an hour later, a day later, a week later, whatever, without much fuss. And since I can easily pick up the task again, I don’t procrastinate.

It’s also nice because if I get really stuck, I have the details of the issue written, and I can shoot a coworker my notes when asking someone for help.

(A final fringe benefit of work journals: To get ready for performance review, you can scroll through your work journal and see what you did that cycle.)

Using Notion

Previously, I used Google Docs for my internship work journals, but I switched to Notion last July. Notion is excellent here because it (1) lets you use and nest checkboxes and (2) gives you syntax highlighting and line wrapping for code snippets.

Here’s a Notion template for this. I wouldn’t recommend bullet-based editors like Roam for this. They tend to be unwieldy for checkboxes and code snippets.

Protip, if you do choose Notion, change the Notion page setting to full width. This lets you see more of any long lines of code you have.

Fin

Done writing for the morning! Now I'm going to go do my startup routine / work journal and start the work day:)

Happy coding everyone 🤗