Version Control for Life

Every serious engineer eventually internalises a habit that has nothing to do with syntax: never make a change you can't undo. Commit small. Branch before you experiment. Keep the working version safe while you try something risky next to it, not on top of it. The habit exists because software is unforgiving about mistakes made carelessly and remarkably forgiving about mistakes made with a plan for reversing them.

I have started noticing how rarely this habit gets applied to anything outside a codebase, and how much smoother a few ordinary decisions become when it does.

Take something as small as rearranging furniture. The instinctive approach is to move everything at once, live with the result for a week, and either keep it or move everything back — a single irreversible-feeling commit with no branch to retreat to. The version-control approach is slower and, honestly, a bit tedious: move one piece, note what changed, live with it for a day or two before touching anything else. It produces less dramatic before-and-after photos. It also means that if something feels wrong on day three, there is exactly one variable to reconsider, not four.

The same logic applies to changes with real stakes — a new working routine, a shift in how a team runs its meetings, a change to a personal budget. The instinct under pressure is to overhaul everything at once, because a partial fix feels like it isn't trying hard enough. But a full overhaul is a single unreviewable commit. If it doesn't work, there is no way to tell which part of it failed, and reverting means giving up everything, including the pieces that were helping.

None of this is a metaphor for discipline in some vague, motivational sense. It's a specific, mechanical habit: change one thing, note the state before you changed it, give yourself an honest window to evaluate, and only then decide whether to keep going or roll back. Engineers do this automatically with code because the tooling makes it easy and the cost of skipping it is visible fast. Outside of code, there's no tooling to enforce it, no diff to review, no log of what the previous state actually was. That absence is exactly why the habit is worth borrowing on purpose rather than assuming it will show up on its own.

The version control isn't really the point. The point is smaller and less impressive: most changes worth making are worth making in pieces, with a clear record of what you'd be going back to if the next piece doesn't work.

It also changes how failure feels. A reverted commit isn't a defeat; it's just information, filed away for the next attempt. Treat a failed change the same way outside of code — as one data point rather than a verdict on the whole plan — and it gets considerably easier to keep experimenting instead of declaring the entire effort a mistake and abandoning it for good.