There is a folder on my laptop called dotfiles-v7. Not version seven of my dotfiles — version seven of my attempt to organize* them. Somewhere around version four I stopped counting the hours and started lying to myself that the whole project was nearly done.
I know I am not alone in this. Every developer I have worked alongside closely enough to see their screen at an odd hour has some version of the same folder, the same half-finished Neovim config, the same Brewfile that references a tool they installed in 2019 and have not opened since. We call it "the setup." We speak of it the way retirees speak of the novel they are going to write: with reverence, with guilt, and with the unspoken knowledge that the finishing of it is not really the point.
The developer setup has become the great displacement activity of our industry — and nobody seems particularly bothered by that.
When Craft Became Cargo Cult
There was a moment, somewhere in the late 2000s, when the idea of the craftsman programmer took serious cultural hold. Books like The Pragmatic Programmer encouraged us to treat our editor as a finely tuned instrument, to know it the way a carpenter knows a good plane. That metaphor was useful once. A carpenter who keeps her tools sharp does better work. The analogy made sense.
What the analogy did not anticipate was GitHub. Or YouTube. Or the entire ecosystem of "my setup" content that would emerge once it became possible to share configurations publicly and receive social validation for doing so. The craftsman sharpening her tools in private became, in the social-media era, a performance. And performances have audiences, which means they have incentives that have nothing to do with the work itself.
I watched this happen in real time at a company I worked for around 2015. We had a Slack channel called #devtools that started, reasonably enough, as a place to share useful utilities. Within eight months it had become the most active channel in the workspace — more active than the channel for the product we were actually building. Engineers who struggled to finish a ticket on time were posting elaborate terminal screenshots at eleven at night. The screenshots got reactions. The tickets did not.
The tools had eaten the work.
The Setup as Identity
Part of what makes this pattern so sticky is that a developer's setup is genuinely expressive. The choices you make — Vim or Emacs, fish or zsh, tiling window manager or stock macOS — do say something real about how you think. There is a kind of personality legible in a well-commented config file, a sensibility in the way someone structures their keybindings. I do not want to dismiss that entirely.
But identity is a trap when it becomes load-bearing. When your self-image as a serious engineer depends on having a serious setup, then the setup can never actually be finished — because finishing it would remove the ongoing project of being the kind of person who cares about their setup. The incompleteness is the point. The perpetual refinement is what signals membership.
This is why "just use the defaults" advice, however practically sound, tends to land like a personal insult in certain communities. Defaults are for people who do not care. And caring — visibly, publicly, in elaborate detail — is the whole social contract.
I once spent a long weekend getting a fuzzy-finder configured to search across my notes, my code, and my browser bookmarks simultaneously. It worked, eventually. I used it perhaps twice before I forgot the keybinding. The weekend itself, though — the problem-solving, the Stack Overflow threads, the small dopamine hits of incremental progress — that I remember clearly. It felt like productivity. It was not.
What the Research Quietly Suggests
There is not a lot of rigorous study on developer tooling time specifically, but the adjacent research is not encouraging for the optimization-obsessed. Studies on expert performance consistently find that the marginal return on tool refinement drops sharply once basic competence is established. The gap between a mediocre setup and a good one is real. The gap between a good setup and a perfect one is largely imaginary — or at least, it is swamped by variables like focus, sleep, and the clarity of the problem itself.
Calendar research on knowledge workers shows that interruption recovery — getting back into deep focus after a distraction — costs somewhere between fifteen and twenty-three minutes per instance. A developer who spends forty minutes tuning a config on a Tuesday afternoon has not just lost forty minutes. They have likely lost the better part of the morning's momentum as well. The opportunity cost is invisible, which is precisely why it never appears in anyone's retrospective on their workflow.
We are also, I suspect, systematically bad at measuring the benefit side of the equation. We notice when a new tool saves us thirty seconds on a repeated task. We do not notice the three hours we spent installing it, the hour we spent debugging a conflict it introduced, or the cognitive overhead of maintaining one more thing in our mental model of our own machine. The ledger is lopsided because we only record the credits.
The Sunk Cost That Breathes
What makes the developer setup genuinely different from other forms of procrastination is that it compounds. A dotfiles repo is not a static bad decision — it is a living one. Every new tool you add creates a new surface for breakage, a new dependency to manage, a new thing to port when you get a new machine. The setup grows, and as it grows, the maintenance burden grows with it, which in turn justifies spending more time on it, which adds more complexity.
I rebuilt my entire configuration from scratch eighteen months ago, committed to minimalism. I was going to use stock terminal settings, the default shell, a single general-purpose editor. I lasted about six weeks before the first "just one small thing" crept in. Then another. Today, dotfiles-v7 is not dramatically simpler than dotfiles-v3. It is just newer, and I understand it slightly better, and in another year I will probably start dotfiles-v8 with the same good intentions.
The sunk cost is not the time already spent. The sunk cost is the identity you have built around being someone who tends this particular garden. Abandoning the setup would mean abandoning a version of yourself, and that is a much harder thing to do than just closing a terminal window.
Learning to Leave It Alone
I am not going to tell you to delete your dotfiles. I still have mine. What I have tried to do — with mixed results, honestly — is impose a rule I borrowed from a woodworker friend who has a strict policy about buying new tools: you have to finish the current project before you are allowed to acquire anything new. For me, the equivalent is that I cannot touch my configuration during a sprint. The setup is frozen while the work is live.
It sounds simple. It is surprisingly hard to honor. The urge to tinker spikes exactly when the work gets difficult — which is, of course, the point. Difficulty is uncomfortable. Reconfiguring a plugin is comfortable and produces visible results quickly. The brain knows which one to reach for.
Maybe the most honest thing I can say is this: the developer setup will always promise more than it delivers, because what it is really selling is the feeling of control in a discipline that is fundamentally resistant to it. Code is hard. Systems are unpredictable. Other people's requirements are irrational. But your terminal color scheme — that you can get exactly right.
The question worth sitting with is not which tools to use. It is what you are avoiding when you reach for them.