Rebuildable Working Environments

Having an environment to work in that you can rebuild is invaluable. When something breaks the first course of action with software is to find a way to reproduce the error. Since there are often many moving parts even familiarity with a system isn’t a fool-proof debugging strategy. I find myself in a small but powerful minority of developers who extend this thinking to the working environment and tools.

Software is built to fail; as users we are accustomed to freezing windows, unresponsive input screens, and programs that mysteriously stop working.

“Did you try turning it off and on again?”

Working with tools I know I can tear down and reassemble from a clean slate keeps me sane. Moving fast means breaking things, when you have no record of what in your text editor or project changed the debugging process becomes tedious. By trading convenient buttons and checkboxes for code, the solutions to problems with my tools are encoded. If my settings are broken at least they will be broken the same way on all my computers.

There are definitely trade-offs, I could use VSCode and likely never worry about 99% of what I end up reading documentation for with Neovim. I view the time sink that others avoid as a boon. My rebuildable environment awards me freedom to experiment alongside the comfort of being able to return to stability when I need it.