Since they have, at their beck and call, machines that can repeat instructions with robotic perfection, coders take a dim view of doing things repetitively themselves. They have a dislike of inefficiency that is almost aesthetic—they recoil from it as if from a disgusting smell. Any opportunity they have to automate a process, to do something more efficiently, they will.
Code makes efficiency and scale easy, seductive, almost inevitable. That is also why programmers fit so easily into business building and part of why some slide so frequently into libertarian thinking. Their talents are torqued perfectly for capitalism’s central trick, which is, basically, “do something marginally more efficiently than before and then skim off the profit.” Mind you, software also, by its very nature, weird-ifies a lot of the assumptions of capitalism. A piece of software is a thing, a machine that does something, so you can own it; but because it’s also a form of speech, it can be easily shared. And so it is shared, almost incessantly. Coders are remarkably chatty and open about their everyday work, regularly posting their software problems to online forums and spending hours helping other people solve theirs.
Most coding is about breaking a big, hard task down into small pieces. You don’t write one big honking program at one go; you write little chunks of code, small subroutines—functions, modules—that, when chained together, accomplish the big task. You go piece by piece, testing as you go. You get a little “win” every time a function passes its test. The upshot is that this can produce a remarkably soothing sense of progress. Research by the Harvard professor Teresa M. Amabile and researcher Steven J. Kramer has found that employees are happiest at jobs where they experience “the power of small wins”—regular, daily, visible progress. They hate it when they have only a fuzzy sense of accomplishment. But if, every day, they experience some concrete moment of success, they’re thrilled. Coding gave me precisely that sense of linear, regular achievement. Writing rarely did. Producing a book always feels more like piloting a boat across a foggy lake. I know I’ll eventually arrive at my destination, but the voyage will be filled with nail-biting doubt about my bearings.
Among the INTJs
This comparison to deepsea diving is revealing, because many programmers have told me the same thing. “Most of the time, we’re not snippy or weird or overly logical,” they say. It’s just that they turn into terrifying robots during the actual act of coding. This is because of the peculiarly taxing mental demands of the discipline. Debugging a piece of code is more than just staring at those few lines and trying to figure out why they’re wrong. No, it often requires thinking about the enormous hairball of the entire system: how those few lines interact with dozens or hundreds of other modules of code—each one passing bits of data back and forth. You start with one function; see what other pieces of code it talks to; figure out which pieces of code those functions talk to. Slowly, slowly, you can begin to build up a mental picture of the many-nested interrelations. After a long effort, you finally load the system’s Byzantine logic into your mind’s eye; you can see how the Rube Goldberg mechanisms work, how this ball knocks over that domino that causes this switch to flick, turning on that light. Or to use a slightly different metaphor, you’ve soared high enough in the air that you can see the entire city arrayed before you at night. You can see the Matrix. And it is at this point that programmers can actually get serious work done, because they understand the implications of changing any tiny part of the mechanism.
Coders typically told me it takes many minutes to get into that state, but for really gnarly coding problems it can take hours. Once you’re there, though, it’s glorious. Doing coding when the program is arrayed in your wetware is deeply pleasant. It is a classic “flow” state identified by the psychologist Mihály Csíkszentmihályi—where one is “completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you’re using your skills to the utmost.” But it’s also an amazingly fragile state. The slightest interruption, and that carefully assembled understanding can vanish in a puff. Thus, the one thing that drives coders into a blind fury is someone pinging them when they’re in the zone. They’re trying desperately to maintain an ethereal crystal lattice in their minds, and now somebody is asking them, Hey, did you get that email I sent you?, and poof, it’s gone.
“My wife and kids have learned that when I’m in my room coding, you really can’t interrupt me, or else you get this completely different father and husband,” as one developer for a social network told me. He’s colder, sharper, and usually deeply distressed that the trance has been broken. Many coders who work from home described the same problem. “I often become very black and white, very logical,” said another one who’s worked in machine vision. Interrupt him midwork and he tries to compress the interaction to a binary variable: Can you give me a yes/no question? The rest of the time, he thinks, he’s a perfectly nice guy. But the act of coding transforms him. Interrupt him at your peril. And so while they’re working, programmers tend to do everything they can to wall off other people, because other people are, in essence, nothing but distractions. They slap on noise-canceling headphones; some save their hard work for the wee hours of the night, when calls and messaging and even political-news tickers fall silent.
Indeed, coder workflows are deeply Romantic, in the original sense of the word. If you brought a bunch of coders back to meet the nineteenth-century Mary Shelley or Lord Bryon, they’d warmly agree that one’s best work is done in a remote garret on a rocky promontory.
Coders are white-collar workers, but the need for deep immersion and concentration puts them at sharp odds with most white-collar rhythms. Paul Graham refers to it as the collision between the “maker’s schedule” and the “manager’s schedule.” The work of managers, he points out, is composed almost entirely of meetings. Managers’ jobs are to make sure things are going well, so they block out their day in one-hour increments, meeting with a different employee every hour. So they think nothing of asking a coder to come in at 1:00 p.m. and have a check-in meeting. But for the coders, that meeting destroys any chance of getting into a long flow state. “I find one meeting can sometimes affect a whole day,” Graham wrote. “A meeting commonly blows at least half a day by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.”
The Cult of Efficiency
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. That combination, that shining-eyed ardor for efficiency and order that manages to be admirable while also completely bonkers, is a heat signature of the engineering mind-set.
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.
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.
And of course, the zeal for optimization can reach into social and emotional relations, too. After all, dealing with the fellow humans around you—saying hi to them, asking how their day is going, listening to partners complain about their day—requires one-on-one attention. It’s constitutionally inefficient; the whole point behind taking emotional care of someone else is to slow down and attend to them. For the set of coders who are already terrible at emotional work—or who regard it as beneath them, or who are simply baffled by it—the instinct is: Well, let’s automate our everyday emotional work, too. It can produce a set of efficiency ploys that can be unsettling, if morbidly fascinating in their ingenuity.
Linguists and psychologists have long documented the value of phatic communications—the various emotion gambits we humans use in everyday life to make those around us feel at ease or listened to: How’s it going? Crazy weather, eh? What’re you up to tonight? The more I talked to coders, the more stories I heard of programmer colleagues who found that stuff as irritating as grit in the otherwise frictionless gears of their daily lives.
Konrad Zuse, the inventor of the first digital computer, once argued that people wielding computers would be affected deeply by that exposure. “The danger that computers will become like humans,” he noted, “is not as great as the danger that humans will become like computers.”
I began to notice this zeal for optimization myself. The more I dabbled in coding, the more I began to notice, and be deeply annoyed by, moments of inefficiency in my daily affairs.
When programmers talk about the efficiency of code, the language is aesthetics, and how software appeals to the senses. Code that’s efficient and well organized is “clean,” “beautiful,” “elegant”—metaphors of visual art, the delights of the eye. But when code is a slow, wretchedly designed mess that’s hard to maintain, programmers talk about stench. The metaphor becomes olfactory, the swill of gases that rise from rot and decay.
This shift from the eye to the nose strikes me as funny, and revealing. Because the goodness of good code is regarded as something visible, it suggests the beauty of structure, something before which you stand in awe: a ticking watch work, a suspension bridge, a Modigliani. The point is to admire the artifice, the made-ness of the thing. But by associating bad code with odor, suddenly we’re in the world of organic matter, of rotting fish and stale milk, of suspicion that something is wrong somewhere, hidden where we can’t see it. Or the world of morality: Researchers are increasingly finding that we associate terrible smells with ideas or politics that offend us.
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.
10X, Rock Stars, and the Myth of Meritocracy
The reason so few people can have such an outsize impact, Andreessen argues, is that when you’re creating a weird new prototype of an app, the mental castle building is most efficiently done inside one or two isolated brains. The 10X productivity comes from being in the zone and staying there and from having a remarkable ability to visualize a complex architecture. “If they’re physically capable of staying awake, they can get really far,” he says. “The limits are awake time. It takes you two hours to get the whole thing loaded into your head, and then you get like 10 or 12 or 14 hours where you can function at that level.” The 10Xers he has known also tend to be “systems thinkers,” insatiably curious about every part of the technology stack, from the way currents flow in computer processors to the latency of touchscreen button presses. “It’s some combination of curiosity, drive, and the need to understand. They find it intolerable if they don’t understand some part of how the system works.” This is why 10Xers love start-ups. It’s where, starting from a fresh page, they can peacock and show off what they can do. In contrast, many big and established firms require a slower pace.
Contributing to a popular open source project is usually a career-enhancing move, which is why so many coders try to get involved in one. It’s also why so many release their weekend just-for-fun side-projects as open source code on sites like GitHub. There’s the pleasure of letting others see your work, the joy of discovering that some weird tool you crafted for yourself is also useful for others; plus, you can learn a lot from looking at other people’s open code and seeing how they built things. Coders also told me they felt an ecological sense of obligation: They open source their own code—and contribute to other people’s projects—as a way of giving back to a scene that has helped them out. Virtually every coder I’ve met uses tons of open source code at work; million-dollar businesses are routinely built on top of open source code. Open source thus contains a curious combination of motivations—an Adam Smithian competition to impress, blended inextricably with a communitarian ethos that might make Karl Marx smile. And through it all is the ideal that, well, the code doesn’t lie: If it’s good, your fellow programmers will see it and accept it.
Coders and techies, certainly in the US, have a reputation for leaning libertarian—which we could define here very loosely as believing that each person is responsible for their own fate, that government regulations generally stifle liberty, and that society is best served by letting the best rise by their own efforts. Why? It’s partly because some iconic tech CEOs espouse libertarian stances so stark they practically come off as cat-stroking Bond villains. Peter Thiel, perhaps the best-known example of this phenomenon, is a man so committed to his loathing of “confiscatory taxes” that he once explored the possibility of “seasteading”—creating a floating city beyond the reach of the weary giants of flesh and steel. He’s also proclaimed, “I no longer believe that freedom and democracy are compatible.”
At first blush, it’s not hard to figure out why there’d be a strong Venn overlap between coders and libertarians. Both inhabit realms where first principles and logic are heavily touted. They’re also arenas heavily populated by young guys—who often have little experience with the messy priors and injustices of the real world, and thus are prone to breezily hand wave these aside. In the programming scene of the ’80s and ’90s, “I think you had a lot of people who were poorly socialized, they liked formal systems, they like solving problems,” as the Netscape coder Jamie Zawinski tells me. He thinks the philosophy is naive, but he gets why coders are drawn to it: “Libertarianism is nothing if not coldly logical, right?” Google’s Peter Norvig, who’s been programming since the ’70s, adds that libertarianism is probably also just a function of how relatively well-off coders are: “I think everybody who has a job as a programmer has a comfortable life and so that means, for some of them, this libertarian approach is attractive because they’re saying, ‘Let’s just get government out of the way. I’d be fine without it. Therefore, everybody else will be fine without it too.’”
If we wanted to synthesize it, we could view tech founders as people who are aware that people can fall through the cracks of a capitalist economy—and even that “disruption” can wreak havoc in the lives of the average Joe and Jane. But tech leaders are also themselves devoutly committed to creating those disruptions: Amazon’s online sales leading to the shuttering of local stores, Uber and the on-demand world producing a patchwork of unreliable “gig” labor, automation destroying entire classes of jobs, such as legal assistants. Nonetheless, tech founders fundamentally believe that talent and merit and innovation—as they define it, anyway—shouldn’t be restrained a whit. So they square that circle by supporting redistributive policies that attempt to make madcap disruption vaguely survivable. Hence the approval of universal health care—or even universal basic income, something that’s a warmly approved talking point at tech conferences. They’re happy to share some of the wealth via taxation but want to ensure nothing stops them in their process of how they amass their wealth. They believe that, fundamentally, they know what’s best for society: Their view is “trust us,” as the philosopher and technologist Ian Bogost says. And of course, it’s a redistributionist view that leaves their political power intact. Workers getting handouts from a small coterie of stratospherically wealthy 1 percenters are not liable to form any sort of strong counterweight to the power of tech giants. The vision is, in essence, that of a digital-age version of the robber baron.
Hackers, Crackers, and Freedom Fighters
In this part of the coder world, they’re meticulous with their terminology. Hacker is used in its traditional meaning: a curious type who loves tinkering with systems, getting them to do new and weird things, and sometimes finding weak points—but generally within the law, white-hat style. A “cracker,” by contrast, is one who breaks into systems for personal gain or crime. (Everyone here is deeply annoyed that in the mainstream imagination and mass media, “hacker” has become indistinguishable with illegal acts.) Cypherpunk, though? That’s a term they can all get behind. It’s a blend of the old word cyberpunk with cypher—the code making and code breaking of computer cryptography—and, to my ears anyway, a dash of the “punk” of punk rock: people who do things in a DIY fashion, operating outside the mainstream. It’s hacking to protect civil liberties. In a world where more and more of our conversation takes place digitally, the cypherpunks see encryption as crucial to civic autonomy.
Purely as a statement of fact, it’s true that crypto protects malefactors as equally as it protects freedom fighters. There’s no way to create crypto math that gives privacy to only the “good” people. The cypherpunks all know this. Most are perfectly fine with it; freedom means freedom to do not just good things but bad ones. Their willingness to say this up front can be startling, or refreshing, depending on your political point of view. While speaking on a panel at a security conference, the crypto hacker Moxie Marlinspike—creator of the Signal messaging app—argued that making things occasionally easier for lawbreakers was an acceptable cost for securing everyone’s privacy. “I actually think that law enforcement should be difficult. And I think it should actually be possible to break the law,” he said. Or, as he wrote on his blog, it’s only by breaking the law that citizens can discover that some laws are nonsensical. “How could people have decided that marijuana should be legal if nobody had ever used it?” he wrote. “How could states decide that same-sex marriage should be permitted?”