The Dotfile Law
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
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.