Ho, as it turned out, had a very strict and peculiar itinerary planned for the trip. He’s particularly fond of ramen-noodle dishes, and his goal on this jaunt, he told her, was to visit as many Tokyo ramen shops as possible. To make sure they crammed in as many as they could, he’d created some custom code. Huh? she thought. He explained: First, he’d assembled a list of top Tokyo noodle places and plotted them on a Google Map. Then he’d written code that drew the optimum pathway that connected all the shops, so they could travel in the most efficient route between them. It was, he said, a “pretty traditional” algorithmic challenge, of the sort you learn in college, and he used tricks like this all the time to optimize the way he lived his life. He whipped out his phone to show her the map. He told her he was planning on keeping careful notes about the quality of each meal, too.

“Anytime I have to repeat something over and over,” he told me, “I get bored.” In his final year of college, he decided that the whole structure of the college system was weirdly inefficient: You had kids taking basically the same classes at different institutions, often with the same lessons, running into the same problems with their work. But these far-flung students didn’t have any easy way to talk together. He put together Qaboom.com, a question-answering site that tried to cluster students across the US by common subjects. Though a few investors in Silicon Valley liked it, it never took off because Ho couldn’t crack the cultural piece: how to get students to post good-quality questions and answers. As a coder, he was concerned with making the site so elegantly designed and robust that it would scale. But since nobody was posting anything, a million people would never show up, he realized. Content mattered, and he didn’t really know how to get that snowball rolling. He shut the site down and, his degree program nearly over, interviewed at a few firms like Google. But he sunk into a funk. He didn’t want to work for someone else. Considered 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. He had the skills to build something, soup to nuts—these “magical powers.” He just needed to find something that needed that gift.

She had also, in the two years they’d been together, discovered that Ho’s obsessive habit of optimizing everything could leak into almost every part of his life. When he decided to buy a house, he didn’t want to sit around going house by house and pondering whether to buy it. So he wrote a little piece of software into which he could dump the information for scores of San Francisco homes—like their locations, prices, and neighborhood statistics—and it would calculate its probable long-term value. (The program recommended a top pick; he duly bought it, and currently lives in it.) Because he hates shopping, he bought dozens of pairs of the same T-shirt and khakis—which, as he notes, also removes any decision-making time when dressing in the morning. A few years ago, tired of being out of shape, he decided to take up bodybuilding, since it seemed like a particularly demented optimization challenge. He began whipping out a food-scale at restaurants to weigh his portions, and devising ways to fit exercise into nearly any part of his day. If he passed a thick metal crosswalk bar, he’d use it to do pull-ups; if he passed a dumpster, he’d lift it up on one edge.

Programmers are obsessed with efficiency. It is the one thing I’ve encountered in essentially every coder I’ve met. Coders might be wildly diverse in other ways—politically, socially, culturally, what have you. But nearly every one found deep, almost soulful pleasure in taking something inefficient and ratcheting it up a notch. Removing the friction from a system is an aesthetic joy; their eyes blaze when they talk about making something run faster, or how they eliminated some bothersome human effort from a process.

The upshot is that most coders arrive at the same logic, which we could summarize thusly: (a) Doing things repeatedly or at the same time every day is boring, and I’m terrible at it. By contrast, (b) slavishly and meticulously doing the same task again and again is easy for the deathless machine sitting on my desk. Thus, (c) I am going to automate every single thing I possibly can.

Eventually, of course, that orientation has a way of bleeding into your everyday life. It becomes hard to turn off, like X-ray vision. “Most engineers I know go through life seeing inefficiencies everywhere,” as Christina, a coder in San Francisco, once told me. “Inefficiencies boarding your planes, whatever. You just get sick of shit being broken. ‘Hi, this isn’t good, and I’m going to fix it!’” She’ll even find herself wishing people navigated the sidewalks and street crossings in a more optimal fashion. “It’s a fundamental kind of dissatisfaction with the way things are currently running,” she says. Jeannette Wing, a professor of computer science—currently running the Data Science Institute of Columbia University—popularized the phrase “computational thinking.” It’s the art of seeing the invisible systems in the world around you, the rule sets and design decisions that govern how we live. And it often leads her, too, to notice subpar organization around her.

“Whenever I get to a lunch buffet,” she says, “I get annoyed when the stations of a buffet are not lined up properly. So when they put the forks and the knives with the thing wrapped around it as the first thing? I find that annoying! Because you have to hold your plate while you hold this thing of knives and forks, too. The cutlery should be at the end! So this buffet is really this linear sequence of stations, and you want it to be sensible. You don’t want a lot of latency.” It’s a classic bit of optimization thinking, something that certainly you don’t need to be a coder to appreciate, but which comes to programmers effortlessly, even unstoppably. (Indeed, there’s something about the demands of food preparation, delivery, and cleanup that seem to inspire particular annoyance among hackers—which probably anyone who hates housework could identify with. The programmer Steve Phillips once told me he yearned to robotically automate dish drying, when as a teenager he was helping his mother clean up after dinner. “I grab one off the stack, I dry it, I sit it down, I grab one off the stack, I dry it, I sit it down. It’s like—this should be a for loop. This is pissing me off.”)

Several were on full display in a Quora thread where coders talked about automating everyday life. “I got tired of hearing ‘You never message me’ from friends and family,” as one wrote, so he created a script that would randomly send a text to one of them, created using a Mad Libs–style mash-up. (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 greetings: [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?].) Another programmer translated the tale of a Russian coder who’d written a script to automatically send a “late at work” message to his partner if he were still there at 9:00 p.m. (with a randomly generated reason affixed) as well as a program that turned on the latte machine in his company’s kitchen and commanded it to brew a “midsized half-caf latte,” to be ready in 41 seconds. (“The timing is exactly how long it takes to walk to the machine from the dude’s desk,” his colleague marveled.) At a hackathon in San Francisco, a middle-aged coder excitedly showed me an app he’d created that would send romantic messages, culled from online quote-databases, to a partner. “So when you don’t have time to think about her”—and, yep, he assumed the emotionally needy partner is a “her”—“this app can take care of it for you,” he enthused. He seemed only very faintly aware of how nuts it seemed.

“He was supposed to be working on a database migration,” the manager said, “which required a bunch of pain-in-the-ass stuff up front, some scut work of cleaning up data by hand.” It probably should have taken the coder a half day or so; it was a onetime affair, and once he was done he’d never have to do it again. But he hated the idea of wasting a morning doing dull, repetitive, by-hand work. So he decided to automate it and plunged into the deep end of optimization madness. The program manager kept on walking by the coder’s cubicle and seeing the guy diligently at work, head down, headphones on, cranking away. But when the manager checked in two weeks later (“my fault, bad management, I should have been checking in every couple of days”), he found the migration was still totally incomplete. The coder hadn’t finished it. He was still meticulously crafting, tweaking, and perfecting a tool to automate that first step, the data cleanup. He’d blown half the month trying to make a tool just to avoid doing three hours of drudgery. “We were now totally behind schedule, but he was all like, hey, I have this awesome tool now!” the manager said, and sighed.

The programmer Bryan Cantrill notes that coders vastly prefer to figure out the cleanest fix for a bug, some solution that will neatly deal with every possible situation the software might face. When they can’t do that—maybe they don’t have the time, or maybe the bug simply defeats them—they’ll reluctantly use an inelegant solution: a sprawling bunch of lines that deal with the four specific fail-conditions, the strange edge cases they’re aware of, and they’ll just cross their fingers and pray there aren’t more edge cases out there lurking. Technically, they’ll have solved their problem. But they’ll hate themselves so much that they’ll often add a comment next to their solution, castigating themselves—and calling their code “gross,” “disgusting,” or “vile.” For programmers, inefficient code is an offense to the soul.

Soylent is, in many ways, a perfect metonym of the software engineers’ obsession for efficiency. It’s what you get when that worldview—speed everything up, remove friction everywhere—becomes second nature, a twitch instinct. Each moment of life becomes a target for Taylorization, a world of nails to be hammered into submission. Everything should move as rapidly as possible: communicating, working, shopping. Indeed, Amazon’s success is predicated on rendering life into a carousel of instant gratification, as the computer engineer and director Ruhi Sarikaya notes: “Friction is any variable that impedes your progress toward a goal, whether it’s purchasing a product or navigating traffic to make your nine a.m. meeting on time. Amazon is obsessively focused on reducing or eliminating friction—think one-click ordering, Amazon Prime, or Amazon Go.”

This fetish for efficiency is what has driven the delirious explosion of “on demand” services. By the mid-2010s, Silicon Valley entrepreneurs started flooding the market with apps designed to optimize nearly every fiddly task of everyday life—offering to do work so you didn’t. There was Washio (a service that dispatched laundry “ninjas” to pick up your dirty clothes), Handy (on-demand apartment neatening), Instacart (to pick up items from the local grocery store), and the endless phalanxes of TaskRabbits (to do basically anything else for you).