EN 69: Dotfiles, Nix and not being techie enough

Last week, a colleague of mine showed me his dotfiles repo. The idea is to version control your many config files for things like vim, git, shell aliases, etc. so you don’t have to start from scratch and set up a new machine the way you like it—always a waste of time. Clone the repo, run some scripts to create symlinks to the files—with GNU stow for example—install common software, add fonts…and you’re done. While I’m familiar with the idea and the many repos shared online, I got a confession to make: I don’t have a dotfiles repo and manually install and configure stuff every single time. The pain of begrudgingly installing everything manually is indeed painful. Still, the pain is not enough to force me to change my ways, such is life.

No defence is needed, but I’d say that my config looks pretty bland and ordinary. I rarely use aliases, I don’t install plugins for vim or configure my terminal exhaustively. I’m boring in that way. Kitty for my terminal, zsh or fish, powerlevel9k or tide, atuin for my search history—since I’ve discovered it, thanks to Thorsten Ball’s Which command did you run 1731 days ago?, it’s become indispensable—mise for a version manager, Visual Studio Code with some plugins and a few more things I don’t remember now.

One good thing about manually setting up a new machine is that, occasionally, I try new things just to try them. I’ve been using zsh, oh-my-zsh and powerlevel9k for the longest time, but for my new job I decided to go with fish, discovered fisher and then installed tide as a powerlevel9k alternative.

After a while, I came to the conclusion that I’m usually not a developer who cares deeply about those things (customising everything to the utmost detail). Most of the time, I just want them to work, so I can actually do the more interesting stuff. Long gone are my days of extreme tinkering and customising, where building a PC from scratch, customising and scrutinising every piece of hardware was fun. I do tinker a bit sporadically, might get obsessed and lost in rabbit holes for a while in areas that pique my interest or try some new cool tools… but my tolerance threshold is typically low unless the payoff is high, the pain unbearable or the thing’s exciting. Nowadays, good UX, with sane defaults—with the choice to customise when needed—and batteries included are much more valuable to me in my workflow.

Still, from time to time, I go out of my way. I’ve been trying to learn vim for a while, and in the past weeks I’ve doubled down (the Practical Vim book is a nice one). “Why are you doing that?” a younger vim-averse Alejandro would’ve asked. Two reasons:

• I would like to learn one set of shortcuts and way of handling text that I can reuse over and over. Initially, I learned JetBrains IDE shortcuts, later on, VS Code’s, then I forgot everything, and I’m too lazy to go through the same experience again.

• It’s fun to learn a new skill and get better at it. After years of tentatively trying to learn, I just went for it, at least to get good enough for comfortable daily use.

Today was the first day I had a wow moment with Vim editing a file. In Practical Vim a few tips basically are about structuring your changes in a way that you can repeat them (with a .) and in chunks, so you can undo them. I’ve been trying to think in that way. In the file I was working on, I needed to replace a few lines, in most cases, with the same words. I could do that normally in VS Code by picking one line with the mouse, Ctrl-D a few times to select all occurrences and replace them all. This time I thought about it and found out that in Vim I could find the starting word, then ctw (change words until the w character) to replace the lines, n to repeat the last search (to the next line I need) and . to repeat my previous action, which automatically replaces the lines.

Another tech I’ve been looking at just a few days ago was Nix. It all started with the dotfiles repo. What if I could run a script and get everything set up exactly how I want it, including the programming languages and their environments, in an easy, consistent and replicable way (think about getting an entire dev environment with just one command)? That was the seed that drove me to Nix. That’s a newsletter for another day, but I’ve dedicated a few hours to learn what it is, the very basics and to attempt to get something going. Suffice to say that I failed to get something going, that while I know a tiny bit more, I yet know nothing, the batteries are not even in the continent and, when thinking about the developer experience, all I can picture is a confused John Travolta in Pulp Fiction. Nix’s promise, if materialised into the mortal realm, seems to be godly, but at what cost. I might continue to slowly digest it, out of pride or stubbornness, and report back.

Interesting links

• Just use Postgres (Ethan McCue). Interesting post with a simple advice: for a new application that needs persistent storage, just default to Postgres. I might be biased, but I would agree with the advice, just use it unless you know why you wouldn’t.

• Sonos workers shed light on why the app update went so horribly (Scharon Harding). Fascinating story. Reading it, I’m not even surprised and recognise things I’ve seen in my career, at a smaller scale, of course.

• A Practitioner's Guide to Wide Events (Jeremy Morrell). This is the kind of article I wish I’d read at the beginning of my journey with observability and adding wide events style instrumentation to services. I added it to bookmarks for future reference. Also, Jeremy recommends a few great posts about Observability.