Learn the Defaults: Why Portability Beats Customization

Here is how a lot of us work in 2026: a dotfiles repo with years of commits, a vim config that pulls in thirty plugins, a tmux prefix remapped to something more comfortable, a shell prompt that took a weekend to get right. The setup is yours, down to the last keybinding. On your laptop, you are fast. Muscle memory does the work and you barely think about the tools at all. That is the dream we sell ourselves, and most of the time it holds up fine.

I lived in that setup for years. I was proud of it. Then one night I SSH’d into a production server to debug something, and I was useless.

No custom mappings. No plugins. No aliases. Just vanilla vim with the default keybindings I had quietly forgotten over the years of overriding them. I sat there fumbling basic navigation, feeling like a beginner, while a real problem waited for me. The tools I had spent so long polishing were on a machine three hundred kilometres away, and they could not help me.

That night I figured out I had optimized for the wrong thing.

What Portability Actually Buys You

Picture the other version of yourself. Same skills, same brain, but you learned vim the way it ships before you ever touched a plugin. You SSH into that same server, open the same file, and nothing feels foreign. The keybindings are the ones you already know because they are the ones that were there from the start.

That person can sit down at any machine with vim installed and get to work. A colleague’s laptop during a pairing session. A locked-down client device. A minimal Docker container. A fresh VM that needs debugging right now. The tooling does not have to come with them, because the competence lives in their hands, not in a repo they need to clone first.

This is the portability over personalization idea applied to your own workflow. Owning your infrastructure means being able to operate it anywhere, not being helpless the moment you step outside your carefully built nest. A skill that only works on one machine is a dependency, and dependency on systems you cannot reproduce is a quiet vulnerability.

The Customization Trap

It is easy to fall into the customization rabbit hole. You read about someone’s amazing vim config on Reddit. You find a dotfiles repo with 3000 stars on GitHub. You think: if I add this one plugin, I will be so much more productive. And you will be. On your machine. With your config.

The cost is hidden, which is what makes it dangerous. Every default you remap without first learning it is a piece of portable knowledge you traded for a local convenience. You do not feel the loss on your own laptop. You feel it the one time it matters, at the worst possible moment, with a deadline breathing on your neck.

There is a real difference between two kinds of person. One knows the defaults and chooses to override them. The other never learned the defaults and only knows their custom setup. They look identical when everything works. They are nothing alike when you drop them onto a vanilla system.

The Defaults Are Better Than You Remember

Now picture working on a stranger’s machine and feeling fine about it. Not slower, not flailing, just working. That is what the defaults give you once you actually learn them, and they have a property no plugin can match: they are everywhere, and they have been for decades.

Vim: learn before you remap

Vim’s default keybindings are weird. No argument there. They are also well thought out and consistent across every vim install on every Unix system since the 1970s. That consistency is the whole point.

Before you remap jk to escape, learn Ctrl+[. It works in vim, in bash, in any readline-based tool. Before you install a fuzzy finder, learn :find and :edit **/*. Before you add custom text objects, master the built-in ones. You can still do all the remapping later. Do it knowing what you are giving up.

I still run plugins. I still have a few custom mappings. But I can sit down at any machine with vim and be productive immediately, because I know what vim hands me for free.

Tmux: the prefix matters less than you think

Everyone’s first tmux change is remapping the prefix from Ctrl+b to Ctrl+a. I did it too. Ctrl+b is awkward, we say. Screen used Ctrl+a, we tell ourselves.

Look at what the prefix actually is, though. You press it once, then hit another key. The awkwardness of Ctrl+b is a single keystroke you will press thousands of times until your fingers stop noticing. Meanwhile Ctrl+a collides with “go to beginning of line” in bash, a binding I reach for constantly. And every server with tmux installed uses Ctrl+b. Train yourself on Ctrl+a and you will fight the wrong prefix every time you leave home.

That last one, Ctrl+b ?, is your lifeline on any tmux install. You do not have to memorize every binding when you can pull up the whole list in one keystroke.

Shell tools: knowledge that travels

The same logic covers grep, awk, sed, find, and the rest of the Unix toolkit. I watch people install ripgrep and forget grep exists. They reach for fd and cannot remember find syntax anymore. They alias everything to the modern replacement until the original is a stranger.

The modern tools are genuinely good and I use them every day. But grep is on every Unix system. Find is everywhere. Awk and sed are preinstalled on every server you will ever touch. At 3 AM, mid-incident, you do not have time to install ripgrep. You work with what is there or you do not work at all.

# grep basics that work everywhere
grep -r "pattern" .           # recursive search
grep -l "pattern" *.log       # files containing pattern
grep -v "exclude"             # inverse match
grep -E "regex|pattern"       # extended regex

# find basics
find . -name "*.py"           # find by name
find . -mtime -1              # modified in last day
find . -type f -exec cmd {} \; # execute on results

# awk one-liners
awk '{print $2}' file         # print second column
awk -F: '{print $1}' /etc/passwd  # custom delimiter
awk 'NR==5' file              # print line 5

Ripgrep is faster. Fd has nicer syntax. Grep and find are always there. On a server you do not control, always there wins.

The Obstacle: Defaults Feel Like a Step Backward

So why does almost nobody do this? Because learning the defaults feels like going slower on purpose. You already have a config that works. Sitting down to relearn vim the boring way, on your own machine, for a payoff that only shows up on someone else’s, is a hard sell to a brain that wants results now.

There is also a sunk-cost pull. You spent real hours building those dotfiles. Admitting that some of those hours bought you a fragile local optimum stings a little. I get it. My dotfiles repo has commits going back years and I am fond of every one of them.

And honestly, most days you will be on your own machine. The whole point of building a comfortable setup is that you live in it. The portability tax only comes due occasionally, which makes it easy to keep ignoring.

Closing the Gap

You do not have to tear down your setup to fix this. The bridge is narrower than it looks.

Start by separating additions from replacements. My customizations sit on top of the defaults instead of erasing them. I do not remap Ctrl+b. I might add bindings, but the originals still fire. Color schemes, a tidy prompt, a few mappings that do not clash with anything built in: keep all of it. The line to hold is that nothing you add should make you helpless on a vanilla box. Whenever you reach to override a default, ask one question first: will this leave me stranded on a fresh system? If yes, think twice.

Then test yourself, because the gaps hide until you go looking for them:

1. SSH into a server and edit a config file in vim. No plugins, no vimrc. Can you navigate, search, replace, and save?
2. Start a vanilla tmux session. Create splits, move between them, open new windows, all with default bindings.
3. Debug something using only grep and find. No ripgrep, no fd, no aliases. Can you find what you need?
4. Write a quick awk one-liner that pulls a column out of a log file, without googling it.

Struggle with any of these and you have just found the defaults worth learning. That struggle is the signal, and it is cheap to act on now compared to discovering it live during an incident.

A few exceptions are worth naming honestly. If you have RSI or another physical limitation, remap whatever you need; your health outranks portability every time. If your whole team standardizes on one config, that config effectively becomes your default. And if you genuinely never leave your own machine, never pair, never SSH anywhere, then customize to your heart’s content. Most of us do not get that luxury.

Your dotfiles are a personal expression of how you like to work, and there is nothing wrong with that. Underneath them, though, you want a foundation of default knowledge that travels with you. Because some night you will be SSH’d into a minimal container with nothing but vanilla vim and a deadline, and the version of you that learned the defaults first is the one who walks out of that night fine. Learn the defaults, then customize on top. Doing it the other way leaves you renting your own competence from a repo you might not be able to reach.

Related: I wrote about my dotfile management setup with chezmoi and mise. Notice that even there, I keep my customizations minimal and non-destructive to default behavior.