Somewhere along my developer journey, I’d grown accustomed to complex configurations - tweaking endless dotfiles, maintaining elaborate setups. The allure of infinite customization is powerful; there’s something seductive about having hundreds of configuration options at your fingertips. But unless you’re dedicating yourself to writing plugins or becoming a tool maintainer, that power can become a burden. Your carefully crafted configurations become delicate sculptures, requiring significant maintenance without delivering proportional value.
Some background
A bit over a year ago I switched from using VS Code as my main editor to NeoVim. For multiple reasons I wanted a more terminal- and keyboard-oriented editing experience when coding and writing in general. Back then, I picked NeoVim since it seemed to be the most modern variant of Vi/Vim, and well established.
It took a few days calendar time (several hours) to get something working reasonably well, which also included setting up tmux and using WezTerm as terminal software. Over the past year I’ve changed and tweaked my settings and plugins a couple of times, but frankly with a bit of hesitation.
Then Ghostty, a nice new terminal software, released version 1.0 in December and I tried it out. The experience reminded my of something crucial, tools can be powerful and easy to configure at the same time. This rediscovery of elegant simplicity has been transformative.
A new editor - Helix
When I listened to the Changelog & Friends podcast, guest Matthew Sanabria had a post about tools worth changing to in 2025. It led me to Helix, offering the modal editing power I loved in NeoVim but with streamlined configuration.
Helix has somewhat similar key bindings to Vim/NeoVim, but also have some significant differences in that a selection is always made first, then an operation on that selection. This is not the case with Vim/NeoVim. This difference would have made the editor a turn-off probably, but the simple configuration and the “batteries included” approach for the editor attracted me after my good experience with Ghostty.
Now I am glad that I did give it a shot.
Not only is the configuration much simpler, it does have a lot of the features I used plugins to get with NeoVim. In fact, it also has a few things I that I would have added to NeoVim, if I had been motivated enough to juggle the config setup. But I wasn’t.
The differences in editing key strokes also grows on me, and I must say I am starting to prefer the logic and design behind the key bindings in Helix to NeoVim. If you are new to modal editors, Helix is easier to learn than Vim/NeoVim in my opinion.
For those that are regular users of Vim/NeoVim you will need to unlearn some Vim habits.
There are a couple of videos on YouTube presenting Helix, one of the better ones in my opinion is this one from NeoVimConf 2022.
Helix has many language server protocol (LSP) integrations already built-in, it just need an external executable installed for many of them. You can see the status of language server configurations by running the command hx --health. In case you need some additional setup done in the configuration, you can find information in the Helix Wiki for language server configurations.
I looked at a few introduction videos to Helix, and I think this one from NeoVimConf (!) is one of the better, especially if you are also familiar with NeoVim.
Infrastructure as code - simple?
On the side I am writing some books about infrastructure as code (IaC), initially for AWS Cloud Development Kit (AWS CDK), and later for Pulumi. I’ve used AWS CDK quite a bit over the past couple of years, not as much with Pulumi yet.
I find AWS CDK a bit deceptive when it comes to simplicity. On the surface, it looks like it can be potentially quite simple to set up infrastructure with it. In some cases, it is that as well - and much simpler than for example struggling with CloudFormation. There is a sweetspot for AWS CDK in my opinion if three criteria are matched:
- you are developer-oriented
- You have some decent knowledge of cloud infrastructure
- your model of your infrastructure matches what the AWS CDK developers envisioned.
If you are in that sweetspot, AWS CDK can work well for you. But it is also quite easy to get lost in growing complexity, if you are not in that sweetspot.
I hope to be able to navigate that space somewhat in the book, so it becomes a useful starting point for infrasatructure-as-code adventures with AWS CDK.
Language learning
While exploring these technical tools and infrastructure patterns, I’ve also been pursuing another kind of learning journey. Much like how finding the right balance between power and simplicity has improved my development workflow, I’ve discovered similar principles apply to language learning. Just as AWS CDK works best when you’re in its ‘sweet spot,’ finding the right approach and motivation has been key to my progress in learning new languages.
About a month ago, I wrote about planned efforts for learning Arabic and Esperanto. One month in, I managed to meet my goals for January, to varying degrees.
Starting in February, I will focus on Arabic though, pausing efforts for Esperanto. My motivation is higher for Arabic, and the routines for learning can have better focus with just that language. Arabic is perhaps one of the more challenging languages to learn, but I do think I’ve a reasonably good process for that currently.
Esperanto has simple grammar in comparison to other languages, and many cognates (words which are similar to other languages). Perhaps too simple, because I found that a lot of course material jump quite early in to teach grammar in a systematic fashion, too systematic. Learning other languages is about communication primarily, not learning rules - even if they are relatively easy.
What do I want to say with this? Motivation and good processes or ways of working can still work wonders with more complex tasks.
Stay motivated and find or make good ways of working, and you can do wonders!