const my_float: f64 = 5.5;
const my_int: u64 = my_float;
_ = my_int;
// error: fractional component prevents float value '5.5' from coercion to type 'u64'

Let's add @as and see if it helps!

const my_float: f64 = 5.5;
const my_int: u64 = @as(u64, my_float);
_ = my_int;
// error: fractional component prevents float value '5.5' from coercion to type 'u64'

Wow, it did nothing!

If we want this to work, we have to use the intFromFloat built-in.

const my_float: f64 = 5.5;
const my_int: u64 = @as(u64, @intFromFloat(my_float));
_ = my_int;
// It compiles!

Whoa! It compiles. But there's another problem.

This program has introduced a useless-use of @as. See, we added @intFromFloat but didn't remove the @as. This is a common mistake people make when first debugging Zig code. They need to do a simple cast, they try using @as, and then when it doesn't do anything, they leave it in. We can get rid of the @as and our program still compiles.

const my_float: f64 = 5.5;
const my_int: u64 = @intFromFloat(my_float);
_ = my_int;
// No error.

And this isn't specific to f64 and u64. This is true for any two types. If you get an error about incompatible types without @as, you're going to get an error with @as. (Some exceptions may apply.)

Is @as useless?

If @as doesn't cast, is it useless? No. To explain what @as does though, you need some understanding of RLS. (This is a very rough sketch of the RLS concept and in particular, result-types.)

RLS stands for Result Location Semantics. This means that (in Zig) an expression can have a Result Type.

Think of the Result Type as a property of the hole that you're going to fill with some value. In the following code, three examples of "holes" are denoted with ....

const a: usize = ...;
const b: usize = 5 + a + ... + 3;

const Side = enum { left, right };
extern myFunction(foo: Side) void;
myFunction(...);

Can you determine what the result types of these "holes" are?

Zig is smart, and so it can deduce the type of two of these result locations, but not the type of the third. Let's take them one at a time.

Example 1

const a: usize = ...;

The Result Type here is obviously usize, because that type is annotated as part of the variable declaration. The compiler knows that regardless of the type of the value or expression used here. If the expression has a different type than `usize`, then Type Coercion is performed.

https://ziglang.org/documentation/master/#Type-Coercion Type Coercion in the Zig Language Reference

Example 2

const b: usize = 5 + a + ... + 3;

In this example, the type of the "hole" is unknown.

Result Type information is optional. Most of the time, this hole will be filled with an expression that has a known type (either another comptime_int or another usize variable).

const b: usize = 5 + a + 2 + 3;

b and a are usize. 5, 2, 3 are comptime_int, and Zig can do peer-type resolution on these types, so there's no issue.

Example 3

Before getting into an example where the type of the expression is also unknown, let's look at our third example. This is the other example where Zig can determine the type of the result.

const Side = enum { left, right };
extern myFunction(foo: Side) void;
myFunction(...);

myFunction is going to be called with an instance of the Side enum, since that's the type declared in its function signature.

RLS is what allows you to write code like myFunction(.left) and have Zig know that .left is referring to the type of Side, and not some other enum with a .left feild.

What if there is no Result Type

Let's say we wanted to write code like this:

const b: usize = 5 + a + @intFromFloat(5.5) + 3;

What's the type of the expression @intFromFloat(5.5)?  @intFromFloat returns anytype. Let's look at the documentation:

Converts the integer part of a floating point number to the inferred result type.

Okay. This is the same result type we were talking about before. Zig uses this result type to determine the result integer type of @intFromFloat.

But wait. This is the second example again, where there was no result type. What does the compiler do?

const b: usize = 5 + a + @intFromFloat(5.5) + 3;
// error: @intFromFloat must have a known result type
// note: use @as to provide explicit result type

Aha! The compiler errors, and the hint? "use @as"

The real use of @as

This is why @as exists in the language. @as allows you to create a "hole" with a defined result type (without needing an intermediate variable or function call).

Our code above can be fixed by adding @as and specifying the Result Type.

const b: usize = 5 + a + @as(usize, @intFromFloat(5.5)) + 3;
// Compiles!

There are definite uses for this, like when doing math with floats and ints in a single expression. But @as is never the thing doing the casting. All it's doing is telling Zig what the Result Type of a cast should be.

How to actually cast

Zig doesn't have a single syntax for casting.

Instead it has a number of built-ins which cast between different types with different semantics. When casting from a float to an int:

• do you want to @intFromFloat?
• do you want to @bitCast?

Ultimately, these builtins give fine-grained control over casting which is less error prone and more useful than a single casting builtin. But man, wouldn't it be nice if @as actually did everything for you!

The title of this post is modeled off of "useless use of cat."

However, in order to join the club and participate in the conversation every week, you have to solve a new programming-related puzzle. Once you have, a custom Discord bot will grant you a role giving you permission to speak in channels.

At the end of the week (0:00 Sunday, UTC), everyone's role will be cleared, and all users will be locked out. A new puzzle will be posted, and everyone will have a chance to solve it.

This is meant to be a fun filter that ensures that the people participating in the conversation have some shared investment. It intentionally discourages drive-by commenters.

So far, I've been writing most of the puzzles (which means none of them are too difficult). But I have a mechanism for server members to submit puzzles as well.

Join the server and see if you can solve this week's puzzle:

https://discord.gg/5vWNUZBX

Easy Usage

I have my remote VPS configured such that I can edit files on it simply by SSHing to it and issuing sl <filepath>. This command returns instantly, placing me back at the shell, but not before opening the specified file in Sublime Text on my local computer. I can edit the file in Sublime, and when I press Save, the file changes are magically written back to the file on my server.

If the file requires root access to edit, I can still do something similar. I can run sudoedit <filepath>, which will again open and edit the file in Sublime on my computer, but it will wait for me to close the file locally before the command exits and results are written to the remote server.

These options are super easy to use for editing files if I'm already at a console on the remote machine. I can initiate the editing session on the remote computer, but then I can do my editing on my computer. This means that I have the editing experience that I'm used to, with zero latency and my Sublime configuration.

How

This is made possible because of a tool developed for TextMate called rmate. This was a companion to the mate command, which was the CLI tool for opening files in TextMate (on the same computer). You could instead run rmate on a remote computer and it would work as described above, opening the file in your local instance of TextMate for local editing.

https://macromates.com/blog/2011/mate-and-rmate/ mate and rmate, from the TextMate blog

Today, I don't use rmate on the server and I don't use TextMate on my laptop, but I can still take advantage of this workflow.

Note on terminology:
I'm going to use "server" and "server-side" to refer to my VPS, the machine I'm connecting to over SSH. This is technically the "rmate client," since it initiates the rmate connection. But I'll avoid this confusing terminology.

On the server, I use Harald Lapp's re-implementation of the rmate script in pure bash. (The original version was written in Ruby, which I don't have globally installed on my VPS.) This project's README is also an excellent reference—it has links and instructions which I drew from when writing this post.

https://github.com/aurora/rmate

On my computer, I use the Sublime Text plugin RemoteSubl, which implements the local side of the rmate connection. If you don't use Sublime Text, there are plugins for other editors like VSCode and Pulsar (the editor formerly known as Atom).

https://github.com/randy3k/RemoteSubl

I find it amusing that I’m not using the original rmate technology on the client or the server; yet, both of them think that the other one is. In this way, even though TextMate is not as relevant as it once was, its name and innovations live on.

Configuration

If you're a CLI pro, this configuration will be trivial. However, if you're a CLI pro, you probably have a method for editing remote files that you're happy with. So I'm going to walk through this slowly so that you can follow along, provided you're already familiar with SSH.

This configuration is in-depth so that, at the end of it, you'll have the best remote editing experience possible. There are simpler instructions in the repositories for the tools linked above, but I've found a little bit more configuration is required to remove the pain points and make it so that you don't have to fall back to vi.

Remote configuration

The first step is installing the rmate bash script on your remote server. Since this is a simple script, we just need to download it, mark it as executable, and make sure it is on the path. I personally place it in ~/bin and then add that directory to my path, to avoid globally installing with sudo.

mkdir -p ~/bin
curl -Lo ~/bin/rmate https://raw.githubusercontent.com/aurora/rmate/master/rmate
chmod +x ~/bin/rmate

Then we need a few simple changes to the remote .bashrc (or equivalent if you're using a different shell):

# Set PATH to include ~/bin
export PATH="$HOME/bin:$PATH"

# Set $EDITOR so other tools know what editor to use
# This should be an absolute path, not `rmate` or `~/bin/rmate`
export EDITOR="$HOME/bin/rmate -w"

# Create an alias for our use
alias sl="rmate"

The first change adds ~/bin to the PATH, as we discussed.

The second change sets $EDITOR. This is used by tools like git commit and sudoedit. sudoedit in particular is tricky to configure since it looks up the editor without your modified PATH or aliases, so it should be an absolute path to the editor executable. The -w at the end of the EDITOR tells rmate to wait until the file has been closed on your remote computer—this is the behavior that most tools expect from $EDITOR.

sudoedit is a helper provided by sudo  for editing files which require root access, without running your editor as the root user.

The third change is a simple alias so that you don't have to type rmate if you don't want to. I use sl since that's the alias I have on my local computer to open Sublime Text, and it makes for seamless transitions between the local and remote CLI.

Local Configuration

There are also a couple of things to set up locally in order for this to work.

First, you need an editor plugin, as discussed above. Check the settings for your plugin, you may need to turn it on or make sure that it's using the default rmate port (52698). However, subsequent times that you open your editor, it will start automatically and will not require further action, which is very convenient.

Second, you need to configure SSH to forward the rmate port when you connect to the remote computer. This can be done by passing an option at the command line, but this is cumbersome if you, like me, are using this as your default strategy for editing remote files.

Instead, I highly recommend creating a rule in your SSH config. On Mac, my SSH config lives in ~/.ssh/config, and the rule that I've added looks like:

# rmate forwarding
RemoteForward 52698 localhost:52698

This means that when you open an ssh connection to a remote computer, it automatically creates a connection between port 52698 on the remote and local machines which rmate can use for communication.

It's overkill to explain in this post, but you can of course configure this forwarding rule on a per-host basis, which is what I do in practice.

Conclusion

There are a couple of drawbacks to this.

• As you saw, there's a little bit of manual configuration involved.
• Your editor has to be open locally, rmate can't open the editor application on your local computer.
• There's no overwrite protection if the file you're editing with rmate is modified as you're editing it

However, these are all very minor and understandable issues.

In my experience, this workflow is much more convenient than opening the file in Vim or Nano on the remote machine, and it's a lot simpler than mounting the remote filesystem or installing VSCode remote editing tools to edit a config file. Not to mention that these solutions rarely play well with sudo.rmate is a really impressive piece of engineering from the TextMate team, and I hope that I can continue using it for a long time.

Git branches (and repositories, remotes, pull requests, etc) are not real. At least not in the way that a commit is.

What makes a commit real?

A commit is more real than these other objects in the git world for a couple of reasons:

• Commits are immutable—they cannot be edited or moved
• Commits are indestructible—they cannot be deleted
• Commits are complex—most other git objects are trivial

To understand the practical implications of these properties, it's useful to understand that a commit has a "commit hash." You've surely seen a commit hash if you've worked with Git before. You can get the hash of the current commit (the commit at HEAD) with:

git rev-parse HEAD

A commit hash uniquely identifies a commit. (In fact, the commit hash is a hash of all of the metadata in the commit, and all the files at the moment of the commit. You can't change the files or the metadata without breaking this hash.) If you have the commit hash, you can find the commit and switch to it with git switch --detach <hash> or you can read the commit information with git show <hash>.

There are obviously operations in Git that appear to violate the above "immutable" property. At a basic level, git commit --amend will let you edit a commit, and at a more advanced level, git rebase is a tool for moving commits.

However these commands are really generating new commits, based on the old ones. These new commits will have new hashes (since their data will be different) and the old commits will still exist and still be usable if you have their hashes. Here's a basic example demonstrating this:

$ git commit -m "Exampel commit" # commit with misspelling
[master 8fd3e68] Exampel commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README
$ git rev-parse HEAD
8fd3e68b316f89357cb2bec8fb783d78c6ba6f9b
$ git commit --amend -m "Example commit" # fix spelling
[master fae17a7] Example commit
 Date: Wed Jan 3 08:47:41 2024 -0500
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README
$ git rev-parse HEAD
fae17a7e41683cf4789f9ac5a7a889147a5ec2a0
$ git show 8fd3e68 --format=oneline -s # show the original unchanged commit
8fd3e68b316f89357cb2bec8fb783d78c6ba6f9b Exampel commit

What makes a Git branch not-real?

Obviously, Git branches do exist. To understand what I mean when I say that they're not as real as commits, I'd like you consider a ski slope.

This is a map of Bald Mountain. The runs, or suggested routes down the mountain, are denoted with solid lines. If you squint, it looks kind of like a Git commit tree (or some sort of directed acyclic graph).

These routes, however, are not etched into the mountain in a definitive fashion. In fact, here's an image of the mountain.

You can see the general shape of the runs, where the resort has cleared trees, but without the map you can't tell the exact route of the runs. When skiing, you're allowed to cut through thin sections of trees or zig-zag between different sections of snow. This is why I'm using a ski slope, and not a road or train track, as a metaphor. A train track exists in the real world and the train has to stay on it. There are no such tracks when skiing.

Git branches are the same way. If commits are the actual mountain, then branches are just the lines on the map.

Normally, when using Git, you stick to the branches, and your branches and your commits evolve at the same time. For example, when you make a commit, your current branch updates to point to the new commit.

$ git branch -v
* master fae17a7 Example commit
$ git commit -m "Test commit"
[master 8ea77b2] Test commit
$ git branch -v
* master 8ea77b2 Test commit

But this is not necessarily the case. We can move our branch back to the previous commit.

$ git reset --hard HEAD~ # Reset the current branch to the parent of the HEAD commit
HEAD is now at fae17a7 Example commit
$ git branch -v
* master fae17a7 Example commit
$ git show 8ea77b2 --format=oneline -s
8ea77b29c0bc56c612a0668a00b929f9d11f45fc Test commit 

As can be seen in the example, this hasn't deleted the commit. In fact, this operation hasn't changed "the mountain" at all. It's only moved the "line on the map." The commit is still there.

In fact, if we first switch to a different branch, we can delete the branch entirely, and this doesn't effect the commits.

$ git switch -c feature-branch
Switched to a new branch 'feature-branch'
$ git branch -D master
Deleted branch master (was fae17a7).

All of our commits are still there. However, since they're not all on a branch, some of them are unreachable!

What does it mean to be "on a branch"

The "on a branch" terminology is very frequently used in the Git world. This terminology confused me when I was learning Git, and it's doesn't reflect how I think about Git commits or branches today.

Saying "this commit is on the branch master" reflects a lot more about the location of the branch than it does the location of the commit. The branch is movable; the commit is not. In the ski-slope metaphor, you could say "this spot is on the run Evergreen," but that doesn't mean the spot could move to a different run.

Additionally, this phrase is confusing because a branch does not have a list of commits which are "on it." Rather, a branch stores only the single commit which is at its tip. In this sense, branches are less like runs on a ski slope, and more like points placed on the map.

Here's the best definition for this concept that I can give: a commit is "on a branch" if and only if that commit is an ancestor of the commit at the tip of the branch.

One interesting consequence of this definition is that once two branches have been merged, they have exactly the same set of commits, and it's impossible (without looking at commit messages or PR messages) to tell which commits were originally on which branches.

What happens to commits that aren't on a branch?

Commits that aren't on a branch are called "unreachable." This doesn't mean that they're completely unreachable—as we showed, if you have the commit id, you can still inspect or switch to these commits. However, they're not reachable from a branch (or other reference like a tag).

Unreachable commits include commits that have been edited with git commit --amend, commits that have been copied and superceeded by a git rebase, or commits that were left behind by branch-moving or deletion shenanigans. They exist in a sort of purgatory. They normally exist completely out of sight. And then, after 90 days, they are deleted forever by Git's garbage collection. However, they can be saved if a kind Git user (like you) makes them reachable again.

We can view the state of our Git tree with git log. However, if we want to include unreachable commits, we have to pass their commit hashes so that git log knows to look for them.

$ git log --graph 8ea77b2 8fd3e68
* commit 8ea77b29c0bc56c612a0668a00b929f9d11f45fc
| Author: Matthias Portzel <MatthiasPortzel@gmail.com>
| Date:   Sat Jan 6 14:52:08 2024 -0500
|
|     Test commit
|
* commit fae17a7e41683cf4789f9ac5a7a889147a5ec2a0 (HEAD -> feature-branch)
| Author: Matthias Portzel <MatthiasPortzel@gmail.com>
| Date:   Wed Jan 3 08:47:41 2024 -0500
|
|     Example commit
|
| * commit 8fd3e68b316f89357cb2bec8fb783d78c6ba6f9b
|/  Author: Matthias Portzel <MatthiasPortzel@gmail.com>
|   Date:   Wed Jan 3 08:47:41 2024 -0500
|
|       Exampel commit
|
* commit 530fa49f63df2382c26e5c3a7f13530568d38d12
| Author: Matthias Portzel <MatthiasPortzel@gmail.com>
| Date:   Wed Jan 3 08:44:44 2024 -0500
|
|     Example commit 1
|
* commit 1160ba1470ab0496293a1db0e7abee4c74863337
  Author: Matthias Portzel <MatthiasPortzel@gmail.com>
  Date:   Wed Jan 3 08:44:33 2024 -0500

      Test commit 1

In this commit tree, you can see two unreachable commits, 8ea77b2 and 8fd3e68. fae17a7 and its three generations of parents are reachable because they exist on the feature-branch branch.

Let's finish this post by "saving" commit 8ea77b2 from its unreachable state. We just have to create a new branch at that commit.

$ git branch master 8ea77b2

Simple.

Hopefully this post gave you a better understanding of how to think about commits and branches; and hopefully this framework makes it easier to understand potentially confusing Git operations like rebase, merge, and more.

However, my Brew workflow looks very different from most people. In this post, I’m going to describe my workflow and then give examples of what benefits this gives me.

My package management workflow revolves around a Brewfile. This is a text file that lets me declaratively list what packages I want to be installed. Instead of imperatively issuing commands like install and uninstall, I edit this text file to include the package that I want, then run a single command that syncs my system with the text file (installing missing packages and uninstalling extra packages), as well as upgrading any out-of-date packages.

That magic command is:

alias bbic="brew update &&\
    brew bundle install --cleanup --file=~/.config/Brewfile"

• brew update connects to the brew API server to fetch the newest version of all packages.
• brew bundle, the main command, installs and upgrades the requirements listed in the Brewfile.
• Passing --cleanup removes any installed formula that aren't listed in the Brewfile.

An example excerpt from my Brewfile:

# Moreutils provides, for example, vipe
brew "moreutils"

# macOS ships with a slightly out-of-date `less`
brew "less"

# jq, a command line JSON editor
brew "jq"

# Emacs (packaged for macOS)
tap "d12frosted/emacs-plus"
brew "d12frosted/emacs-plus/emacs-plus", args: ["with-memeplex-wide-icon"]

# Sublime Text editor
cask "sublime-text"

As you can see from this example, the syntax is very simple. Other declarative package management systems (Nix, for example) require learning a new syntax and a new system. But a Brewfile is just an unordered list of Homebrew packages.

Advantage 1: Package tracking

Other than the simplicity, the other thing to notice in that example excerpt is the comments. A Brewfile allows me to sort and comment on the packages inline, instead of having to keep in my head why I installed or uninstalled something. (To uninstall, I’ll frequently just comment out the line with the package.)

This keeps my system organized, and ensures that I can keep track of every installed package and what its purpose is.

Advantage 2: Easy Software Trials

I like to be able to quickly and easily try out software, and uninstall it when I’m done. I don’t think installing software should be a commitment. If I'm trying out a software, I can just run brew install example-test-software, which installs the software like normal. But the next time I run bbic, it will cleanup by uninstalling example-test-software, since it's not listed in my Brewfile. Since I like to "trial-run" software without hassle, this "unsaved-by-default" behavior is a plus for me.

Advantage 3: Everything always up-to-date

If I want to permanently install a piece of software, I just edit ~/.config/Brewfile, add the package (and a comment explaining why I added it), and then run bbic. This installs the software, but it also updates Homebrew and upgrades any out-of-date software at the same time. This ensures that every package on my system is always up to date. (This command invokes feelings of the famous pacman -Syu that I'd grown fond of when using Arch.)

I can imagine many other workflows similar to this one, like having a Brewfile per-project and taking advantage of the ability to run a Brewfile-specific sandbox, or having "install" and "uninstall" aliases that edit the Brewfile for you. I'm just describing what works for me. Hopefully this post gets you thinking about other ways of managing packages (that don't require switching operating system).

I originally started using this method because Brew didn't provide a way to automatically remove packages that were originally installed as dependencies, which made temporarily installing software difficult. Brew now, however, offers brew autoremove.

Micromouse is a robotics competition where teams compete to create and program a small (mouse-sized) robot to solve a maze. The robot functions completely autonomously (without any remote-control) and has to navigate to the center of the maze with no prior information.

As software lead, I implemented a tweaked version of the A* search algorithm to navigate the maze, and closed loop sensor control in order to avoid crashing into walls.

We used the Teensy 3.1 as an embedded microcontroller and the Arduino platform to program the robot.

In 2023, we earned a Silver award at the National Robotics Challenge.

Source Code on GitHub

Myself and another former member of that team continued developing small autonomous robots with our entry into the APEC 2025 Micromouse contest.

This productivity system is inspired by many other approaches, but combines them together into a system that has allowed me to break out of the procrastinator’s mindset and get things done. Unlike other systems, it is not designed to maximize productivity or efficiency. Rather, it minimizes stress and anxiety, and asks relatively little of me.

My yoke is easy and my burden is light.
—Matthew 11:30

This is the description of the productivity system that I currently use. I wish that I had this document 4 years ago. It would have honestly been life-changing. I knew I needed something like this system, but none of the other systems that I tried helped me.

I’m sharing it because I think you might be interested, and it might be helpful for you. But I don’t know if it will be. I use “you should” or “you have to” several times because it is convenient. But I am not telling you to use this system.

The Procrastinator’s Failure Mode

In high school, my days were packed full of classes, homework, and extracurricular activities, with very little flexibility. In college, I had fewer extracurriculars, less time in class, and copious free time. I was utterly unprepared to make use of this time, but I didn’t realize it at first. I tried to apply the same strategies that I did in high school: wait until the last minute and try to spend as little time on things as possible. This worked fine in high school because I had so much going on. (I couldn’t have spent more time on my assignments if I had wanted to.) But my second semester Junior year, I ended with a 0.75 GPA (that’s 2 F’s, a D and a C). Something went horribly wrong.

I want this to be a post about the strategies I use now, not the particular failure mode that I ended up in. But I do need to explain why I ended up failing half my classes.

• I was smart enough to understand the concepts in my classes. While difficult, the complexity of the topics was not the source of my troubles.
• I had plenty of time. I was only taking four classes, and participating in minimal extracurriculars.

In short, my problem was simply that I couldn’t make myself spend time on it. This led to a disastrous feedback loop. See, the less time you spend on work, the more important the time that you spend is. If you’ve procrastinated, and you have two hours before the assignment is due to complete it, then that two hours is extremely important. This leads to engaging in two hours of work, which frankly, are miserable. It’s rushed, high stakes (you don’t have time to make mistakes), and high stress. The chronic procrastinator knows this, and so they are right to be extremely unwilling to sit down and face this two hours of work. So instead, they procrastinate more.

Audience

This post is applicable to a very particular type of person. High schoolers and younger, who largely have their time managed for them, are limited in how much they can mismanage their time, and thus how much this can help. Similarly, if you have a job that requires you to work defined shifts, then there’s little room to procrastinate. In fact, this approach is heavily inspired by the effectiveness of shift work.

I expect the primary audience is college students like myself, but this could also be helpful for people working from home with flexible hours.

In order for this to be effective, your work and your expectations cannot be exceptional. This system is designed to minimize stress and anxiety, and increase your enjoyment of the work as a consequence. Once this happens, it’s easy to get enough done to satisfy other people. In a college setting, what this means is that you have to be okay with getting Cs. (I found that once I implemented this system, I very rarely got below a B, but you have to be okay with Cs.) Look at it this way. Maintaining a 4.00 is stressful, and there’s no system I can give you that will make it stress-free. But a lot of procrastinators are stressed about trying not to fail. And not-failing shouldn’t be stressful. You can do it.

Four Mindset Shifts

At the end of the day, chronic procrastination isn’t a failure of an organizational system. It’s a mindset failure. While there are lots of resources for procrastinators to change their systems, few people talk about the required mindset shifts.

1. Recognize that your time is not valuable.
2. You should be comfortable enough that you can work forever.
3. Create and stick to a routine.
4. Left-align tasks.

This is the hard part. All of these mindset shifts are required. You can’t implement one of them and expect results, they all play into one another. If you think that your time is valuable, you’ll find it very hard to stick to a routine. If you’ve organized your time into a routine, you’ll be forced to left-align your tasks.

The next four sections will explain what I mean by each of these.

Recognize that your time isn’t valuable

I posit that the single biggest reason that procrastination is so hard to break out of is that this required leap is so counter-intuitive. At least for me, I tried to break out of procrastination by telling myself that my time was too valuable to be wasting procrastinating, and that I should start working right now. But as mentioned in the beginning, the procrastinator, usually, is under too much stress, not too little. Rather, I take the pressure off. It’s okay. You’re going to be okay.

And we know that God works all things together for the good of those who love Him, who are called according to His purpose.
—Romans 8:28

Procrastination, really, is a productivity system that’s concerned with spending as little time as possible on the work. What I’m about to suggest, in the later section on routine, is allocating way more time than you need to do the work. But before you can do that, you have to be okay with “wasting” your time by not perfectly scheduling everything. The procrastinator is frugal with their time, hoarding it, spending as little as possible and only when it is absolutely necessary. You should be liberal with your time, spending time doing work even when you don’t need to.

Additionally, lowering the stakes makes the work much more enjoyable. It removes the pressure and obligation from any one decision to do work.

You should be able to work forever

This is more difficult to describe than the other things discussed in this post. It’s also less important, so I’ll spend less time on it. It’s really a feeling, the feeling that you can continue at the same pace for the rest of your life.

I have a temptation to think that I just need to “push through” or “work hard for a short amount of time” but this temptation is antithetical to the system that is being described.

This is a system for pacing yourself. If you find yourself seriously struggling, that is a good opportunity to step back and reflect on why. If you’re not under time pressure, you can get help or take a break and do something easier.

Life isn’t a sprint, and it’s not even a marathon. It’s not a race at all. You can set your own goals and your own pace.

Routine is more important than getting things done

Routine is what happens when a schedule becomes habit. But you first need a schedule.

My current daily schedule (7 days a week) looks something like this:

• wake up at 7
• start working (usually on school work) at 8:30
• work until 12
• eat lunch
• resume work at 12:30
• work until 5
• relax for an hour
• eat dinner at 6
• relax until I get tired and go to bed (usually at 10)

It feels silly writing this out, because it’s not that peculiar of a schedule. However! What is unusual is my mindset. What is unusual is that I actually think about my day at this level of granularity. At 5:00 on the dot, I close my open documents, change clothes, and open YouTube. For a while I had these events in my phone calendar (“Study, 8:30—12” etc), until they became second nature.

The specifics of the times of course don’t matter, and I’m leaving out many details. For example, sometimes I’ll add a third working time block from 7-9pm for work on personal projects. What I want you to take away is merely the efficiency of the idea of large “working blocks,” without further subdivisions. I try to avoid breaking down my day any further. I never estimate the time it will take to do individual assignments or dedicate blocks of time to working on them.

In order to ensure I have enough time to get everything done, I simply allocate more time than I actually need. I don’t need to spent 8 hours a day doing work. But that is a reasonable amount of time to spend (it is an amount that I can commit to forever), based on the idealized day of 8 hours work / 8 hours at home / 8 hours sleep.

Having a distinct routine for working and taking breaks has no less than five distinct advantages: unscheduled productive time, consistent sleep, stress-free breaks, easy decision making, develop of habit. (I had to stop myself from adding more advantages. These are the main five.)

Unscheduled productive time

As explained, most weeks I can get all of my work done in less than 40 hours. What, then, do I do with the rest of the time? All of the time during one of my “working blocks,” when I’m not doing schoolwork, is spent in one of these ways.

First, I’m okay with “wasting” this time. Some of this time I spend scrolling on my phone, taking a nap, or making myself a snack. These breaks from work are relatively quick, and I’m often thinking about work, so they’re different from the hour-long “relaxation” block after work, where I’ll watch a TV show or read a book.

Second, some of this time is spent doing “miscellaneous productive things.” This includes updating my TODO-list, updating my calendar, making plans, cleaning my room, reorganizing files on my computer, etc.

Third, some of this time is spent on personal projects. If I really don’t have any school work to do and my room is spotless, then I’ll use my working time to write blog posts or code for my own projects.

Many procrastinators skip these things all together. Doing homework at the last minute is no fun, but it’s even less fun if your room is a mess and you don’t know what homework you have to do. So this time spent not doing homework is super important.

Consistent sleep

I’m a huge believer in the importance of sleep, and not just quantity of sleep, but consistency. If you wake up at the same time every time every day, and go to bed 9 hours before that, your body will learn your sleep schedule. You’ll start to feel tired at your bed time and awake in the morning.

I had nights in college where I stayed up until 5am and said hi to my roommate waking up at 5am. It’s fun. But it does lead to an effect where your body starts to fight you, and “demand” more sleep than it actually needs, because it doesn’t know when you’ll be able to sleep again.

On at least one occasion, I tried to fix my sleep schedule by going to bed early. All that happened was I slept through my alarm and slept for over 12 hours. I was very discouraged by this, but I shouldn’t have expected my sleep schedule to fix itself in a day. It takes closer to 2 weeks.

100% Stress-free, guilt-free relaxation time!

During my relaxation blocks, I straight up do not allow myself to work. This, combined with the fact that these blocks are relatively short (less than the work time and never a full day), means that I very rarely get bored or sick of playing too much Minecraft or binging too many Dropout.tv videos. It was honestly shocking to me how, after just a few days of scheduled work, I felt more passionate about my hobbies than I had before. If you stop working and immediately go eat dinner, then there’s little time for rest or recreation. During my 5pm-6pm “relax” block, I’m tired and hungry, but I’m also more likely to pick up a book and read than at any other time of the day.

Easy Decision Making

For me, the most difficult part of doing homework was always making the decision to work on it. Making that decision always felt like it took a lot of motivation and energy and commitment.

One of the advantages of having a schedule is that it allows me a level of indirection. For the procrastinator, the decision to work is a complex affair, based on the amount of work they have to do, how difficult that work is going to be, when the assignment is due, etc. In contrast, I now need one piece of information to decide whether I’m working or not, and that is the current time.

Once I’ve decided to work, I still have to decide what to work on, but having these decisions be split up is actually an advantage. It’s easy to decide to work when you don’t have to decide what you’re working on, and it’s easy to decide what to work on when you’ve already decided that you’re going to work. For the details of how I decide what to work on, see the later section on my TODO list, but remember that “cleaning my room” or other low-stress tasks are always an option.

Build Habits

There’s a line in BoJack Horseman that gets used a motivational quote. BoJack (I think that’s his name, I don’t watch the show), has given up jogging and has laid down on the ground. Another character says to him, “Every day it gets a little easier… But you gotta do it every day — that’s the hard part. But it does get easier.”

Now, in my experience, this quote isn’t true in general. Math homework is hard, and doing math homework every day doesn’t make it easier. But it is extremely true for one thing, and that is sticking to a routine. Every morning that you get out of bed and choose to get stuff done, makes doing it the next day easier. They say it takes about two weeks to build habits. After that point, your default option is to continue in the habit. That didn’t make the work easier, and honestly, the voice in my head saying “screw this, go back to bed” never went away. But my default option is now getting out of bed. It just kind of happens.

To reiterate. The amazing thing about routine is that if you make the decision 14 times, then making the decision future times happens automatically.

Now, I want to add a quick note on deviations from routine. I ascribe a very high importance to following my schedule every day. That is my number one priority. However, it is still important not to beat yourself up when you do deviate from the routine. Let’s say, as an example, that it’s my 3rd or 4th day following a new routine, and I sit down for my lunch break, and I forget to get up. I got sucked into reading Twitter, and 1pm came and went, and now it’s 3pm. Well, my first inclination is to give up on my new routine. My second inclination is to “make up” the lost time and work from 3 to 7. But both of these responses make the problem worse. The correct response is for me to work for the remainder of the time block, until 5, then relax at 5. “But Matthias,” you say, “you haven’t earned that break.” But when you’re following a routine, there’s no concept of “earning” breaks. I’m going to relax at 5 because the schedule says to, and the quicker that I can re-align with the schedule, the better.

Left-aligning tasks

When I say “left-aligned,” I mean that you start work on assignments as soon as possible, rather than as late as possible. This allows you to avoid the last-minute crunch. Additionally, it helps reduces stress, guilt, and pressure around completing, postponing, or failing to complete tasks.

The procrastinator is always working on the assignment that is due soonest. But since I have flexibility to choose what to work on, I end up working on whatever item I’m most prepared to tackle at any given time. Sometime I won’t be in the mood for writing, but would rather clean my room. Other times I’ll be physically tired, unable to stand up, but have no problem doing some writing. This keeps me from fighting my body.

I’ve re-organized my TODO-list in order to store assignments in a “left-aligned” way, which encourages my to work on them soonest-first.

A better TODO list

TODO lists are necessary to keep track of what needs to be done. However, TODO lists should not be the motivator for whether you are doing work; that is the job of a schedule.

I removed the due-dates from my TODO list, and was left with just a list of work to be done. This re-organization allows the TODO list to keep track of all available work.

This is what that looks like for me. I keep my TODO-list in a paper notebook. I start a new TODO list on a new page in the notebook every day, and then I list out everything that I should or could be working on. This includes a section for homework and as well as any chore or other tasks. The one requirement is that everything on the list must be “immediately actionable.” If I can’t start working on something immediately, then it becomes a reminder or a calendar event. (Often I create scheduled reminders simply to add something to my TODO list.)

The list is roughly sorted by importance. I check my calendar often enough that I know what assignments are due in the next few days, and these assignments end up on the top of the TODO list. But the due dates are not written down on the TODO list itself.

What this means is that if I don’t complete a task on one day, then I have to re-write it on the TODO list for the next day. This can be annoying, since some assignments will stay on the list for a while, being moved from day-to-day and being re-written many times. However, this has one big advantage: I can put things that don’t have hard deadlines in my TODO list. Things like “do laundry” or “send email” go on my TODO list. (When I was using a TODO-list app with deadlines, I would put in “Do laundry” with a to-do date of “Today.” But tomorrow that’s marked as “Overdue” with a red exclamation mark, which is stressful and not helpful.) The second advantage of forcing myself to re-write things is that I can easily re-word the task as the requirements shift. If I work on “Assignment 3” on Monday, but get stuck on question 4, when I re-write the TODO list on Tuesday, I might say “ask teacher about question 4 on Assignment 3.” On Wednesday, after asking my question, it may be “finish and submit assignment 3.” With a due-date-based list, it doesn’t make as much sense for me to edit or replace a task that’s been partially completed. On a day that doesn’t have much homework, “re-organize closet” might end up on the TODO list. But if the next day I have a lot of homework, it’s easy to omit this unimportant task when rewriting the list. Manually re-writing the list ensures that entries always make sense to work on and aren’t “stale.”

This removes the focus from “getting items completed” and shifts it to “getting work done.” My TODO list is not a list of things I have to do, it’s a list of things that I could do.

(In practice, if my TODO list hasn’t changed significantly, I won’t re-write it. But most days it does.)

Other examples of left-aligning tasks

I had asked some of my friends who were more organized than me how they kept track of things. One of them said that she has a planner/calendar that she writes assignments in. The catch? She writes them in the planner section corresponding to the date they are assigned, not when they’re due. This is nonsensical from the perspective of someone who is right-aligning tasks, but you can now recognize that this is just left-aligning tasks. Another friend of mine has a whiteboard where he keeps a list of assignments to work on. He tries to erase it regularly and re-write it from scratch to avoid stale entries. This is also a left-aligned system, since the entries aren’t sorted and he doesn’t write out the dates.

Conclusion

This article is much longer than I expected it to be. If you read all of that, congratulations! If you didn’t, let me summarize:

• Escaping procrastination is difficult because you need to be less frugal with your time, not more.
• If what you’re doing is really difficult for you, you’re probably working too hard, or not used to working at all.
• Deciding to work a structured 8 hours a day is a great way to fix the above problems. A casual 8 hours of work is better than a rushed 2 hours.
• When filling your time, work on things as soon as possible, not as late as possible. Don’t worry about when they’re due, just work on making progress on them.

Hopefully some of these ideas are helpful for you in your own life. If not, hopefully you found it an interesting insight into my life.

Often, when people evaluate Docker or make statments about "Docker," they're referring only to the Docker Engine. But most of the time, this is not a useful view to take. Most of time, the practicality of Docker comes from a combination of all four of these things.

The backend of this site has been completely written several times. Originally it used Next.js, but as I wasn't using many of Next's features, I re-wrote it with the Nano.jsx library and my own glue code. However, Summer 2023, I launched a new version of MatthiasPortzel.com based on Ghost. Having an Admin view that allowed me to edit and manage posts increased the amount that I was able to write and update the site. And by creating a wholely custom theme, I could preserve MatthiasPortzel.com's unique look.