I have a confession: I spent years perfecting my dotfiles. Custom vim mappings, tmux prefix changed to Ctrl+a, fancy shell prompts, aliases for everything. My setup was perfect. And then I SSH’d into a production server to debug an issue, and I was useless.
No custom mappings. No plugins. No aliases. Just vanilla vim with its default keybindings that I had completely forgotten. I fumbled around, couldn’t remember how to do basic navigation, and felt like a complete beginner.
That’s when I realized: I had optimized for the wrong thing.
The Customization Trap
It’s easy to fall into the customization rabbit hole. You read about someone’s amazing vim config on Reddit. You see a dotfiles repo with 3000 stars on GitHub. You think: “If I just add this plugin, I’ll be so much more productive.”
And you will be. On your machine. With your config.
But here’s the thing: you don’t always have access to your config.
- You SSH into a server that only has vanilla vim
- You pair program on a colleague’s machine
- You work on a client’s locked-down laptop
- You’re in a Docker container with minimal tooling
- You’re on a fresh VM and need to debug something NOW
In these moments, all your carefully crafted customizations are worthless. What matters is whether you can work with what’s there.
The Case for Defaults
I’m not saying you shouldn’t customize your tools. I’m saying: learn the defaults first, customize second.
There’s a crucial difference between:
- Knowing the defaults and choosing to override them
- Never learning the defaults and only knowing your custom setup
The first person can work anywhere. The second is helpless without their dotfiles.
Vim: Learn Before You Remap
Vim’s default keybindings are… weird. No question. But they’re also incredibly well thought out and consistent across every vim installation on every Unix system since the 1970s.
Before you remap jk to escape, learn to use Ctrl+[. It works everywhere — vim, bash, any readline-based tool. Before you install a fuzzy finder plugin, learn :find and :edit **/*. Before you add custom text objects, master the built-in ones.
Defaults worth knowing:
| Default | What it does | Why it matters |
|---|---|---|
Ctrl+[ | Escape | Works in every terminal, not just vim |
Ctrl+o / Ctrl+i | Jump list navigation | No plugin needed |
:!command | Run shell command | Available on any vim |
* / # | Search word under cursor | Instant, no config |
% | Jump to matching bracket | Built-in since forever |
gf | Go to file under cursor | Works out of the box |
Ctrl+a / Ctrl+x | Increment/decrement numbers | Underrated default |
I still use plugins. I still have custom mappings. But I can sit down at any machine with vim installed and be productive immediately, because I know what vim gives me for free.
Tmux: Prefix Matters Less Than You Think
Everyone’s first tmux customization: change the prefix from Ctrl+b to Ctrl+a. I did it too. “Ctrl+b is awkward,” we say. “Screen used Ctrl+a,” we justify.
But here’s the reality: the prefix is pressed once, then you hit another key. The “awkwardness” of Ctrl+b is one keystroke that you hit thousands of times and build muscle memory for. Meanwhile, Ctrl+a conflicts with “go to beginning of line” in bash — a keybinding I use constantly.
More importantly: when you SSH into a server with tmux installed, it uses Ctrl+b. If you’ve trained yourself on Ctrl+a, you’ll be constantly hitting the wrong prefix.
Defaults worth knowing:
| Default | What it does |
|---|---|
Ctrl+b % | Vertical split |
Ctrl+b " | Horizontal split |
Ctrl+b o | Cycle through panes |
Ctrl+b z | Zoom pane |
Ctrl+b [ | Copy mode |
Ctrl+b d | Detach |
Ctrl+b ? | Show all keybindings |
That last one — Ctrl+b ? — is your lifeline on any tmux installation. You don’t need to memorize everything if you can quickly look it up.
Shell Tools: Portable Knowledge
The same principle applies to grep, awk, sed, find, and the rest of the Unix toolkit.
I see people install ripgrep and forget that grep exists. They use fd and can’t remember find syntax. They alias everything to the modern alternatives.
These modern tools are great. I use them daily. But grep is on every Unix system. Find is everywhere. Awk and sed are preinstalled on every server you’ll ever SSH into.
When you’re debugging a production issue at 3 AM, you don’t have time to install ripgrep. You need to work with what’s there.
Learn these, then use alternatives:
# 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
Yes, ripgrep is faster. Yes, fd has nicer syntax. But grep and find are always there.
The 80/20 of Defaults
Here’s my practical approach: learn 80% of the defaults, customize 20%.
The defaults I always know:
- Core navigation (hjkl in vim, Ctrl+b in tmux, Ctrl+a/e in bash)
- Search and replace basics
- File operations
- Help systems (
:help,man,--help)
The things I customize:
- Color schemes (because life’s too short for ugly terminals)
- A few critical mappings that don’t override defaults
- Shell prompt (but I can work without it)
- Tool-specific settings that don’t change fundamental behavior
The key is: my customizations are additions, not replacements. I don’t remap Ctrl+b to something else — I might add new bindings, but the defaults still work.
Building Portable Muscle Memory
There’s a mental shift required here. Instead of thinking “how do I make this tool work the way I want,” think “how does this tool work, and can I live with it?”
Often, the answer is yes. Vim’s defaults are weird but learnable. Tmux’s prefix is fine once you stop fighting it. Grep’s syntax is verbose but memorable.
And when you do customize, ask yourself: “Will this make me helpless on a vanilla system?”
If the answer is yes, think twice.
When Customization Makes Sense
I’m not advocating for pure minimalism. Customization has its place:
Accessibility: If you have RSI or physical limitations, remap away. Your health matters more than portability.
Team standards: If your entire team uses the same config, that becomes your “default” for practical purposes.
Non-conflicting additions: Adding new functionality that doesn’t override existing behavior is usually safe.
Local-only workflows: If you never SSH into servers, never pair program, and always have your dotfiles — customize freely. (But most of us don’t have that luxury.)
Practical Exercises
Want to test your defaults knowledge? Try these:
SSH into a server and edit a config file with vim. No plugins, no vimrc. Can you navigate, search, replace, and save?
Start a vanilla tmux session. Create splits, navigate between them, create new windows. All with default bindings.
Debug something using only grep and find. No ripgrep, no fd, no aliases. Can you find what you’re looking for?
Write a quick awk one-liner. Extract a column from a log file. No googling.
If you struggle with any of these, that’s your signal. Those are the defaults worth learning.
Conclusion
Your dotfiles are a personal expression of how you like to work. There’s nothing wrong with that. But underneath all the customization, you should have a solid foundation of default knowledge.
Because someday you’ll be SSH’d into a minimal container, debugging a production issue, with nothing but vanilla vim and a deadline. And in that moment, knowing the defaults will save you.
Learn the defaults. Then customize. Not the other way around.
Related: I wrote about my dotfile management setup with chezmoi and mise — but notice that even there, I keep my customizations minimal and non-destructive to default behavior.