Learning Vim is like any other skill. It takes time to build up the reps and integrate it. I’m working on it, slowly, and have managed to use it daily at work with the NeoVim plugin in Visual Studio Code.

Akin to when somebody learns a new language, and have to stop to think what they want to say or look for the right words, I stop for a second to think about the next action, how to modify the text, how to reach a certain word, or how I could’ve done the action better. The body mind connection is not smooth yet. Based on what veterans say, you get to a point where you don’t have to be conscious all the time about every little detail, it becomes natural, unconscious, and you edit text at the speed of thought.

Interestingly, the more I practice, the more I notice when I can’t use it to move around text, instead having to use the mouse or the arrow keys, or edit, and the clunkiness of it all. I wanted to jump to a word quickly, or change a block of text, but had no tools to do it efficiently. I’m not at the level where I want to have Vim everywhere, but certainly I can appreciate why somebody would want to use it if there’s heavy text editing. All in all, I’m not saying you can’t be fast without Vim, Emacs or any other tool, I was decently fast without any of them.

The allure of a tool like Vim is that it has a mental model, a language, that is made to edit text efficiently and that is consistent. When you learn the model, you can construct “phrases” and combine actions, a bit like a domain-specific language. There are a few things that irk me about the model though, like the order of “combinations”—Vim follows an action → selection model, e.g. change word, but there are times when I think selection → action (e.g. word change) makes more sense—and I wonder what a “modern” Vim would look like, without the constraints of computers in 1991. Helix, for example, looks interesting, although it has the issues of new things: lack of wide adoption.

An ethereal screen pops up before your very eyes. This is odd, you mutter, but there’s not even a trace of surprise in your body, it feels natural, welcoming even. Your eyes move to the top of the screen: “Time to reincarnate!”. The “oh” that comes out of your mouth conveys a profound realisation. A small tooltip to the right of the header floats, and opening it reveals that you have to choose a new life, selecting body characteristics and initial context, and warns that all fields are required. Clearly, good design hasn’t yet reached the celestial planes.

You press the start button, faced with a wizard like interface. You go back and forth, changing settings and seeing their impact in a summary that updates in real time. Melanin level, country of origin, wealth, education and overall health of your parents, era of birth… these are a few of the options out of many others. As each element changes, the modifiers in the summary change as well, influencing probabilities in complex ways with too many combinations to grasp. Lowering one element might increase the probabilities of bad outcomes, but increasing other elements balance them out or diminish their importance, or vice versa.

Nothing is certain, the interface guarantees, there’s randomness in the system, these are only initial conditions. Once you reincarnate, your memories will disappear. With the knowledge of your past life, you set out to choose the best possible conditions to live long and prosper.

After what seems to be an eternity, the wizard is completed. A new, better life awaits. Your finger presses the Start a new life button, and a prompt stops you, “are you sure you want to continue?”, how would you not be sure? Yes! A progress bar replaces the wizard, slowly filling up, pixel by pixel. This is taking a bit much, you think, is the bar even moving? There’s no escape or cancel buttons to press, just the progress bar turning transmutating excitement into anxiety.

“Raising the bar” is a tricky phrase. What does it mean to the person saying it? I immediately get a visceral reaction, while the context associated with it manifests in my brain. I’m going to go with what “raising the bar” means to me, my own interpretation and the way I’ve seen the phrase frequently used.

A world where, instead of the bar being raised, the floor is, that’s what I’d like to imagine. Such an idea would be more transformative, to companies and society. In fact, there’s no need to imagine a universe where raising the bar happens, we can look around and see plenty of examples. The discourse and management practice in which high performers are desirable and low performers are fired already exists, we just need to look at the vitality curve, pioneered by Jack Welch or the “up or out” approach.

Jack Welch’s idea was to fire the bottom 10%, the “C” players, which are non-producers. That way, we only have high performers, the “A” and “B” players. I’ll leave it to the reader to imagine the impact of such a system, and how it would feel as a worker. Wait, there’s more, do you remember Intuit laying off 1800 employees and labelling 1050 of them as “underperformers”? There’s a real impact of labelling a worker as a low performer, not only when they go out to the market again, but on their sense of self-worth. Jonathon Colman said it best in his reaction to the news:

Under-performing isn’t a mortal sin. It’s not a crime to punish. It can happen for many reasons that aren’t the fault of the employee: poor leadership, unclear expectations, unreasonable workloads, lack of training, conflicting incentives, bad partners…

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.

After a few more weeks than originally planned, I’m back. Starting a new job is always somewhat chaotic, and it’s taken me a full month to come back to a resemblance of a routine and sufficient energy levels. Many days in the first two weeks felt like I was completely drained, and just wanted to lay down doing nothing or go to sleep until the next day.

New people, new codebase, new technologies… The technology aspect is the easiest to tackle, dedicate some time to learning it on the job or on your own time—always preferably on the job—and you’ll pick it up. With pair or ensemble programming, it can be easier. You work with other developers side by side, benefit from their internalised knowledge of the system, and feel supported from the start without having to struggle for hours, trying to figure things out solo. There’s a benefit in the struggle, though, information about the codebase becomes easier to remember, but pairing or mobbing allows you to ease in and rely on the context and guidance of your teammates.

The perennial challenge is to get to know the people well enough—enough not to feel like an outsider—and get used to the way things are in that particular company. If there’s something I don’t find comfortable, no matter how many times I do it, is starting over and building new relationships. Every so often, it takes less time to feel comfortable and that you can lower the defences a bit or swap the mask to a more familiar one. In a way, it’s like going back to high school again. Possibly, I’ve also got better at faking it and being at peace with the discomfort. Experiencing this comes with a benefit: when I’m the one in my element, and new people join the team, I try to make them feel welcomed and supported.

How’s the learning lately? Things are moving slowly, but moving nonetheless. I’m shooting for at least half an hour of learning time in the morning. If it doesn’t work out, going over my flashcards is enough. The guiding idea is to keep dedicating some time to learn, no matter how short it is. The goal’s still to learn Rust, but instead of trying to swap between books and exercises, which worked great when I had more time, I’m sticking with 100 Exercises To Learn Rust. It’s a fantastic course to get started with the language, you learn the fundamental concepts and put them in practice via the exercises.