Keep perfecting your config

Make your tools work better for you.

First of all, I wanted to extend a huge and heartfelt thank you to all of the people who bought Logic for Programmers. Seeing the interest is incredible motivation to continue improving it. If you read it and have feedback, please share it with me!

Second, I have a new blogpost out: Toolbox Languages. It's about five obscure languages I use that make certain hard problems I have much easier. I hope it encourages other people to talk about their toolbox languages (or share new ones with me!). Patreon blog notes (and the cut sixth language) here.

Third, actual newsletter.

Keep perfecting your config

Last week I read the article stop perfecting your config, which argues that people spend too much time tinkering with "editors, IDEs, terminals [and] other applications". I firmly believe the opposite, that people should spend more time tinkering. To be fair, the OP says

Before I continue, let’s make one thing clear. By no means am I saying that there is something wrong with trying to master your tools or attempting to adjust them to suit your specific needs. It’s actually the opposite.

So I read this more as "don't make my mistakes" than "don't do what I don't like."¹ At the same time, it's notable are "his mistakes"— what he counted as perfecting his configs. Reading the article, he mentions Neovim keymaps once, plugins once, and color schemes four times.

There's an idea in programming language design called Wadler's Law, which is that the majority of discussion is on syntax and not semantics. I imagine this applies to configuration too: the majority of time spent "tinkering" is on layout and coloring and not on changes to the tool's behavior. This is a trap. You get the most value of "configuration" when you use it to improve your workflow.

Here's a Neovim script I wrote a while back:

function LoadLocal(local_task)
  vim.b.local_task = local_task
end

function RunLocal()
  vim.cmd(vim.b.local_task)
end

vim.cmd [[command! -nargs=1 LoadLocal call v:lua.LoadLocal(<f-args>)]]
vim.keymap.set('n', 'gxl', RunLocal, {desc="Buffer Task"})

On calling :LoadLocal foo it loads foo as the local command for that specific buffer. Then, typing gxl executes foo. The command can be anything, up to and including shelling out to !rm *.

Oh, also any other script can set vim.b.local_task.² LoadLocal can be used by the rest of my configs. When I open an XML file it sets the local task to the appropriate transformation script.

Those eight lines have probably saved me at least eight hours of drudgework over their lifespan. The full taskrunner has saved even more. That's the kind of customization that's most useful.

Anything that goes for an IDE goes double for the shell. I use a ton of shell scripts.

Customization teaches you

A common argument against customization is that you shouldn't do it until you know the tooling basics well. For example, you shouldn't install a filetree plugin for neovim because it comes with Netrw. In other words, there's a difference between the skill of using your tools and the skill of customizing them, and the first is more important than the second.

But just as often customization promotes mastery, by smoothing out the starting friction with using a feature. Say you're trying to get more comfortable with vim macros. Here's a keymapping that could help:

vim.keymap.set('n', "<leader>Q", [[:let @q = input("Edit macro:", @q)<CR>]])

Vim macros are stored in a text registry: recording the @q macro will overwrite whatever you copied to the "q register. This means that you can treat a macro as text. input will fill a prompt with the @q macro text, let you edit it as text, and then save your changes back to the register.

This makes it so much easier to experiment with macros! If you screw up a macro while recording, you don't need to start over, you can just finish and make an edit afterwards. If you try a finished macro and it does something wrong, same thing, just undo and edit it.

Reasons not to customize

I've heard two other reasons why not to heavily customize your system:

1. It'll be harder for other people to pair with you on your machine
2. It'll be harder for you to work on machines without the customizations: servers you SSHed into, VMs, other people's computers, etc.

(1) is only a problem if you're modifying default keybindings or adding surprising new ones. I deal with it by having two editors: a heavily customized Neovim for solo work, a vanilla VSCode (plus plugins) for collaboration.

(2) is a bigger problem. I find the problem is how it messes with muscle memory. In vim I've mapped H/L to beginning/end of line when normally they mean "first/last line in view", and it always screws me up. It is so immensely frustrating. Other than that, though, I generally can tolerate losing my config for a bit. Most of the stuff that's most useful to me are things that aren't useful when I'm remoting, so I don't miss them.

One good reason not to customize that I haven't heard: There is one more reason I've heard not to customize: you can easily break stuff that you don't know how to fix. This is more true with stuff like vim and shell that allow arbitrary scripts as config, less so with VSCode or the new crop of modal editors.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.