The Dotfile Law

Tom Golden
Tom Golden

Setting up a computer is time consuming.

When done by a human, it is also prone to errors.

Given how easy it is to install and configure programs with scripts, it is no wonder that many developers seek to solve these problems.

Stage 1) Config files

You join your first job and they hand you a shiny laptop to set up with your devtools. It takes about a day.

You think to yourself: Wait... I know how to build scripts and I could totally automate this. But I need to get right to work to impress my new employers so will have to put this on ice.

You give your best effort to make it usable for 1 day - then go home and copy all of your config files over to your new laptop.

Unsatisfied with the awkwardness of this process you create a Github repo called something like config-files.

Stage 2) Scripty boi

config-files does its job. You've spent a year or two at this job and they finally give you a promotion. You are now a big boi (or gal) developer.

But the promotion comes with more responsibilities for the same pay. You pretend to be happy for the arrangement for about 3 months before handing in your notice. Time to find a new job.

Now you have lots of free time to work on those things you said you would.

Where to start? Well - why not the config-files? Alex, one of the other engineers at work, had a cool terminal setup and you want something like that. You try and set it up and it takes you a day. You go to sleep excited about the unlimited potential of your new terminal skillz.

It's day 2 after you left your job - and you've woken up early to work on setting up a script that will set up your computer in one go.

... 2 weeks later you wake up from your coding coma with your new automation script setup. It does everything - even your vimrc (you don't even really use vim, but it does it anyway). You call it dotfiles like all the cool kids - even though yours has scripts and is cooler.

Now you're done - it's time to try the things you said you would build with your new setup.

Alas, in that time you have somehow forgotten what you were going to build. So I guess it's time to find a new job...

Stage 3) Self awareness

It's the first day of your new job and they hand you a shiny laptop to set up with your devtools. It takes about an hour, 10 mins for your script and 50 mins of company specific stuff. The IT guy pretends to be impressed.

It dawns on you that maybe - just maybe - that couple of weeks you spent on your scripts were a waste of time.

But this is too painful an idea to take. You double down. My dotfiles aren't a waste because other people could use my work. But everyone at work is already using their own dotfiles...

You post your amazing dotfiles on Github, to zero fanfare. It's understandable - you made it for your toolchain, not other folks. You generalise your script further.

You look at other dotfiles on the platform and discover that there's a whole dotfile universe out there.

Somehow, tens of thousands of people have fallen down the same trap.

The Dotfile Law

The more time a project can theoretically save you, the more time it will also cost. And there's no guarantee that those savings will outpace the costs.

Clearly, storing the config files was an efficient use of time.

And yet - creating scripts that install them isomorphically on my linux and mac systems clearly absorbs more time than it saves. In theory, having a script that automatically installs my configs regardless of the operating system is a huge time save, and a big convenience. But I've spent weeks on it now and it's time to accept a huge 'L'.

Discouraging people from trying new things to improve efficiency is not my goal with this article. Instead it is to encourage a new practice.

Before committing your time to an efficiency project spend an hour to search for other people's solutions. It almost certainly already exists.

What the UK needs

My take on where British society lies

Human Text Interaction

The most ignored area of computer science