There is a familiar phase in every engineer’s life where they spend two months configuring Vim, three weeks switching to Emacs, two months back to Vim, a week on Helix, four months on Doom Emacs, and emerge from the cycle slightly older and no more productive. I have been through that cycle. So have most of the engineers I know. The setup I describe below is what I landed on after the cycle, used for the past four years across two job changes, three operating systems, and the move from Buenos Aires to Tokyo. It is not the prettiest, the most-recommended, or the most-marketed configuration on the internet. It is the one I stopped fiddling with, which is the only real test that matters.
This essay is not a recommendation that you adopt my exact configuration. It is an argument for the principle that any sufficiently old engineer’s setup is, eventually, minimal — and that the path to minimal is not adding more features, but cutting the ones that produce friction without producing work.
What I run
Three things, in order of importance:
-
A terminal emulator. On Linux: Alacritty with default config. On macOS: Ghostty (used to be Kitty). On Windows: the new Windows Terminal. Configuration of all three: font (Fira Code, size 14), default profile pointing at my preferred shell, dark colour scheme. Nothing else.
-
Tmux as the session manager. A twenty-line
~/.tmux.confthat sets a vim-style copy mode, prefix on Ctrl-A (because Ctrl-B fights with Emacs habits), 256 colour mode, and a clean status bar that shows the current branch and the pomo timer. No tmuxinator, no plugin manager, no theme packs. -
Neovim as the editor. A thirty-line
init.luathat loadsnvim-treesitterfor syntax,nvim-lspconfigfor language servers,telescope.nvimfor fuzzy finding,mini.completionfor autocomplete, and that is the entire plugin list. No status line plugin, no file explorer, no Git integration plugin, no theme manager.
That is it. Total custom config across all three tools: about fifty lines. The repository on GitHub where I keep them is called dotfiles and the README is two sentences long.
What I do not run
The list of tools I tried and dropped is much longer than the list I kept. For honesty:
- Tmux plugins: tried
tmux-resurrect,tmux-continuum,tmux-yank. All useful for about a week, all eventually replaced with native equivalents or just by being more careful about session hygiene. - Neovim distributions: tried LazyVim, AstroVim, NvChad, LunarVim. Each one starts beautifully and degrades into something I do not understand within two months because they evolve faster than I have patience to keep up with. The thirty-line config I have today is something I can fully read in two minutes, which is the only test of whether a config is mine.
- Code completion: tried Copilot, tried Codeium, tried Tabnine, tried Cursor as a full IDE. Each one gave me about a 15-20% speedup on routine code and about a 30-40% slowdown on careful code because I started trusting the suggestions instead of thinking. The suggestions are often subtly wrong in ways that take longer to debug than the original code would have taken to write. Now I use a much more limited model only inside terminal scripts where the cost of being wrong is small.
- Status line plugins: lualine is beautiful and configurable and has fourteen themes. I removed it after a month because the default Neovim status line carries every piece of information I actually look at, and the plugin’s main effect was making me look at the status line more often than I needed to.
- File explorer: nvim-tree, neo-tree, oil.nvim. The honest truth is that the fuzzy finder (telescope) plus the terminal-side
cdandlscover ninety-five percent of my “find a file” needs faster than any tree view. I removed file explorers entirely. - Git plugins in Neovim: vim-fugitive, gitsigns, lazygit-as-floating-window. I kept gitsigns for the gutter indicators and removed everything else. Git in a terminal split is faster and more honest than git inside the editor.
What unifies the cut list: every removed tool had a positive surface appearance (clean UI, neat keystroke savings, social-media-screenshot-worthy aesthetic) and a negative real impact on my work (one more system to maintain, one more bug to debug, one more piece of mental overhead). The kept tools all have the opposite profile: they are slightly ugly, completely indispensable, and rarely break.
The structural argument
There is a structural reason minimal setups tend to win for deep work, and it is not the romantic “real engineers use vanilla Vim” rhetoric you find on certain corners of the internet. The reason is maintenance cost compounds.
Every tool, plugin, theme, and config layer in your setup has a maintenance cost: keeping it up to date, debugging it when it breaks, re-learning it when its upstream developer rewrites the API, updating its documentation, occasionally rewriting it from scratch when its philosophy changes. For any individual tool, the cost is small. Across thirty tools, the cost is significant. Across one hundred (which is what most over-customised setups end up at), the cost is a meaningful portion of every working week, paid in the same hours you would otherwise spend actually shipping code.
The minimal setup wins because its maintenance cost is dominated by the costs of the tools you cannot avoid (the kernel, the shell, the language runtimes, the OS package manager) rather than by costs you have voluntarily added. A thirty-line Neovim config breaks rarely; a thousand-line distribution breaks often. The hours saved by not maintaining the distribution are not theoretical — they show up in your week as actual hours of focused work that would otherwise have been consumed by yak shaving.
This is also why, paradoxically, the setups that look the most boring from the outside tend to belong to the engineers shipping the most interesting work. They are not better engineers than the people running customised Doom Emacs setups — they have simply stopped paying the configuration tax and reinvested those hours into the work itself.
The deep work case
For the specific case of deep work — the kind of three-to-five hour focused engineering session that produces actual progress on hard problems — the minimal setup has a second advantage. The number of in-editor distractions is dramatically lower. There is no status bar animation pulling your eye every time you save. There is no Git plugin badge updating in your peripheral vision. There is no AI completion popup interrupting your sentence to suggest a different sentence. There is just the code, the cursor, and the silence.
Combine this with a non-distracting visual environment — a single dark wallpaper, a 60-Hz monitor, a tmux status line showing only the working directory and the time — and the editor genuinely disappears. You stop noticing it. The editor becomes what every editor should be: a transparent surface for thinking, not a piece of software demanding attention.
This is the actual point of “minimal setup” as a productivity philosophy, and it is the part that the aesthetic-screenshot subculture on the internet misses. The minimalism is not for the aesthetic. The minimalism is to get the editor out of the way so the work can come through. It is not a style choice; it is a structural one. The fact that minimal setups tend to look clean and screenshot-friendly is a side effect of the more important fact that they get out of your way during the hours that matter.
Caveats
This is not the right setup for every engineer. If you are doing front-end work with heavy live-reload, complex framework tooling, and ten browsers open at once, a more featureful editor (or a full IDE) is probably the right call. If you spend most of your time in notebooks, JupyterLab or a dedicated notebook IDE beats Neovim. If you are doing Java or C# enterprise work, IntelliJ or Rider will save you more time than they cost. The minimal terminal stack works best for engineers doing backend, systems, or scripting work where the editor’s main job is to render text and the build/test/deploy cycle happens at the shell.
The other honest caveat: the path to a minimal setup runs through having had a maximal setup first. You probably cannot start with the thirty-line Neovim config. You have to go through the years of yak shaving to know which tools you actually need versus which ones you only thought you needed. The cycle is not a waste — it is the apprenticeship. Just try to notice when you are still in it.
What I do when I sit down to work
For completeness, here is the full setup when I start a deep work session:
# Open terminal, attach to the persistent tmux session for the project
tmux attach -t lofi || tmux new -s lofi
# Top window: editor on the file I'm working on
nvim ./scripts/<file>.py
# Bottom window split: shell for running tests / git
# A second pane somewhere with the lofi stream tab open in a browser
That is the entire ritual. The bottom of the screen shows the pomo timer countdown. The wallpaper is one of our shrine torii ultrawide variants. The 24/7 lofi stream runs on a pinned browser tab at low volume. Everything else is closed.
If the setup looks unremarkable, that is the entire point. — Marco
