My Middle Way Dotfiles Strategy

This week I got to set up a new computer and reflected on how I manage my configurations. After a decade, I've found something that works for me and feel is worth sharing.

I like using the terminal, Tmux, and Vim. I like REPLs like psql, irb, iex, and node. The terminal requires configurations: you have to turn a few things on, and a few things off. We call the files that encode these configurations 'dotfiles' because they start with a ..

When I get a new computer, ideally I'd type in a single command ("engage!") and after a few moments, I'd have a development environment tailored to my exact specifications. That is not quite what happens.

Why not? First, making it perfect would be a lot of work for something that I do once every couple of years. Second, configurations are specific to the work that I plan to do next. If I'm joining a team that uses MySQL, I might not need a Postgres configuration.

And yet, I think you have to store your configurations in some way. It's suboptimal to be deciding how you want Vim to work on each new computer.

So, here's my middle way: I have a dotfiles repository on GitHub, linked below, that takes a bit of improvised setup to pull down, and once I do, I review it, adjust, and run a script. It's 90% automated.

GitHub - jwworth/dotfiles: 🗄 My local dotfiles

🗄 My local dotfiles . Contribute to jwworth/dotfiles development by creating an account on GitHub.

Here's the workflow, starting with a brand new MacOS computer.

First, I install my terminal. I use iTerm.

Next, I open the terminal and install homebrew. Homebrew gives me the programs I'll need.

Next, I authenticate with Github. This lets me pull down the dotfiles.

I change directory to my dotfiles repo and run ./bin/install. This should do two things: install packages and symbolically link dotfiles.

Installing packages is the first step. Via homebrew, I'm going to need Tmux, Ripgrep, FZF, Vim (preferred to the MacOS native version), and a couple of other packages. I don't keep this list actually checked in, but I could.

Next, I symlink the dotfiles. In my dotfiles repo, I have a configuration for each major program I care about: .zsrhrc, .vimrc, .vimbundle, .cvsignore, .tmux.conf, and .gitconfig. My script symlinks each of these to the root directory, where they're found by each program:

ln -s "$HOME"/code/dotfiles/.* "$HOME"/

With symlinks, I get a neat effect. Because the files that I'm editing are stored in my ~/code/dotfiles directory, which is versioned and stored on GitHub, any machine that has this setup will get the changes I make.

An idea I've been thinking about here is the Explore vs. Exploit Dilemma. If you've ever played an open-world computer game or read Who Moved My Cheese?, you know this dilemma: do you leave to find new opportunities or try to maximize where you are?

In the world of computer configurations, there's a lot to explore. Incredible enhancements for most of the tools I've mentioned, that can give you superpowers. And yet I've mostly exploited what I have. I don't want features that slow down my terminal, surprise me, and that I might never use. I want the configurations that I know I need, that have survived across multiple installs. And I'm willing to sacrifice a superpower or two for that simplicity.

Another strategy I'll suggest: if you want to set up a computer, switch to it completely and try to ship some code. Shut any other machines, open the new one, and start trying to change a code file. All of the things you're missing will appear.