Code

Code has been my life, and it has been your life, too. It is time to understand how it all works.

What is Code?

What is Code? is great interactive longform offering an engaging look at the history of coding and software culture. It takes you from the hardware up to people and culture in an accessible way. For a couple hours of reading, you get a lot of software cultural literacy. See the trees, stacks, graphs, tables, and algorithms all around us. Learn about the frantic pace of learning and disruption in the software world and how small, self-organizing teams using agile methodology plan, build, and verify huge systems in small chunks.

The code behind the webpage is open source and available on GitHub. There’s an issue tracker where volunteer contributors report errors and help improve the code and the text.

Selected quotes

This is real. A Scrum Master in ninja socks has come into your office and said, “We’ve got to budget for apps.” Should it all go pear-shaped, his career will be just fine.

There are lots of other neighborhoods, too: There are people who write code for embedded computers smaller than your thumb. There are people who write the code that runs your TV. There are programmers for everything. They have different cultures, different tribal folklores, that they use to organize their working life. If you told me a systems administrator was taking a juggling class, that would make sense, and I’d expect a product manager to take a trapeze class. I’ve met information architects who list and rank their friendships in spreadsheets. Security research specialists love to party.

Every month it becomes easier to do things that have never been done before, to create new kinds of chaos and find new kinds of order. Even though my math skills will never catch up, I love the work. Every month, code changes the world in some interesting, wonderful, or disturbing way.

A computer is a clock with benefits. They all work the same, doing second-grade math, one step at a time: Tick, take a number and put it in box one. Tick, take another number, put it in box two. Tick, operate (an operation might be addition or subtraction) on those two numbers and put the resulting number in box one. Tick, check if the result is zero, and if it is, go to some other box and follow a new set of instructions.

You, using a pen and paper, can do anything a computer can; you just can’t do those things billions of times per second. And those billions of tiny operations add up. They can cause a phone to boop, elevate an elevator, or redirect a missile. That raw speed makes it possible to pull off not one but multiple sleights of hand, card tricks on top of card tricks.

When you use computers too much—which is to say a typical amount—they start to change you.

The turn-of-last-century British artist William Morris once said you can’t have art without resistance in the materials. The computer and its multifarious peripherals are the materials. The code is the art.

Computers are machines. They don’t know what a screen or an “a” are. To put the “a” on the screen, your computer has to pull the image of the “a” out of its memory as part of a font, an “a” made up of lines and circles. It has to take these lines and circles and render them in a little box of pixels in the part of its memory that manages the screen. So far we have at least three representations of one letter: the signal from the keyboard; the version in memory; and the lines-and-circles version sketched on the screen. We haven’t even considered how to store it, or what happens to the letters to the left and the right when you insert an “a” in the middle of a sentence. Or what “lines and circles” mean when reduced to binary data. There are surprisingly many ways to represent a simple “a.” It’s amazing any of it works at all.

Coders are people who are willing to work backward to that key press. It takes a certain temperament to page through standards documents, manuals, and documentation and read things like “data fields are transmitted least significant bit first” in the interest of understanding why, when you expected “ü,” you keep getting “�.”

If you can sell the software, if you can light up the screen, you’re selling infinitely reproducible nothings. The margins on nothing are great—until other people start selling even cheaper nothings or giving them away. Which is what happened, as free software-based systems such as Linux began to nibble, then devour, the server market, and free-to-use Web-based applications such as Google Apps began to serve as viable replacements for desktop software.

Decades of efforts have gone into helping civilians write code as they might use a calculator or write an e-mail. Nothing yet has done away with developers, developers, developers, developers.

Coders, starting with concepts such as “signals from a keyboard” and “numbers in memory,” created infinitely reproducible units of digital execution that we call software, hoping to meet the needs of the marketplace. Man, did they. The systems they built are used to manage the global economic infrastructure. If coders don’t run the world, they run the things that run the world.

Software is everywhere. It’s gone from a craft of fragile, built-from-scratch custom projects to an industry of standardized parts, where coders absorb and improve upon the labors of their forebears (even if those forebears are one cubicle over).

Coding is a broad human activity, like sport, or writing. When software developers think of coding, most of them are thinking about lines of code in files. They’re handed a problem, think about the problem, write code that will solve the problem, and then expect the computer to turn word into deed.

Computers usually “understand” things by going character by character, bit by bit, transforming the code into other kinds of code as they go.

Trees are a really pleasant way of thinking of the world. Your memo at work has sections that have paragraphs? Tree. Your e-mail program contains messages that contain subject lines and addresses? Tree. Your favorite software program that has a menu bar with individual items that have subitems? Tree. Every day is Arbor Day in Codeville.

Every character truly, truly matters. Every single stupid misplaced semicolon, space where you meant tab, bracket instead of a parenthesis—mistakes can leave the computer in a state of panic. The trees don’t know where to put their leaves. Their roots decay. The boxes don’t stack neatly. For not only are computers as dumb as a billion marbles, they’re also positively Stradivarian in their delicacy.

Little in computing has a single, reliable name, which means everyone is always arguing over semantics.

You may look over a programmer’s shoulder and think the code looks complex and boring, but it’s covering up repetitive boredom that’s unimaginably vast.

Compilation is one of the denser subjects in computer science, because the lower down you go, the more opportunities there are to do deep, weird things that can speed up code significantly—and faster is cheaper and better. You can write elegant, high-level code like F. Scott Fitzgerald, and the computer will compile you into Ernest Hemingway. But compilers often do several passes, turning code into simpler code, then simpler code still, from Fitzgerald, to Hemingway, to Stephen King, to Stephenie Meyer, all the way down to Dan Brown, each phase getting less readable and more repetitive as you go.

Computing treats human language as an arbitrary set of symbols in sequences. It treats music, imagery, and film that way, too.

Maybe you’re reading this in print. No shame in that. In fact, thank you. The paper is the artifact of digital processes. Remember how we put that “a” on screen? See if you can get from some sleepy writer typing that letter on a keyboard in Brooklyn, N.Y., to the paper under your thumb. What framed that fearful symmetry?

“Algorithm” is a word writers invoke to sound smart about technology. Journalists tend to talk about “Facebook’s algorithm” or a “Google algorithm,” which is usually inaccurate. They mean “software.”

Algorithms don’t require computers any more than geometry does. An algorithm solves a problem, and a great algorithm gets a name. Dijkstra’s algorithm, after the famed computer scientist Edsger Dijkstra, finds the shortest path in a graph. By the way, “graph” here doesn’t mean a bar chart but rather a collection of nodes, connected by paths.

Think of a map; streets connect to streets at intersections. It’s a graph! There are graphs all around you. Plumbing, electricity, code compilation, social networks, the Internet, all can be represented as graphs! (Now to monetize …)

In code as in life, ideas grow up inside of languages and spread with them.

A programming language is a system for encoding, naming, and organizing algorithms for reuse and application. It’s an algorithm management system. This is why, despite the hype, it’s silly to say Facebook has an algorithm.

Dijkstra said: “Computer science is no more about computers than astronomy is about telescopes.”

Companies such as Google, Facebook, and Twitter are built on top of fundamental computer science and pay great attention to efficiency, because their users do things (searches, status updates, tweets) an extraordinary number of times. Thus it’s absolutely worth their time to find excellent computer scientists, many with doctorates, who know where all the efficiencies are buried.

It takes a good mathematician to be a computer scientist, but a middling one to be an effective programmer. Until you start dealing with millions of people on a network or you need to blur or sharpen a million photos quickly, you can just use the work of other people. When it gets real, break out the comp sci. When you’re doing anything a hundred trillion times, nanosecond delays add up. Systems slow down, users get cranky, money burns by the barrel.

The hardest work in programming is getting around things that aren’t computable, in finding ways to break impossible tasks into small, possible components, and then creating the impression that the computer is doing something it actually isn’t, like having a human conversation.

Tons of algorithms, bundled up and applied, mean that computers can fake listening.

The DRY principle, for Don’t Repeat Yourself, is one of the colloquial tenets of programming. That is, you should name things once, do things once, create a function once, and let the computer repeat itself. This doesn’t always work. Programmers repeat themselves constantly. I’ve written certain kinds of code a hundred times. This is why DRY is a principle.

He often tells you just how important this panel-speaking is for purposes of recruiting. Who’s to say he is wrong? It costs as much to hire a senior programmer as it does to hire a midlevel executive, so maybe going to conferences is his job, and in the two months he’s been here he’s hired four people. His two most recent hires have been in Boston and Hungary, neither of which is a place where you have an office.

People come together in the dozens or thousands and attend panels, ostensibly to learn; they attend presentations and brush up their skills, but there’s a secondary conference function, one of acculturation. You go to a technology conference to affirm your tribal identity, to transfer out of the throng of dilettantes and into the zone of the professional.

Here’s the other thing about technology conferences: There has been much sexual harassment and much sexist content in conferences. Which is stupid, because computers are dumb rocks lacking genitalia, but there you have it.

Why do people construct and then give away free languages? Well, the creation of a good computer language is the work of an apex programmer. To have produced a successful language is acknowledged as a monumental effort, akin to publishing a multivolume history of a war, or fighting in one. The reward is glory.

Making a new language is hard. Making a popular language is much harder still and requires the smile of fortune. And changing the way a popular language works appears to be one of the most difficult things humans can do, requiring years of coordination to make the standards align. Languages are large, complex, dynamic expressions of human culture.

A language is software for making software.

A coder needs to be able to quickly examine and identify which giant, complex library is the one that’s the most recently and actively updated and the best match for his or her current needs. A coder needs to be a good listener.

Code isn’t just obscure commands in a file. It requires you to have a map in your head, to know where the good libraries, the best documentation, and the most helpful message boards are located. If you don’t know where those things are, you will spend all of your time searching, instead of building cool new things.

There are true benefits to everyone on a team using the same language. They’re all thinking the same way about how to instruct the computer to process data.

It’s not necessary for every team across a big organization to use the same language. In fact, it’s often counterproductive. Large organizations have lots of needs and use many languages and services to meet them.

Programmers spend much of their time dealing with different types of data. Let’s say I have a number x, like 7, and a word y, like “cat.” When I multiply x and y, what’s the result? A runtime error in many languages—because you can’t multiply a number by a word. The language Perl returns a zero, which is expedient but baffling, and JavaScript returns “NaN,” for “not a number.”

How often are you going to be multiplying sevens and cats? Soooo much. The real world of data is messy, so you’re constantly converting one type of thing into another type—and the shading is subtle. Sometimes an e-mail address is just a bunch of letters and symbols; sometimes it’s a field just plucked from a database; sometimes it’s specially prepared to be sent into the Internet. Programmers write a lot of code that converts data from one type to another.

The idiom of a language is part of its communal identity.

You pick a language not just on its technical merits, or its speediness, or the job opportunities it may present, but also on its culture.

Languages have agendas. People glom onto them. Blunt talk is seen as a good quality in a developer, a sign of an “engineering mindset”—spit out every opinion as quickly as possible, the sooner to reach a technical consensus. Expect to be told you’re wrong; expect to tell other people they’re wrong. (Masculine anger, bluntly expressed, is part of the industry.)

Regular meetings can become sniping matches about things that don’t matter. The shorthand term for that is “bikeshedding.” (Who cares what color the bike shed is painted? Well …)

Code culture is very, very broad, but the geographic and cultural core is the Silicon Valley engine of progress. The Valley mythologizes young geniuses with vast sums. To its credit, this culture works; to its shame, it doesn’t work for everyone.

Within 18 months your skills could be, if not quite valueless, suspect.

I was in a meeting once where someone said, “How long will it take to fix that?” One person, who’d been at the company for years, said, “Three months.” A new person, who’d just come from a world of rapidly provisioned cloud microservices, said, “Three minutes.” They were both correct. That’s how change enters into this world. Slowly at first, then on the front page of Hacker News.

Programmers carve out a sliver of cognitive territory for themselves and go to conferences, and yet they know their position is vulnerable.

Is the next great wave swelling somewhere, and will it wash away Java when it comes? Will Go conquer Python? Do I need to learn JavaScript to remain profitable? Programmers are often angry because they’re often scared. We are, most of us, stumbling around with only a few candles to guide the way. We can’t always see the whole system, so we need to puzzle it out, bit by bit, in the dark.

Programming has twin cults of genius and youth.

All kinds of people can be programmers. And autistic people can have all kinds of careers.

For a truly gifted programmer, writing code is a side effect of thought. Their skill isn’t in syntax; it’s how they perceive time and computation. They can see the consequences of their actions more quickly than the next programmer; they spend less time in the dark.

As a class, programmers are easily bored, love novelty, and are obsessed with various forms of productivity enhancement.

And whatever you do, never, ever ask a developer about productivity software.

“Ship” is a cult word.

One of the greatest ship risks is anything shiny.

You also don’t want to create a situation where engineers can’t play around, because then they’ll set up systems behind your back “just for testing.” That’s how Linux spread.

Technical debt is the idea that software often launches without everything buttoned up, to meet deadlines or because some features were prioritized over others, and over time, as systems change and evolve, a kind of code-debt builds up. It’s no different from infrastructure debt. Bridges, tunnels, or tech—to do new things in a compatible way can require painful, wasted effort. Sometimes, to move a system forward, you need to address that debt: Upgrade the balky server, deal with the fact that your user account manager tends to log people out without warning, or occasionally throw away a component and start again.

Or the entire industry will spasm and everything you’ve done will need to be thrown away and rebuilt along new lines anyway. (From desktop to Web, from Web to mobile, from mobile to … quantum? Who knows. But there’s always something.)

Most programming languages are partly a way of expressing things in terms of other things and partly a basic set of given things.

You can pick up the weird metallic smell of large computer centers with raised floors just by looking at some Fortran.

Different computing eras smelled differently. The old, huge machines had a slight burning-metal smell. Early PCs gave off different odors of plastic, metal, and enamel. And who could forget the wafting scent of a monitor with smoke pouring out the back? The goat-like aroma of dozens of people in a computer center, up against a deadline? The odd smell of laser toner or massive piles of pulpy striped paper? Occasionally I’ll see a picture of a pile of old machines from the 1980s, and the olfactory memory will jump me.

Remember how the computer’s memory is kind of like a straight line, but programmers think in trees? That’s Lisp in a nutshell; it gives you an incredibly consistent way to think in trees. It’s as close to Zen as computing gets. Of all the languages in this essay, Lisp is the one I’d take to a desert island. It has the most to teach me about the hidden order of the universe.

Data management is the problem that programming is supposed to solve. But of course now that we have computers everywhere, we keep generating more data, which requires more programming, and so forth. It’s a hell of a problem with no end in sight. This is why people in technology make so much money. Not only do they sell infinitely reproducible nothings, but they sell so many of them that they actually have to come up with new categories of infinitely reproducible nothings just to handle what happened with the last batch. That’s how we ended up with “big data.” I’ve been to big-data conferences and they are packed.

It’s rare that a large task is ever very far from a database.

When people talk about databases, they often use the acronym CRUD, for create, read, update, and delete. You might create books or customers or purchases; read the data when a user logs in and load up their name and information; update someone’s e-mail address; or delete a user upon request. A huge amount of code is all about managing CRUD operations.

You set out to do something cool and end up destroying lots of things that came before.

There’s even a tiny little database called SQLite that’s so small, so well-behaved, and so permissively licensed that it’s now in basically every smartphone, available to apps to help them save and load data. You probably have a powerful SQL-driven database in your pocket right now.

“Enterprise” is a feared word among programmers, because enterprise programming is a lot of work without much to show for it.

Gigantic data-driven organizations are structured around code, around getting software made. But that doesn’t mean their teams are huge—Amazon, for example, is famous for its two-pizza rule: “Never have a meeting where two pizzas couldn’t feed the entire group.”

People in the free software community often code to scratch an itch and release that code into the digital commons so that other people can modify and manipulate it. While more often than not this process goes nowhere, over time some projects capture the imagination of others and become part of the infrastructure of the world.

The point is that things are fluid in the world of programming, fluid in a way that other industries don’t seem to be. Languages are liquid infrastructure.

A lot of things keep winning because computers keep getting more plentiful. It’s weird.

“Everything is edge cases,” he says. “Testing and edge cases.”

The greatest commercial insight of the technology industry is that if you control a computing environment, you can move the market.

People who work at technology companies are supposed to take an idea and multiply it by a few million people, yielding a few billion dollars.

A great way to do that is to wrap up your intentions in APIs and SDKs and IDEs. That’s why so much software to make software is free: It stimulates the development of even more software.

“Ecosystem” is another debased word, especially given what we keep doing to the real, physical one around us. But if a few hundred thousand people are raising their kids and making things for 100 million people, that’s what they call it.

You have entered into a pool with many thousands of other programmers who share the framework, use it, and suggest improvements; who write tutorials; who write plug-ins that can be used to accomplish tasks related to passwords, blogging, managing spam, providing calendars, accelerating the site, creating discussion forums, and integrating with other services. You can think in terms of architecture.

Programming is debugging. It’s the expectation that things won’t work.

JavaScript is fast-moving right now. Too much of what you know today will be useless in six months. Every hard-fought factoid about the absolute best and most principled way to use the language will be fetid zoo garbage by the end of the year. And some sniveling, bearded man-toddler will be looking slightly to your right with his pale, buzzword-infected eyes and awkwardly mumbling, “Yeah, no, wow, it says you have a lot of Gulp and Angular, but I’m guessing you don’t use Fleejob or Grimmex with the Snurt extensions? (Long sigh.) I’m just not sure if you’re gonna like working here.”

In my opinion, version control is one of the most beautiful things about programming.

See, tests and version control are now the trigger for actually shipping code. If you can follow a process like this, you can release software several times a day—which in the days of shrink-wrapped software would have been folly.

You feel some pity for the coders now. Obviously, they will inherit the earth. But in their race to the summit, they missed a lot of memos.

But the choice of a main programming language is the most important signaling behavior that a technology company can engage in. These languages contain entire civilizations.

I spoke with some friends in their 40s who had spent careers in technology. I was complaining. I said, “I mentor some millennials, and my God. Every job is a contract position. Nothing comes with health care. They carry so much debt.” They looked at me with perplexity. It took a moment, and then one of them said: “Not if they can code.”

Software taught me math and basic statistics. It taught me how to calculate great circle distance, estimating the distance between two points on a globe. I learned about the Internet by creating Web pages, and I learned about music through MIDI. And most of all, software taught me about software.

This is what Silicon Valley must be thinking, too, as it optimizes the hell out of every industry it can, making software (and the keepers of that software) the middleman. The Valley has the world in its sights. Government, industry, social services, human sexuality, agriculture: They want to get in there and influence the whole shebang.

For its part, Amazon is not really a bookseller as much as a set of optimization problems around digital and physical distribution.

Published by Ryan Boren

#ActuallyAutistic retired technologist turned wannabe-sociologist. Equity literate education, respectfully connected parenting, passion-based learning, indie ed-tech, neurodiversity, social model of disability, design for real life, inclusion, open web, open source. he/they