Dotfiles for adults: less terminal cosplay, more useful flow

I like a nice terminal as much as the next engineer. I also like not wasting half an hour a day on avoidable friction.

Only one of those survives contact with real delivery work.

I maintain my dotfiles because local friction compounds quietly. One alias that behaves differently per machine. One setup step you always forget. One command you run daily that still feels like a scavenger hunt. None of these is catastrophic on its own. Together they're a low-grade tax on your best judgement - applied at the exact moment you're trying to think clearly.

When teams say "we need to move faster", the instinct is usually to jump to architecture. Sensible. But there's another lever that gets overlooked: reduce the cognitive drag at the local level, so engineers spend less time context-switching and more time making good decisions.

That's what dotfiles are for, when they're done well.

My rule: config has to earn its place

Over time I removed most of the "clever" customisation and kept only what pays off repeatedly. If a tweak mostly makes me feel clever, it doesn't survive. If it helps me move from question to verified change with less noise, it stays.

The terminal is a workplace, not a theme park.

What actually helps me deliver better

The biggest wins are boring and consistent:

fast discovery - fzf and ripgrep for finding files and symbols without mental overhead;
stable sessions - tmux for long-running contexts that survive network blips and laptop lids;
predictable shell behaviour - minimal aliases, obvious names, consistent flags so nothing surprises you mid-incident;
editor ergonomics - Neovim tuned for readability and navigation speed, not novelty;
script-first workflow - project-critical operations live in repo scripts or Make targets, not in my personal shell layer.

That last one matters most when working in teams.

A hard boundary: personal setup must not hide team workflows

I made this mistake earlier in my career and I still see it regularly: moving essential project behaviour into private shell magic.

It feels fast for the engineer who wrote it. It's fragile for everyone else - and it quietly ensures that nobody else can own the workflow.

If a command matters to delivery, it belongs in the project. Dotfiles should support shared workflows, not replace them.

The test I use: if I disappeared for two weeks, could the team run the same workflow without any guesswork? If the honest answer is no, I've put too much in my personal layer.

Why this is really about reliability, not preference

Good local tooling improves more than typing speed. It helps most in the places where engineering gets expensive:

incident triage, when you need fast, accurate investigation and your tools need to get out of the way;
release windows, when confidence matters more than cleverness;
onboarding, when setup friction can quietly burn a full week for a new joiner;
large refactors, when context breadth is high and small mistakes compound.

Stable local workflows preserve cognitive bandwidth for the decisions that actually require it - architecture, debugging, user impact. That's a reliability outcome, not just a productivity vibe.

Final thought

Dotfiles aren't about being "that engineer with the dramatic terminal". They're about reducing repeated friction so your best attention goes to the hard problems, not to command archaeology.

Good dotfiles are quietly useful. They don't perform. They support.

And if your prompt looks nice at the same time, that's a perfectly acceptable bonus.