Whenever I read the storybook romances of the New York Times wedding section, I think: The plural of anecdote is not data. In my time as a programmer and software engineer, I learned that the most heartfelt emotions collapsed in the face of cold quantitative analysis, just as so many loving marriages stand a good chance of ending in divorce. Inauspicious data scared me off marriage when I was younger, and it would have come as a surprise to teenage me that I’d end up in a relationship (and marriage) that has now spanned half my life. I can only attribute its provisional success to the power of software engineering and the wisdom I’ve gained from it.
My partner and I are both software engineers. We code and build programs. One of those programs is our marriage. Our code for the marriage is made up of our words, our actions, and our thoughts. Our job: to prevent bugs in our code from crashing the marriage.
You can’t avoid bugs. Every programmer makes them. The goal is to anticipate and mitigate the damage. Code can survive unexpected inputs and circumstances, if it’s robust enough. But very often the result is a crash, heralded by a message known to anyone who’s ever programmed in Linux or Unix: SEGMENTATION FAULT (CORE DUMPED). These are some software engineering maxims that have saved my marriage from core dumping.
1. Avoid Vaporware. Many products have crashed on the shoals of early announcements that proved impossible for programmers to then meet. Sometimes the delays in shipping a product went on for years—decades, in the case of Duke Nukem Forever. The pressure to deliver such vaporware puts immense strain on programmers, since they fear they can’t live up to what’s been promised—and often they can’t. What’s the ultimate in relationship vaporware? “Till death do us part.” We yanked that line out of our marriage vows and replaced it with quotes from Robert Musil (“Love is the most talkative of all feelings”) and James Wright (“Somewhere in me there is a crystal that I cannot find alone”). Another way of putting this is: Underpromise and overdeliver.
2. Beta-Test. We were quite young when we got together. The code I wrote when I was 21 wasn’t awful, but it was callow and could have been done so much better. No matter how good you think you are, there’s a lot more to learn. We understood this sufficiently to mistrust the feeble and inept judgments of our younger selves. We waited 10 years to get married, to rack up enough evidence that the code was now robust enough to keep the product running smoothly. And regular upgrades are crucial, lest code rot sets in.
3. Remember: Bugs Never Disappear. They Only Hibernate. I detested one of my partner’s friends, who had nastily dissed me a few times. I avoided him and let it go, only to find, down the line, that it really bothered me that he and my wife were still friends. Resentment ensued. Eventually we talked it out and I got the reassurance that my wounded pride had thirsted for in the first place. He even came to the wedding.
Bugs can seem evanescent. I’d see server crashes that appeared out of nowhere and, just as mysteriously, seemed to disappear. Bugs never disappear. If you haven’t actually fixed anything, it’s a dead certainty the enigmatic bug will return sometime in the future at the worst possible moment. Likewise: Bad fights may abruptly dissipate for calmer times, but the underlying issues will fester and explode later if you don’t understand them there and then.
4. Follow the 90/10 Rule: Here I quote an old law of software optimization: “A program spends 90% of its time in 10% of its code. Humans are very bad at guessing where that 10% lies.” Early on, I thought that the strength of our relationship rested on our shared interests (literature, software) and physical attraction. Looking back, those turned out to contribute a lot less to relationship stability than agreeing on finances, lifestyle, and sarcastic humor. More importantly, we realized each of us needed to have a room of our own where we could be alone. You have a limited amount of resources: Don’t spend them trying to get in sync with your partner on whether the British thriller Utopia is even better than Breaking Bad or going on nature hikes that only one of you enjoys (hint: not me). This is unnecessary optimization, and as comp-sci demigod Donald Knuth has said, “Premature optimization is the root of all evil.”
5. Do the Grunt Work. In the words of computer scientist Mary Shaw: “Less than 10% of the code has to do with the ostensible purpose of the system; the rest deals with input-output, data validation, data structure maintenance, and other housekeeping.” The ostensible purpose of a relationship is love, but if you rely on love to carry you through without the necessary support infrastructure, your relationship will be about as stable as Windows 3.0. Most of your code will not be about love, but about creating the circumstances for the possibility of love, and those circumstances have to do with working out the little piddly things around scheduling and finances and chores. Beware software engineers and lovers who only want to work on the sexy stuff.
6. Make This Your Mantra: Hysteresis Helps Homeostasis. Hysteresis is the dependency of a system not just on its current state but also on its history of states. When you incorporate hysteresis into an algorithm, it’s to prevent changes from having too many drastic effects too quickly—for example, a thermostat set to 68 degrees doesn’t just heat at 67 degrees and cool at 69 degrees; it keeps track of its recent actions so it doesn’t oscillate wildly.
In a marriage, too, you can’t overreact to sudden changes as though your entire past counts for nothing next to some shocking turn of events. Unfortunately, the human mind has great skill at rewriting the past based on the caprices of its emotions. In my worse moods, calm nights at home can abruptly look like the wastage of many years—every book read or movie watched just another distraction from the empty spectacle of two vacant souls enduring a pointlessly fortunate life. Those moods and memory lapses are just bugs as well. “With the perturbations of memory are linked the intermittencies of the heart,” wrote the great computer scientist Marcel Proust. And with the perturbations of code are linked the intermittencies of software.
7. Trust No One (Not Even Yourself). Hidden bugs in a program can come out of the woodwork years or even decades after the code was written. (The Y2K bug didn’t show up for decades in systems that were designed in the 1970s and 1980s, since that code handled 19XX years just fine.) I once found a bug that would crash an entire chat server, kicking thousands of users offline, if a single user happened to send exactly 60 messages in one minute, no more and no less. Uncommon, unexpected inputs produce new and sometimes catastrophic results, and the causes are usually never clear.
A good programmer knows that she never knows everything about a program. Likewise, even after 18 years together, I know that my picture of my wife is still only an approximation of a very complex person, and thinking it complete and accurate will inevitably lead to error upon error.
Back in 2000, the Triassic age of cellphone technology, on a disastrous kayaking trip organized by a (now former) friend, my partner and I were stranded in darkness on a tiny spit of land in Puget Sound with the tide encroaching. I shivered with hypothermia while our friends bickered over which island on the map we were actually on. My wife quietly turned on the unwieldy mobile phone that she’d presciently removed from its cobwebbed home in our car’s glove compartment. She whispered to me, “We have cellphone reception. We can call the Coast Guard.” For that, she has my eternal gratitude. To quote Proust again, “It is a charming law of nature that we live in perfect ignorance of those we love.” We may think we know our partners inside and out, but we can never quite predict how they’ll react in an unprecedented situation. All we have is the program itself—everyday life—and the endless process of debugging and maintaining our own code.
