by
Peter Seibel
View all notes
Available query params: commented=1, untagged=1
[...] the other guy was programming the way he had wanted to program but with a different spin. So he saw what happens when one very intense, very good programmer doesn't segment it down. You get one very long program—it's not that the program was spaghetti code but there were just so many levels of complexity in this one linear suite. He almost pissed me off because, as I say, he went over my head to demand that the department had to have standards to not allow that thing to happen.
Seibel: Not realizing that his own previous code would've probably fallen afoul of the same standards?
Cosell: No. He got that. He was a convert. It's sort of like the guys who give up smoking and are the most pains in the butt about other people still smoking. He became one of the strongest guys on my project. He used to nag me when I wasn't careful enough—when I compromised. My project was the first project of its type he had ever worked on. Communications, real time, all this stuff—all new to him. But he was a smart guy and he went through this little epiphany and came out of it the programmer I always thought he was going to be. Last I heard, he was doing wonderfully. With him it worked out. Other people didn't like working with me because they found me too overbearing; I can't imagine why.
I don't know why I had those two convictions. I arrived at BBN with no skill per se, but I had those principles in the back of my head for some reason. I thought I ought to be able to understand anything and it shouldn't be so hard. I found that even for the time-sharing system and the IMPs—for all of those class of programs, that proved to be true. In general once I had the right understanding of what a program was supposed to do, the pieces would fall into place. The pieces that didn't belong would stand out like a miscolored piece in a jigsaw puzzle.
Another principle was I always wanted clean listings. I wanted the thing to be just right. When you have to fix a bug in a program you never, ever fix the bug in the place where you find it. My rule is, “If you knew then what you know now about the fact that this piece of code is broken, how would you have organized this piece of the routine?” What were you thinking about wrong before? Fix the code so that can't happen. When you finish with a routine I want every routine you work on to look as if it was just written. I do not want to see any evidence of afterthoughts or things gone wrong followed by something to correct the error or a mysterious piece of code saying, “This routine returns the wrong value every now and then so I've got to fix it.” I don't want to see any of that. I want to see code that looks like through some divine inspiration you got it exactly right the first time.
The problem is that coding isn't fun if all you can do is call things out of a library, if you can't write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who'd want to go into that as a career?
There's this overemphasis on reusable software where you never get to open up the box and see what's inside the box. It's nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what's inside the box. Instead people make these closed wrappers around everything and present the closure to the programmers of the world, and the programmers of the world aren't allowed to diddle with that. All they're able to do is assemble the parts. And so you remember that when you call this subroutine you put x0, y0, x1, y1 but when you call this subroutine it's x0, x1, y0, y1. You get that right, and that's your job.
or like using copilot lol
This sense of magical control can be intoxicating and fun; it lends itself frequently to a sort of starry-eyed idealism. And it can also lead, particularly in younger coders—who’ve yet to be humbled by life and their own screw-ups—to some epic hubris. People who excel at programming, notes the coder and tech-culture critic Maciej Cegłowski, often “become convinced that they have a unique ability to understand any kind of system at all, from first principles, without prior training, thanks to their superior powers of analysis. Success in the artificially constructed world of software design promotes a dangerous confidence.” Or as the computer scientist Joseph Weizenbaum noted in 1976, “one would have to be astonished if Lord Acton’s observation that power corrupts were not to apply in an environment in which omnipotence is so easily achievable.”
true
It is accompanied by its close cousin, a fierce devotion to efficiency. 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. (Sanghvi even extended this to her nuptials. Her mother wanted to arrange Sanghvi’s marriage in India, and Sanghvi agreed, because it struck her as far more efficient than dating—which you could regard, from a purely computer-scientific point of view, as a woefully resource-intensive sorting algorithm. “I was a big fan of arranged marriages,” as she said once in a speech. “It appealed to the engineer in me. They’re practical, and they had a higher probability of succeeding.”)
like that cryptonomicon bit where lawrence forgets the code to the safe because it's more important to have a safe-breaking algorithm <3
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. (A study in the ’80s concluded that coders were “less loyal to their employers than to their profession.”) Even in the bowels of the most rapaciously capitalistic Silicon Valley firm are coders who spend a lot of time—at their desk, at work—helping solve the bugs of other randos. And there’s often a communitarian spirit in the worlds of free and open source software, where coders often contribute work freely, to software that anyone can also use themselves, freely.
But crucially, nobody was telling them what to program or what not to program. They were the first group of coders who used the machines to do things that were simply whimsical or creative. They’d get the machines to play music by writing code that turned the vibrating speaker on and off at different frequencies. They’d write programs to calculate chess moves, one of which eventually beat an actual human. Russell wrote Spacewar!, one of the world’s first graphical computer games, in which two players each piloted a ship around a black hole, trying to shoot the other. Using a $120,000 machine to play a video game would likely have seemed, to computer-makers at the time, a madly frivolous thing to do. But the MIT hackers regarded themselves as liberating programming from its mundane history of mere bean counting and scientific problem-solving. Coding itself, they felt, was a playful, artistic act.
The Niagara of money in Silicon Valley, though, has been bringing in a new breed of coder that cared considerably less. By the late ’00s, the example of companies like Instagram—minting so many multimillionaires by making something that Facebook or Google might buy—caught the attention of a new breed of striver, one that we might call the Ivy League frat boys. In previous generations, they’d head for Wall Street, hungry to make quick millions. After the financial collapse of 2008, they needed a new field and found it in Silicon Valley. These “brogrammers” who began to show up, some straight from the frat house, weren’t even concerned about the impact of their code; they weren’t even necessarily interested in the intellectual thrill of the work, frankly. For them, the industry was purely a route to power. It’s safe to say that overall this new population has made less of a contribution to coding than to the overall culture of Silicon Valley.
This is the same sort of objective pride that coders often take when they’ve got something working. On the flip side, it’s also part of what can render them arrogant and dickish. You can convince yourself that what you’re doing is real work, and everyone else—the folks in marketing or sales or management—are just pencil pushers who don’t truly produce anything. (Ooooh, the marketing folks say they’ve increased the firm’s “mind share.” The coders will sit, unimpressed, arms crossed, asking: Can anyone really prove that’s true?) From the perspective of a really linear-minded coder, people who are involved in so-called soft-skills work are constantly hiding behind PowerPoint presentations because they can’t actually demonstrate that they’ve accomplished anything of merit. They’re just slinging buzzwords. This attitude can be a particular hazard among younger programmers fresh out of school, who haven’t yet realized the value of all their nontechnical colleagues—the others who are frantically selling and organizing and keeping the company from falling apart. (“I remember as a young programmer going to staff meetings, my eyes glazing over as some big-shot leader with whom I would never directly work showed chart after chart of numbers that I believed to be completely irrelevant to me,” as Chad Fowler, a longtime coder, wrote ruefully in his book The Passionate Programmer. “My teammates sat together, looking like a row of squirming children on a long car ride. None of us understood what was being presented, and none of us cared. We blamed what we felt was a complete waste of time on the incompetent managers who had called the meeting. Looking back on it, I realize how foolish we were.”)
heh
“I tell people, you always take pride in your code. You should always be refactoring it, it should look like you’ve been working on it, when people see it,” he said. A single flabbily written function would convey something other than total commitment to the craft. “I’m a firm believer in the broken-windows theory. You find a bug, you hunt it down and kill it.” Indeed, when Cohen was working hard, he hated anything that took him out of the flow, even eating. While making himself a sandwich in his kitchen, back when I visited him for Wired, he complained that it was taking too long. “Sometimes I wish there were just some way to install energy in your body, like the Terminator putting a battery in his chest,” he said.
i like this