I’ve been reading some more essays on software engineering and computer programming lately, from the three following books. Here’s a brief synopsis and some of my thoughts on each:
The back jacket of this book describes Douglas Rushkoff as an author and media theorist – not as a programmer, which should be a yellow flag for anyone coming to this text looking for pragmatic programming advice.
That said, he offers an easily digestible summary of trends in internet technology, and where he thinks society as a whole would benefit most if certain standards of thought were subscribed to in the future. Many of his concepts are agreeable, if a little alarmist. (Which is okay, because I think I might be turning into a bit of an alarmist myself.)
I think the most important message Rushkoff is trying to send is one that communicates the significance of the current moment in the history of human communication and cognition. He offers ten bullet points for how to get out in front of the avalanche.
“We are not just extending human agency through a new linguistic or communications system. We are replicating the very function of cognition through external, extra-human mechanisms. These tools are not mere extensions of the will of some individual or group, but tools that have the ability to think and operate.”
His response to these ‘extra-human mechanisms’ are ten ‘commands’ for how to navigate the new normal. Instead of letting the programs affect their logic into our own biologic cycles, he warns that we must continue to be in charge. A few of his ‘commands’ –
- Time: We Must Not Always Be On.
- Place: Live in Person. There is No Substitute for In-Person Interaction.
- Discrete: Everything Is a Choice. You May Always Choose None of the Above.
- Identity: Always Be Yourself. Accountability Must Exist Online.
- Openness: Share. Don’t Steal.
Rushkoff makes several statements about why it is so important to be careful in how society progresses alongside internet technology, but the one that struck me most was an analogy that might be stretching the limits of fair comparison – he compares people not learning programming, to people over the last few decades not understanding how their cars work.
He lists all the gripes about the modern automobile situation in the United States, identifying sprawl, environmental hazard, stress of drivers, accidents, etc., and proposes that all these negative things could have been avoided if people would have spent more time wondering how cars work and what they do instead of just getting in and driving them.
Therefore, he says, everyone should know how to program, so that sixty years from now we aren’t stuck in a debate about how to fix all the problems that poor programming has caused, or how to catch up with the other nations who have advanced past America in their programming ability, etc.
His argument isn’t ridiculous – he’s saying that by blindly accepting the technologies, we blindly accept the risks and dangers they bring with them – but these seem like two different animals.
I like the idea, and I agree with some of the sentiment, especially that automobile culture has created an environment with just as many new problems as solutions to old ones – but I disagree on where to lay the blame.
Not everyone is meant to be a programmer, just like not everyone should be a Navy Seal, a mural painter, or a tour de France cyclist. it requires a person with a unique set of skills and personality.
The automobile problems society has now seem to me as much the result of poor land use decisions, mismanaged federal funding, and urban planning as they are the result of ‘people not knowing how their cars worked.’ How can that claim even be justified? How can you measure what would be different if people had ‘known how their cars worked?’
If Rushkoff is arguing we should all learn to program for the purpose of being able to check off the box, and have our asses covered later just in case someone needs to take the fall for writing bad programs – why is he choosing the actual programming layer as the thing society must learn?
There are so many components and pieces of modern technology that make the internet work, from the electrical engineering in circuit boards to the network infrastructure of fiber optic cable, that correlating programming to world-saving feels like a weak handed grab at one small piece of something that happens to be currently fashionable. Programming just seems like an easy target because it’s the most popular.
Unlike Rushkoff, Graham hasn’t written this book as a treatise for an entire society to absorb and go forth with. Graham’s ideas don’t feel forced, or directed at a readership who wouldn’t already understand many of the concepts. He’s not trying to push the envelope as much as make the envelope shinier and easier to read.
In a masterfully clear writing style, Graham lets his intellect run wild through a variety of topics. He observes ‘Why Nerds are Unpopular,’ in one chapter. He expounds that Startups are the safest bet for wealth generation in another. Choosing an operating system, finding the ‘perfect’ programming language, and why income inequality is a positive thing in society, are all topics treated with their own essays.
Graham doesn’t make any bold statements in these essays that shares Rushkoff’s sentiment that programming should be a giant rainbow on which every type of person in the world can dance – on the contrary, Graham comes across as more likely to believe that programming should only be done by people who want to do it, and who understand how to do it, and everyone else should stick to the things they are good at.
In his ‘Nerds’ essay, he outlines the formative experiences of programmers (nerds) in school, and how their outcast separation from others lays the foundation for them to be successful when they enter the ‘real’ world.
The most interesting chapter for me was the exploration of wealth inequality in America. Graham argues that the only logical way to reduce income inequality is to take money from the rich – and that to do so damages the entire economy.
If inequality were solved by taking money from the wealthy and handing it over to the poor, Graham states, the wealthy would have none left to invest, Startups would disappear, technological growth would halt, and society would stagnate.
Graham’s proposed alternative is not to attack wealth itself, but the corruption that it so often enables. If you kill corruption, the wealthy will continue to grow small businesses. If you kill wealth, for the sake of redistribution, then everything that wealth enables dies alongside it.
His argument earns its credence from his own experience in capital growth – Graham built one of the internet’s first e-commerce platforms, which was later acquired by Yahoo!, minting him with great riches.
In turn, he founded the Y Combinator, a place for Startups to network, incubate, and find investors. He proves his inequality argument by outlining the way his new wealth helped to create more where it didn’t previously exist.
Ullman, author of ‘The Bug’ (Finalist for the PEN/Faulkner award) drapes her tales of computer life in savory detail and lucid prose. She finds a way of paying computers their due respect, while concurrently reminding the reader that programs are unnatural, dumb and fragile tools, driven by the peculiarities of the programmer’s mind.
Unlike Rushkoff, Ullman finds solace in placing a distance between herself and the goal of a program. Where Rushkoff wants to insert himself and his ethics and his sense of right and wrong into programs, Ullman wants to back far away.
Describing a project she worked on in which she was tasked with building a registry for AIDS patients, she speaks of the system users and their “fleshy existence” as a distraction, something that must be ignored in order to create the program.
She writes of coding the AIDS registry:
“Real, death-inducing viruses do not travel here. Actual human confusions cannot live here. Everything we want accomplished, everything the system is to provide, must be denatured in its crossing to the machine, or else the system will die.”
Neither Rushkoff or Graham would seem as ready as Ullman to portray themselves as freaks – while Graham makes ample reference to the history of Nerdism, and takes up personal residency there, he hints at none the fear or anxiety that Ullman experiences as she contemplates what motivates the programming mind.
“I’m upset, so I’m taking apart my computers,” she writes. “If I were a poet, I would get drunk and yell at the people I love. As it is, I’m gutting my machines… there’s a perverse comfort in broken machinery.”
Ullman’s focus on physicality between person and machine is unique. Her relationships with the objects carry more significance than any that Graham or Rushkoff mention, and she finds contrast between that ‘closeness’ and the dislocation felt by many who live their day to day lives online.
In one of the books most poignant moments, Ullman tours real estate that she and her sister inherited from their deceased father. One of her newly inherited tenants, a purse shop owner on Wall Street in Manhattan, explains to her that his business is failing, “because of the modems.” According to the shop owner, Wall Street managers who used to stop in and buy bags are all telecommuting from Connecticut now, while the remaining customers are ‘of a different class.‘
Ullman recoils at the idea her profession, programming, building applications for remote communication, is the root of failure in the businesses supported by her father. She mourns at what feels like her father’s generation’s work evaporating.
“In my world, it was so easy to forget the empty downtowns. The whole profession encouraged us: stay here, alone, home by this nifty color monitor. Just click. Everything you want – it’s just a click away. Everything in my world made me want to forget how – as landlord, as programmer, as landlord/programmer helping to unpeople buildings like my very own – I was implicated in the fate of Morty and the bag shop.”
Her resistance to hail computers as mankind’s last savior (a line tiptoed by Rushkoff and Graham) is all the more authoritative given her experience as a programmer.
She writes of her pedigree – “I have taught myself six higher-level programming languages, three assemblers, two data-retrieval languages, eight job-processing languages, seventeen scripting languages, ten types of macros, two objects-definition languages, sixty-eight programming library interfaces, five varietys of networks, and eight operating systems.”
In contrast, Graham spends a lengthy chapter huzzah’ing the merits of a single programming language, LISP, while Rushkoff mentions nary a learned language under his own belt.