Coders’ Primal Urge to Kill Inefficiency—Everywhere

Ho, as it turned out, had a very strict and peculiar itinerary planned. He’s fond of ramen dishes, and to fit as many as possible into their visit to Tokyo, he’d assembled a list of noodle places and plotted them on Google Maps. Then he’d written some custom code to rank the restaurants so they could be sure to visit the best ones as they went sightseeing. It was, he said, a “pretty traditional” algorithmic challenge, of the sort you learn in college. Ho showed Chang the map on his phone. He told her he was planning to keep careful notes about the quality of each meal too. “Oh wow,” she thought, impressed, if a bit wary. “This guy is kind of nuts.”

Ho was also witty, well read, and funny, and the trip was a success. They ate a lot of ramen but also drank beer ringside at a sumo wrestling match, visited the Imperial Palace, and stopped by the hotel where Lost in Translation was filmed. It was the beginning of a seven-year relationship.

Oddities like the ramen optimizer have been part of Ho’s daily routines for years. As a kid growing up in Macon, Georgia, Ho owned a Texas Instruments TI-89 calculator, he told me. One day while leafing through the instruction manual, he discovered that the calculator contained a form of the Basic programming language and taught himself enough to painstakingly ­re-create Nintendo’s The Legend of Zelda game on the calculator. He learned Java on the computer and, after high school, went to Georgia Tech in Atlanta to study computer science. Abstract algorithmic concepts were interesting enough, but what really got him going was using computers to avoid repetitive labor. “Anytime I have to repeat something over and over,” he told me, “I get bored.”

In his final year of college, Ho started a company that created forums where students studying the same courses at different colleges could answer one another’s questions. But it didn’t amass nearly enough users, so he shut it down. He interviewed at a few companies like Google and Micro­soft but sank into a funk. He didn’t want to work for someone else. As a question of value creation, being an employee was a terrible proposition, he felt. Sure, you earned a check. But most of the value of your labor was captured by the founders, the ones who owned equity. He had the skills to build something, soup to nuts. He just didn’t know what.

A few months later, he stumbled into an idea on a visit home to Macon. He went to Staples on an errand with his dad, a pediatrician who ran his own office. Ho’s father needed to buy two time clocks, those old-school machines where employees insert cards to be stamped with the time they start and stop work for the day. Each clock cost around $300.

Ho was astounded: Had time-clock technology not changed since The Flintstones? “I can’t believe this is still a thing,” he thought. He realized he could quickly cobble together a website that performed the same task, but better: Employees could check in with their phones, and the site would total up the hours automatically. “Don’t buy this time clock,” he told his father. “I’m going to code you one.” Three days later, he had a prototype. His father’s office began using the service and, to Ho’s delight, they loved it. The system was remarkably more efficient than a paper-based time clock.

He spiffed up the website, gave it a name—Clockspot—and, four months later, a law firm signed on as a client. When its first payment came through, Ho nearly jumped out of a chair at the Georgia Tech library where he was working. He was getting money for his software! Nine months later, Ho’s company was earning around $10,000 a month from cleaning companies, home-health-care-aide firms, the city of Birmingham, Alabama. He worked nonstop for two years improving and debugging the code. Eventually he got it working so well that Clockspot was running mostly on autopilot. Besides himself, the only employee Ho needed was a part-time customer service agent. He was making a healthy income and had plenty of time for his travels and other interests. He’d optimized his life efficiency.

Like any sentient person, you’ve noticed that software is eating the world, to use venture capitalist Marc Andreessen’s famous phrase. You’ve seen Facebook swallow the public sphere, Uber overhaul urban transportation, Instagram supercharge selfie culture, and Amazon drop off your shopping within 24 hours. Technological innovators generally boast that their services change the world or make life more convenient, but underpinning everything they do is speed. Whatever you were doing before—hailing a cab, gossiping with a friend, buying toothpaste—now happens faster. The thrust of Silicon Valley is always to take human activity and shift it into metabolic overdrive. And maybe you’ve wondered, why the heck is that? Why do techies insist that things should be sped up, torqued, optimized?

There’s one obvious reason, of course: They do it because of the dictates of the market. Capitalism handsomely rewards anyone who can improve a process and squeeze some margin out. But with software, there’s something else going on too. For coders, efficiency is more than just a tool for business. It’s an existential state, an emotional driver.

Coders might have different backgrounds and political opinions, but nearly every one I’ve ever met found deep, almost soulful pleasure in taking something inefficient—even just a little bit slow—and tightening it up a notch. Removing the friction from a system is an aesthetic joy; coders’ eyes blaze when they talk about making something run faster or how they eliminated some bothersome human effort from a process.

This passion for efficiency isn’t unique to software developers. Engineers and inventors have long been motivated by it. During the early years of industrialization, engineers elevated the automation of everyday tasks to a moral good. The engineer was humanity’s “redeemer from despairing drudgery and burdensome labor,” as Charles Hermany, an engineer himself, wrote in 1904. Frederick Winslow Taylor—the inventor of Taylorism, which helped lay the groundwork for manufacturing assembly lines—inveighed against the “awkward, inefficient or ill-directed movements of men.” Frank Gilbreth fretted over wasted movements in everything from bricklaying to vest buttoning, while his industrial-­engineering partner and wife, Lillian Evelyn Gilbreth, designed kitchens such that the number of steps in making a strawberry shortcake was reduced “from 281 to 45,” as The Better Homes Manual enthused in 1931.

Many of today’s programmers have their efficiency “aha” moment in their teenage years, when they discover that life is full of blindingly dull repetitive tasks and that computers are really good at doing them. (Math homework, with its dull litany of exercises, was one thing that inspired a number of coders I’ve talked to.) Larry Wall, who created the Perl programming language, and several coauthors wrote that one of the key virtues of a programmer is “laziness”—of the variety where your unwillingness to perform rote actions inspires you to do the work to automate them.

Eventually that orientation toward efficiency becomes hard to turn off. “Most engineers I know go through life seeing inefficiencies everywhere,” Christa Mabee, a coder in San Francisco, once told me. “Inefficiencies boarding your planes, whatever. You just get sick of shit being broken.” She’ll find herself walking down the street wishing people navigated the sidewalks and street crossings in a more optimal fashion. Jeannette Wing, a professor of computer science who runs the Data Science Institute at Columbia University, popularized the phrase computational thinking to describe what Mabee was talking about. It involves the art of seeing the invisible systems in the world around you, the rule sets and design decisions that govern how we live.

Jason Ho had a knack for seeing and trying to perfect those invisible systems. I met Ho and Chang in—of course—a ramen restaurant in San Francisco a few years ago. Ho was managing Clockspot, though it was ticking along so nicely by that point that he was working only a few hours a week. “He says he works 20 hours a month, but I don’t think I’ve seen him work that much,” Chang said. (The couple has since broken up, but the two remain on good terms.) Ho spent quite a bit of time traveling; once he’d even handled a Clockspot outage while at base camp on Mount Everest.

His optimizing and coding work, however, never stops. When he decided to buy a house, he wrote a piece of software into which he could dump the information for scores of homes on the market—their locations, prices, and neighborhood statistics—and the program would calculate the properties’ probable long-term value. The program’s top pick was a modern condo in Nob Hill. He duly bought it. Because he hates shopping, he bought dozens of pairs of the same T-shirt and khakis, a classic strategy for coders, since it removes the friction of decisionmaking when getting dressed.

A few years ago, Ho decided to take up bodybuilding, which presented a particularly demented optimization challenge: How ripped could he get? He carried a small scale to restaurants and weighed his food portions. “He tracked every single thing he ate in this massive spreadsheet,” Chang said. Ho sheepishly showed me the spreadsheet on his phone; a sprawling beast that plotted every ingredient in his workout meals, for a total of 3,500 calories per day. He worked out in a gym but also devised ways to squeeze exercise into whatever he was doing. If he passed a thick metal railing, he’d use it to do pull-ups; if he passed a dumpster, he’d lift it up on one edge.

After two years of training, he placed second in an amateur bodybuilding competition. He flipped through his phone to find pictures of himself from the period. In one picture he’s lightly oiled and posing in his underwear before a sunny window. He looks like a Greek statue. “I was down to about 7 percent body fat,” he said. It felt good to look so ripped, he said, but mostly he’d just wanted to see whether it was possible.

Ho showed me another chart he’d constructed. This one was a life guide, of sorts, a way of optimizing not just his body but how he devoted every waking second. He decided he wanted to spend time doing only the things where every ounce of effort was most likely to produce maximum results. He’d made 16 rows labeled with life activities. Among them: entrepreneurship, programming, guitar, StarCraft, shopping, and “spending time with friends and family.”

Then, in columns, he plotted various criteria—like whether the activity is inherently meaningful and not just a means to an end (“autotelic”), whether it “can be mastered,” whether it “impacts multiple areas of life.” For “programming” and “entrepreneurship,” Ho ticked off yes for every quality. When he came to the social realm of “spending time with friends and family,” he checked the box for “impacts multiple areas of life.” For “can be mastered,” he wrote maybe.

For a lot of people, this might seem nuts. The idea that you might want to systematize the emotional parts of life and regard social activity as a source of inefficiency is, to many people, discomfiting. Ho is gregarious and outgoing, but for some coders, people and their incessant demands can be a pain in the butt, and human relations another daily hassle to be fixed. It’s a problem that technologists, back in the early days of computing, pondered with some unease. As Konrad Zuse, the German civil engineer who built the first programmable computer, was credited with saying: “The danger of computers becoming like humans is not as great as the danger of humans becoming like computers.”

I thought of this one evening when I was engrossed in a Quora thread in which dozens of coders shared tales of how they’d automated the nuances of everyday life. There were some unsettling, if morbidly fascinating, ploys for turning social contact into a set-and-­forget robotized task. “I got tired of hearing ‘You never message me’ from friends and family,” one programmer wrote, so he created a script that would randomly send them texts, created using a Mad Libs–style mashup. A text would begin with this gambit—“Good morning/afternoon/evening, Hey {name}, I’ve been meaning to call you”—and then append one option from a list of endings: “I hope all has been well/I will be home later next month love you/let’s talk sometime next week when are you free.”

At a hackathon in San Francisco, a middle-­aged coder excitedly showed me an app he’d created that would send automated romantic messages to a partner. “When you don’t have enough time to think about her”—yep, he assumed the emotionally needy partner would be a her—“this can take care of it for you,” he enthused. These sorts of attempts to make socializing efficient go all the way up the chain to the biggest high-tech firms: Think of Gmail’s auto-complete feature, which encourages us to speed up email by having an algorithm compose our responses for us.

Linguists and psychologists have long documented the value of phatic communications—the various emotional devices humans use in everyday life to make others feel at ease or listened to: “How’s it going?” “Crazy weather, eh?” “What are you up to tonight?” The more I talked to coders, the more stories I heard of people who found that stuff as irritating as grit in gears.

Christopher Thorpe, a veteran of more than a half-dozen tech firms, told me about “an incredibly talented engineer” he once worked with who fit that bill. “He was very upset with me that we told jokes in all our meetings, because we were wasting time. ‘Why are we spending five minutes having fun with 20 people in the office? This is work time.’ Everybody is laughing—but, you know, you’re wasting all this valuable time.” The joke had frittered the time of 20 people! This guy would begin rattling off the math: “Five minutes times 20, that’s like, you know, you’ve wasted an hour and a half of person-time on these jokes.”

The truth is, I have some sympathy for coders’ mania for optimizing daily life, because I’ve tasted those electric thrills myself. Three years ago I started working on a book about the psychology of programmers, so I decided to pick up the long-­discarded coding I’d done on VIC-20s back in the ’80s and dabble in some modern languages like Python and JavaScript. The more I played around writing little scripts, the more I began to notice, and be deeply annoyed by, moments of inefficiency in my daily affairs. While writing, for example, I’d find myself frequently consulting various online thesauri. (Feel free to judge me.) They were useful but so sludgy that each time I did a search it took maybe two seconds to load the results. So I decided to write my own command-line thesaurus, using a site that offered a thesaurus API. After a quick morning of tinkering with Python, I had a script. I’d type a word into the command line and get synonyms and antonyms back with lightning speed. It was green text on black, unadorned, and crude. But damn, it was fast: No more waiting around for the browser to load a slurry of tracking scripts while cookies clogged up my hard drive.

Granted, the amount of time this saved me was not terribly consequential. Assuming I search for synonyms twice an hour on average while I’m writing, and assuming (generously) that my creation saved me a rollicking two seconds per search, I spared myself, maybe, one hour a year of irked waiting. Hardly worth mentioning. Still, the burn of velocity warmed my soul. Each time I searched for a synonym, the zippy results produced a surge of pleasure. I was applying the drug of efficiency to my veins, and it felt good.

Before long I’d gotten addicted to writing code for little routines. I made one to clean up YouTube transcripts that I’d downloaded; another to crawl and archive links I posted to Twitter; one that continually checked the website of my son’s elementary school and texted him when the teacher posted homework. (He was sick of hitting Refresh.)

A lot of my little programs were badly written, barely functioning hack jobs; I picked the most simple, brute-force way to get it done. When I looked at the code of really experienced programmers, I’d admire how much more elegantly they wrote. I’d come up with a sprawling, ugly function to sift through some data and then find that an experienced programmer could do it in a few crisp lines. (And their code ran a lot faster too.) Journalists sometimes marvel at the huge size of Google’s code base—2 billion lines!—as an indication of its might. But coders aren’t impressed by volume. Sometimes the most productive programmers are those who reduce code bases, make them shorter and denser. After three years at Facebook, an engineer named Jinghao Yan checked all of his contributions to the company’s code base and found that the math was negative. “I’ve added 391,973 lines to and removed 509,793 lines from the main repository,” he wrote on another Quora coder thread. (There are a lot of programmers on Quora, as it turns out.) “So if I coded 1,000 hours a year, that’s about 39 net lines removed per hour!”

Programming is reminiscent of poetry, where compression can confer power. “In a well-crafted poem, every single word has meaning and purpose,” as the coder and writer Matt Ward wrote in an essay for Smashing Magazine. “A poet can spend hours struggling for just the right word, or set aside a poem for days before coming back to it for a fresh perspective.” Among the most famous modernist poems, inspired by the age-old concision of haiku, was Ezra Pound’s “In a Station of the Metro”:

The apparition of these faces in the crowd; Petals on a wet, black bough.

“In just two lines and fourteen simple words,” Ward notes, “Pound paints a striking image, ripe with meaning and begging to be devoured by scholars and critics. Now, that’s efficiency.”

Back in 2016, I visited Ryan Olson, a lead engineer for Instagram. His team had just pushed out the platform’s Stories function. It was a massive update. Olson told me about traveling around San Francisco in a blur of exhaustion mere hours after the update went live­­ and seeing people already using Stories. “It’s a pretty cool experience,” he said. “Last night I was at the gym, and I looked over and someone is using the product. I don’t know if there’s ever been historically any other way where you could reach so many people” or where “so few people define the experience of so many.”

It’s one thing to optimize your personal life. But for many programmers, the true narcotic is transforming the world. Scale itself is a joy; it’s mesmerizing to watch your new piece of code suddenly explode in popularity, going from two people to four to eight to the entire globe. You’ve accelerated some aspect of life—how we text or pay bills or share news—and you can see the ripples spread outward.

This is how the big riches in software are often made, too, so there’s a concomitant frisson of power and wealth. Venture capitalists pour money into things they think will grow like kudzu, and the markets reward it. This nexus of motivations tends to produce, in efficiency-loving Silicon Valley engineers, not just a pleasure in scale but an absolute lust for it.

Indeed, among the royalty of Silicon Valley there’s often a sort of contempt for things that don’t scale. Smallness can seem like weakness. A few times while talking to tech bigwigs, I’d mentioned Jason Ho’s company, explaining how I found it a smart and admirable business, a perfect example of an entrepreneur nailing an unmet need. But they scoffed. To them, Ho’s Clockspot was a “lifestyle business”—Valley-speak for an idea that will never scale into the stratosphere. That sort of product is fine, sure, they say, but Google could copy it and put him out of business in a second.

Obviously we’ve benefited enormously from software engineers’ twitchy, instinctive desire to speed things up, to create plenitude. But the simultaneous, relentless drive for efficiency at scale has troubling side effects. Facebook’s News Feed speeds up how friends show us photos but also how malcontents spread disinformation. Uber optimizes car-hailing for riders but upends the economics of making a living as a driver. Amazon prepares drones for delivery of electronics over main streets denuded of stores.

Perhaps we—the folks whose lives are being so relentlessly optimized—are finally noticing these repercussions. We’re certainly complaining more about Big Tech, noticing how it outgasses civic problems, how it enrages while it enchants. We don’t quite know what to do about it; we still like the convenience, the way software constantly claims we can do more with less. But the doubts are prickling at our skin.

Maybe we’re becoming uncomfortable with how we, too, in our daily habits, have embraced the romance of hyperoptimization. Look at the scene on any city street: Employees listening to podcasts at 1.5X speed while racing to work, wearing Apple Watches to ensure they’re hitting 10,000 daily steps, peeking at work email under the dinner table. We’ve become like the coders themselves, torquing every gear in our lives to remove friction. Like any good engineer, we can make the machines of our lives run awfully fast, though it’s not clear we’re happy with where we’re going.

Adapted from Coders: The Making of a New Tribe and the Remaking of the World, by Clive Thompson, to be published March 26, 2019, by Penguin Press, an imprint of Penguin Publishing Group, a division of Penguin Random House LLC.

Clive Thompson (@pomeranian99) is a WIRED contributing editor.

This article appears in the April issue. Subscribe now.

Let us know what you think about this article. Submit a letter to the editor at mail@wired.com.

More Great WIRED Stories

• “We’re in the business of programming people’s lives“
• How Tesla’s Model Y compares to other electric SUVs
• Meet Romania’s very internet-savvy witch community
• Facebook can make VR avatars move exactly like you
• I embraced screen time with my daughter—and I love it
• 👀 Looking for the latest gadgets? Check out our latest buying guides and best deals all year round
• 📩 Want more? Sign up for our daily newsletter and never miss our latest and greatest stories