Repair, Don’t Replace: Understanding Systems

Experience with off-roading has changed what “prepared” means. My RZR contains a surprising amount of extra hardware, an assembly of nearly two decades of trials with things going wrong. There’s a spare drive belt, spark plugs, tire repair kits, fluids, spare tire, fire extinguisher, and on and on. It’s a toolbox that seems excessive until it isn’t.

I’m not expecting failures — most rides are uneventful in that regard — but they do happen, and I can’t exactly just switch to a different machine. A parts store is hours away, and we’re miles of rugged trail across two ridges from workable cell service. If something fails, the only useful resources are whatever parts, tools, and knowledge came along for the ride.

This isn’t unique to my off-roading adventures but extends into virtually all aspects of life.

Repairs

I have repaired a fairly varied collection of things. Many of the projects, especially the larger ones, were automotive: replacing a torque converter, replacing a head gasket, or tracing electrical problems. Others were much less involved: basic maintenance like an oil change, swapping out the power board in a television, upgrading from a failed hard drive in a laptop, restringing blinds, fixing sprinkler valves and heads, and addressing a leaking propane line in an RV.

The easiest solution would have been to replace many of those things or to hire out the job and spend my time elsewhere. Sometimes that’s the correct decision, and I try to recognize when it is. But often it’s not.

The projects themselves haven’t really changed. Some are small enough to finish in the amount of time it takes just to gather the tools and parts — I’ve restrung more than one set of broken blinds because of a cat that chews any string within reach, and the replacement parts cost only a few dollars. Others become much larger commitments like replacing the torque converter in an older, high-mileage Subaru, which meant pulling the engine itself, making a judgment about whether the vehicle itself was still worth spending time and money on, and accepting that I might discover additional problems before it went back together.

Neither project was fundamentally about blinds or transmissions beyond the obvious end result. They were both exercises in understanding a system and building experience for future repairs and replacements. Saving some money was more of a secondary benefit.

That experience changes the economics of future repairs. The second time I removed the engine, I wasn’t learning where every connector, hose, and bracket belonged. Much of that cost had already been paid, and knowledge compounds in a way that simply replacing the whole thing rarely does.

The Underlying Value

The obvious question is what any of that really buys you. Saving money is the answer most people arrive at first, and that absolutely is part of it; some of those repairs have avoided expensive replacements or labor bills. Compared to taking the car to a Subaru mechanic, doing the head gasket replacement myself saved roughly $4,000.

Others have hardly mattered financially at all. Restringing a set of blinds isn’t exactly a life-changing economic decision, though it would add up after the dozen or two times I have done it (there's a lesson here too about finding a way to avoid repeated fixes too, which we finally did).

Money is easy to measure, though, which is probably why it dominates discussions about repair. You can total labor costs, add up parts, compare replacement prices, and calculate the savings from doing the work yourself. Knowledge and understanding is harder to quantify, and that's why it’s so easy to underestimate.

Ultimately, my curiosity probably deserves more credit than thrift. More than once I’ve taken something apart because I wanted to know how it worked, not necessarily because the repair itself justified the effort. That curiosity has repeatedly paid unexpected dividends later for me, often in situations that have very little to do with the original project.

Building Mental Models

Every repair attempt forces you to build a mental model of how a system works. Once you understand why something failed and how the surrounding systems interact, that understanding becomes available the next time you encounter a similar problem, even if it’s an entirely different system.

A torque converter is no longer just some novel or abstract automotive part once you’ve replaced one. You understand what it does, how it fails, what symptoms point toward it instead of other potential causes, and why it can be worth fixing rather than replacing the entire vehicle. You also gain an understanding of its supporting systems and hardware.

This same pattern repeats almost everywhere. A successful repair leaves behind two things: a machine that works and a person who understands it better. Even an unsuccessful attempt usually leaves the latter.

Virtually all modern products of any complexity are assemblies of simpler subsystems, subsystems that can usually be isolated to repair or replace. Irrigation systems and computers are both modular as are vehicles and your home. Once you begin seeing products as assemblies instead of monolithic objects, replacing the whole thing starts feeling like only one option among several.

Beyond Repairs

This is not to say that all repairs are necessarily possible or worthwhile, though. One television, an old Samsung, wasn’t possible to repair because replacement boards were unobtainable. I also abandoned repairing an EGO battery pack after finding out enough of the cells were dead, though not before spending money on a couple of replacement BMS boards. A new magnetron costs as much as a microwave itself.

Some repairs fail due to human error: I accidentally drained the transmission instead of the oil once, costing about $100 in replacement fluid. I also created a huge mess to clean up (Subarus have a very messy fill procedure).

The mistake reinforced another lesson, though: understanding something doesn’t prevent errors, but it makes recovery less intimidating. Failure is really only complete when you miss the lesson it brings with it, and understanding the successes and failures both help adapt that knowledge to the next encounter.

Once you begin looking at systems that way, knowledge starts transferring between things that appear unrelated. By the time I replaced the head gasket, removing the engine no longer felt like the project itself — it was the first several hours of getting to the project. Procedures that once demanded careful labeling and photographs had become routine, leaving more attention for the actual problem, and work moved faster.

Vehicles, computers, and appliances frequently require vastly different tools, but the troubleshooting itself follows a familiar process: isolate variables, test assumptions, and narrow the possibilities until an explanation fits the evidence. Software debugging works the same way. A failing program and a failing battery share no parts, but both call for hypotheses, evidence, and a willingness to revise plans and assumptions.

I'm certain that tinkering with and repairing physical systems reinforced these habits long before I wrote software professionally. They aren’t mechanical skills. They transcend that; they’re habits of reasoning that transfer between disciplines.

Something else happens too, almost without noticing: you become less intimidated by the unfamiliar. Many become manageable once they’re broken into smaller pieces. The details differ, but patterns repeat, and the process of figuring them out becomes familiar.

Design patterns repeat often, much as evolutionary patterns in nature do. Once you can recognize them, previous exploration becomes applicable far outside its original context. The first engine removal felt intimidating because every connector and bracket was unknown. The second wasn’t easier because I remembered every detail but because I could draw on that previous experience.

The lasting value isn’t only the repaired object but the understanding left behind. It changes how you approach unfamiliar problems and how dependent you are on others when something breaks.

Independence

Self-reliance isn’t refusing to replace things. Understanding a system doesn’t obligate you to rebuild every component yourself any more than understanding software obligates you to rewrite every library. Sometimes replacement, delegation, or redesign is the correct engineering decision. The value lies in recognizing which option fits the situation instead of choosing blindly.

It also means you don’t have to make every decision under pressure. When a drive belt fails on a trail or an air conditioner’s start capacitor dies on a Sunday, you’re not immediately dependent on someone else’s schedule. You may fix it yourself or decide not to; the value is having a choice. Instead of immediately asking who can fix something, you can first start with a diagnosis and determine whether repair is worthwhile.

The years haven’t changed what I am capable of repairing nearly as much as they’ve changed what “prepared” means. The spare parts matter, but they’re only half of what’s riding in the back of the machine. The rest is the accumulated understanding of how and why things fail.

A broken belt, a leaking valve, an electrical fault, or a piece of software that suddenly behaves differently all begin with the same question: What changed?

Sometimes the answer is a five-minute repair. Sometimes it’s a weekend project. Sometimes it’s deciding the repair isn’t worth doing.

But every time I work through that process, I become less dependent on luck, less dependent on someone else’s schedule, and more confident that the next unfamiliar problem is understandable.