What is Code?

Today I read perhaps the single best article I’ve ever read on programming.

Paul Ford has written the definitive guide for explaining a profession that employs 11 million people and occupies 7 million more hobbyists’ time by answering the question, “What is code?”

He wrote the article for everyone, he says, but specifically he wrote it for the editor of Bloomberg. Whether you’re a programmer already, in a business where you work with programmers, or just want to learn a bit more about the thousands of frameworks for 0s and 1s that run our world, I think the article is for you.

It’s not fair to attempt a summary of the many points Paul makes, but I’ll highlight some of my favorite passages and also summarize some of the topics he covers. However, I can not offer each point the justice they deserve, so honestly if you really want the best experience, read the original and not this.

The only benefit of my article is that at just over 2,000 words it’s 5% of the length of the original. I’d encourage everyone to read the entire article. I’m sure I’ll share it individually hundreds of times in my future.

Here is MY three-word summary of my article for busy people: Reevaluate your life.

— Paul Ford (@ftrain) June 12, 2015

Are you still not convinced to commit to it? Okay, fine. Here are my favorite parts:

Where is code?

While the entire article answers, “What is code?”, he starts by answering, “Where is code?” Code is much broader than the web. It’s pervasive. Everywhere.

Most programmers aren’t working on building a widely recognized application like Microsoft Word. 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). Software is there when you switch channels and your cable box shows you what else is on. You get money from an ATM—software. An elevator takes you up five stories—the same. Facebook releases software every day to something like a billion people, and that software runs inside Web browsers and mobile applications. Facebook looks like it’s just pictures of your mom’s crocuses or your son’s school play—but no, it’s software.

Computers are dumb

Until they’re not. But today, computers really don’t know anything; they return things based on what we put in them, and they can do so many things faster than we can.

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.

Programming languages

Paul spends a ton of time talking about various programming languages, their origins, their styles, their adoptions, their usefulness, and how they’ve evolved.

He primarily focuses on C (and how it’s fast but not object oriented) and Java (and how it’s object oriented but not fast, relatively). Amazingly, he manages to talk about many, many languages, their attributes, and yet explain them in a way that nearly anyone can understand.

I have to admit something: I am so far from a classically trained developer that I found this focus of the article to be incredibly educational. I learned the wrong way, from the tip of the pyramid down. If you consider markup and styles the very tip, and then WordPress is a bit below that as a framework for PHP — and you are still only part way down the pyramid. PHP is built with C and C compiles to machine code. His article helped me understand the pyramid from the other direction much better.

Programmer culture

An important piece of the article was around culture. He spends time both on programmer attitudes and broader programming culture, such as conferences.

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.)

Coding is a culture of blurters. This can yield fast decisions, but it penalizes people who need to quietly compose their thoughts, rewarding fast-twitch thinkers who harrumph efficiently. Programmer job interviews, which often include abstract and meaningless questions that must be answered immediately on a whiteboard, typify this culture. 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.

At any moment some new thing could catch fire and disrupt the tribal ebb and flow. Instagram was written in Python and sold for $2 billion, so Python had a moment of glory. The next mind-blowing app could show up, written in some new language—and start everyone taking that more seriously. 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. They get defensive when they hear someone suggest that Python is better than Ruby, because [insert 500-comment message thread here]. 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.

And his passage on the decreasing percentages of female coders is pure perfection:

The average programmer is moderately diligent, capable of basic mathematics, has a working knowledge of one or more programming languages, and can communicate what he or she is doing to management and his or her peers. Given that a significant number of women work as journalists and editors, perform surgery, run companies, manage small businesses, and use spreadsheets, that a few even serve on the Supreme Court, and that we are no longer surprised to find women working as accountants, professors, statisticians, or project managers, it’s hard to imagine that they can’t write JavaScript. Programming, despite the hype and the self-serving fantasies of programmers the world over, isn’t the most intellectually demanding task imaginable.

Which leads one to the inescapable conclusion: The problem with women in technology isn’t the women.

PHP and (sorta) WordPress

Of everything discussed in the article, the one thing I really could tell he didn’t appreciate much was PHP.

You can get a site up and running in PHP in a few minutes, and that’s the problem. It used to be the terrible choice you made when you needed to get something done on the Web, but increasingly JavaScript has replaced it as the default terrible choice.

PHP stands for Personal Home Page/Forms Interpreter. The idea was that when you loaded your Web pages, the PHP code would run before the page went out to the Internet. And PHP could, say, check whether you were logged in. If you were, it could show you your top secret account details; and if you weren’t, it could say, “Please log in.”

I know a lot of people who program in PHP, and they are smart, good people. PHP powers Etsy and Facebook. It powers Wikipedia, for God’s sake. WordPress. Out of all the Web’s pages, an enormous percentage is created with PHP.

Coding in PHP for a living is not a death sentence. Lots of people have gotten rich off PHP. It just means a lot of cutting and pasting, and a lot of trips to Google to figure out why things aren’t working.

Poor, sad, misbegotten, incredibly effective, massively successful PHP. Reading PHP code is like reading poetry, the poetry you wrote freshman year of college.

I spent so many hundreds, maybe thousands, of hours programming in PHP, back when I didn’t know what I was doing and neither did PHP. Reloading Web pages until my fingers were sore. (I can hear your sympathetic sobs.) Everything was always broken, and people were always hacking into my sites.

PHP. I don’t wish it any harm. I’m glad to see how well it’s done for itself. We had some good times together. I just don’t ever want to go back there.

He also uses WordPress as the punching bag for the story in the story. The fictional story within the article is of a company that’s replacing their current website with a new website. It’s a big corporate environment and they’re, “at the limits with WordPress.” Of course, Matt Mullenweg took issue with that one aspect on his own blog.

Debugging, testing, and version control

Paul gives some of the best layman’s descriptions for debugging, testing, and version control I’ve ever read. He closes the section with this:

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. (Often builds were done nightly, by big “build servers,” and one would come in the next morning to get the score.) But now that software can be released via the Web or an app store, why wait? Why not continually release software, every day, whenever you have something that’s ready to go?

Actually picking a language

It’s hard to limit this one and it was one of my favorite parts, so I’m just going to toss it in in bulk.

Beware of arguments related to programming speed. All things being equal, faster is better. But all things are never equal. Do you need the kind of speed that lets you get a website up and running quickly? Or the kind that allows you to rotate a few thousand polygons in 3D in real time? Do you need to convert 10,000 PDFs into text per hour? Or 10 million PDFs into text once? These are different problems. What do we need to do, how many times do we need to do it, and what existing code can we use to help us do it that many times? Ask those questions.

It’s possible to spend productive months preparing for a project without deciding on a language. It may be the sign of a fine manager, someone who assumes his people can learn new things, someone who’s built an agile team capable of experimenting with new technologies and getting ideas into production. It could also be that this person is totally useless. You’ll find out!

Let’s say your programmers are developing a huge website that serves 5 million people who each visit five times a month. Do you use Python, which is slower, or Go, which is fast, or Node.js, which is something in-between? Trick question! Twenty-five million Web page visits isn’t that big a deal, unless they involve some deep wizardry or complex database queries that are very different for each page (good example: Facebook).

Now, that number isn’t trivial; if it takes a minute to make a page, you’d need 48 years to make that many, which is way too slow. If it takes a second to make a page, that’s still too slow—there are only 2.6 million seconds in a month. So you need to figure out how to serve about 10 pages per second. You’ll probably want more than one computer, a little redundancy, some good server setup. It will take some doing and planning. But it can be done in any language.

What if you are going to serve only a few hundred thousand pages a month? Then you’ve got tremendous breathing room. You don’t need too many engineers to create the system architecture. You still need to plan, but in general you can read some blog posts and follow along with what others have done. You can be pretty sloppy, to be honest. Again, any language will do.

What if you want to include a live, person-to-person chat on those pages, and you expect thousands of people to use that chat at once, all speaking to each other? Now you’re dipping your hand into that godforsaken river. But that is exactly the problem that Go was designed to solve. It’s a language for creating highly available servers that use as much of the computer’s processor as possible. It has other features as well, but this is where Go shines. Actually, Node.js works pretty well for that sort of server, too, and Clojure certainly has the capacity. Oh, right, Java works, too. If you really needed to, you could even do it in PHP.

This is why the choice is so hard. Everything can do everything, and people will tell you that you should use everything to do everything. So you need to figure out for yourself what kind of team you have, what kind of frameworks you like using, where people can be most productive, so they will stick around through the completion of the project. This is hard. Most places can’t do this. So they go with the lowest common denominator—Java, PHP—because they know that when people leave, they’ll be able to get more of them.

And that’s OK. The vast majority of technology projects don’t require original research, nor do they require amazing technological discoveries. All the languages under discussion work just fine. There are great coders in all of them.

Should you learn to code?

I’ve only highlighted some of my favorite parts. I will likely re-read this article many times.

You can also check out a GitHub repo for the article, which is super cool. You can also catch a Q&A with Paul Ford, about the article and process, on Gawker. Oh, and his test last year of the Kinja CMS — a debacle that is reminiscent of the Bloomberg article more than a little bit — is hilarious.

In the end, he poses the question: “should you learn to code?” You’ll have to read to the end to find out.

Seriously, thank you Paul Ford for this piece, and Bloomberg for funding it.