Text Editors

Every engineer types code into something. The editor you pick — and the second editor you pick when the first one isn't available — quietly shapes the next decade of your career. This is one of the few "learn it once" lessons in software.

Analogy

Editors are like kitchen knives. Most home cooks use one good chef's knife for nearly everything. Pros keep a chef's knife AND a paring knife AND a serrated, because the right blade for a tomato is not the right blade for an onion. Trying to dice garlic with a bread knife is exactly how vim feels to a VS Code-first engineer who SSH'd into a box at 2am — possible, but slow and bleeding. The fix isn't to throw the bread knife away; it's to spend an hour learning where the handle is.

Modal vs modeless

The first thing to understand about editors is what mode you're in.

• Modeless editors (emacs, nano, VS Code, Sublime) — every keystroke does the same thing every time. a types the letter a. To save, you hold a modifier (ctrl-s, cmd-s).
• Modal editors (vi/vim/neovim, helix) — keystrokes mean different things in different modes. In normal mode, a enters insert mode after the cursor. In insert mode, a types the letter a. The same key, two completely different meanings.

Modal editing wins on keystroke economy — once you learn it, common edits are 2–3 keystrokes instead of click-drag-click-type. It loses on discoverability — you can't guess any of it; you have to be taught.

The reason senior engineers tolerate modal editors despite the learning curve: the muscle memory survives the rest of your career. Vi keybindings are everywhere — Gmail, GitHub, Less, the man-page reader, every modern IDE has a "vim mode" plugin. Learn the keys once, type them everywhere.

The vi survival kit

You will get stranded in vi at some point. A production box, a docker exec, a recovery shell. These are the keys that get you out without losing data:

i        enter insert mode
ESC      leave insert mode
:w       save
:q       quit (refuses if unsaved)
:q!      force-quit, discard changes
:wq      save and quit
u        undo

That's enough to fix a one-line typo and exit gracefully. vimtutor from any shell is a 30-minute interactive tutorial that takes you from there to genuinely productive.

Why two editors

Senior engineers almost always have two: a primary for daily work, and a secondary for everywhere the primary doesn't run.

	Primary	Secondary
Examples	VS Code, JetBrains, Neovim	vi, nano, micro
When	Local laptop	SSH'd into a remote box, container, recovery shell
Setup	Heavy — plugins, themes, language servers	None — comes pre-installed everywhere
Speed of edit	High once configured	High once learned

The secondary doesn't have to be your favourite; it has to be always there. On Unix that means vi (or nano, on a system where it's installed). When the wifi flakes mid-flight, when you're inside a 50MB distroless container, when SIP-locked Recovery Mode hands you bash and nothing else — the secondary is what survives.

Editor as IDE

Modern editors blur with IDEs. Three categories:

• Pure editors — vi, emacs, sublime. You type code; the editor doesn't know what it is.
• Editor + LSP — VS Code, Neovim with nvim-lspconfig. Syntax-aware via the Language Server Protocol; refactor, autocomplete, jump-to-definition.
• Full IDEs — IntelliJ, Visual Studio, Xcode. Bundled compilers, debuggers, profilers, project model. Heavier but tighter.

LSP is the great equaliser. Once a language has a language server (every major one now does — gopls, pyright, rust-analyzer, tsserver), you can get IDE features in any editor that speaks LSP. The gap between VS Code and a properly-configured Neovim is much smaller than it was five years ago.

Configuration as code

Whatever editor you settle on, commit your config to git. A new laptop should reproduce your exact editor in five minutes:

~/.vimrc                              vim
~/.config/nvim/init.lua               neovim
~/.emacs.d/init.el                    emacs
~/.config/Code/User/settings.json     VS Code (mac/linux)
~/Library/Application Support/Code/User/settings.json   VS Code (mac, alt path)

Keep these in a private dotfiles repo. Symlink them into place from a setup script. This is the single highest-ROI thing you can do — every minute spent configuring an editor on a fresh machine is a minute the next setup will repay.

Keybindings to internalise

Three commands, in any editor, that pay off forever:

1. Open file by name — VS Code: cmd+p. JetBrains: cmd+shift+o. vim: :e <path>. Faster than navigating the file tree, every time.
2. Command palette / fuzzy command — VS Code: cmd+shift+p. Sublime: same. emacs: M-x. Type the name of any action ("format document", "toggle wrap", "git blame") and run it.
3. Multi-cursor — VS Code: cmd+d (next match). Sublime: same. vim: visual block + insert. The single biggest "how did I live without this" feature for batch editing.

What to avoid

• Editor flame wars. Vim vs emacs vs VS Code is a religion older than most engineers. Use what makes you fast. Respect what makes others fast.
• Tweaking forever. The editor is the means, not the end. There's a phase where you spend more time configuring vim than writing code in it. That phase ends.
• Refusing to learn the second editor. "I'll never need vi" is a sentence said by people who haven't yet had to fix /etc/resolv.conf over a flaky tether at 2am.

The learn-once payoff

You will use a text editor every working day for the rest of your career. Twenty minutes a week of deliberate practice — learning one new keystroke, watching a single keybinding video, reading the man page — compounds astonishingly over years. The senior engineers you admire don't have faster fingers. They have ten years of accumulated muscle memory in a tool you also use.

Pick a primary. Pick a secondary. Commit your config. Open vimtutor and run through it once. Done.