Read an Excerpt

Introduction
A few years ago, I was riding on a ski lift with our Swedish exchange student. I asked her if she had thought about what she was going to do after high school. She said that she was considering engineering and had taken a programming class the previous year. I asked her what they taught. She replied, “Java.” I instinctively responded with “That’s too bad.”

Why did I say that? Took me a while to figure it out. It’s not that Java is a bad programming language; it’s actually pretty decent. I said it because of the way in which Java (and other languages) are typically used to teach programming today—without teaching anything about computers. If this strikes you as a bit odd, then this book is for you.

The Java programming language was invented by James Gosling, Mike Sheridan, and Patrick Naughton in the 1990s at Sun Microsystems. It was modeled in part after the C programming language, which was widely used at the time. C doesn’t include automatic management of memory, and memory management errors were a common headache at the time. Java eliminated that class of programming errors by design; it hid the underlying memory management from the programmer. That’s part of what makes it such a good programming language for beginners. But it takes much more than a good programming language to produce good programmers and programs. And it turned out that Java introduced a whole new class of harder-to-debug programming problems, including poor performance resulting from the hidden memory management system.

As you’ll see in this book, understanding memory is a key skill for programmers. When you’re learning to program, it’s easy to develop habits that become hard to break. Studies have shown that children who grew up playing at so-called “safe” playgrounds have a higher rate of injuries later in life than those who didn’t, presumably because they didn’t learn that falling hurts. Programming is an analogous situation. Safe programming environments make getting started less scary, but you also need to prepare for the outside world. This book helps you make that transition.

Why Good Programming is Important
To understand why it’s problematic to teach computer programming without also teaching about computers, first consider how ubiquitous computers have become. The price of computers has fallen so dramatically that using them is now the cheapest way to build many things. For example, using a computer to display an image of an old-fashioned analog clock on a car dashboard costs much less than a mechanical clock. This is a result of how computer chips are manufactured; they’re more or less printed. It’s no longer a big deal to stamp out a chip that contains billions of components. Note that I’m talking about the price of computers themselves, not the price of things that contain computers. In general, a computer chip today costs less than the packaging in which it’s shipped. Computer chips are available that cost pennies. There will likely come a time when it will be difficult to find anything that doesn’t contain a computer.

Lots of computers doing lots of things means lots of computer programs. Because computers are so ubiquitous, the field of computer programming is incredibly diverse. As in medicine, many programmers become specialists. You can specialize in areas such as vision, animation, web pages, phone apps, industrial control, medical devices, and more.

But the strange thing about computer programming is that unlike in medicine, in programming you can become a specialist without ever being a generalist. You probably wouldn’t want a heart surgeon who never learned anatomy, but the equivalent has become normal for many programmers today. Is this really a problem? In fact, there’s plenty of evidence that this isn’t working very well, with almost daily reports of security breaches and product recalls. There have been court cases in which people convicted of drunk driving by breathalyzer have won the right to have the breathalyzer code reviewed. It turned out that the code was full of bugs, which resulted in overturned convictions. Recently, a piece of antivirus software crashed a piece of medical equipment in the middle of a heart surgery. Lives were lost due to design issues in the Boeing 737 MAX airplane. The large number of incidents like these don’t inspire a lot of confidence.

Learning to Code is Only a Starting Place
Part of the reason for this state of affairs is that it’s not all that difficult to write computer programs that appear to work, or work much of the time. Let’s use the changes in music (not disco!) in the 1980s as an analogy. People used to have to develop a foundation in order to make music. This included learning music theory, composition, and how to play an instrument; ear training; and lots of practicing. Then the Musical Instrument Digital Interface (MIDI) standard, originally proposed by Ikutaro Kakehashi of Roland, came along, which let anyone make “music” from their computer without ever having to develop calluses. It’s my opinion that only a small percentage of computergenerated “music” is actually music; it’s mostly noise. Music is produced by actual musicians—who may or may not use MIDI to build on their foundation. Programming these days has become a lot like using MIDI. You no longer have to sweat much or spend years practicing or even learn theory in order to write programs. But that doesn’t mean these are good or reliable programs.

This situation is likely to get worse, at least in the United States. Wealthy people with vested interests, like those who own software companies, have been lobbying for legislation mandating that everybody learn to code in school. This sounds great in theory, but it’s not a great idea in practice because not everybody has the aptitude to become a good programmer. We don’t mandate that everybody learn to play football because we know that it’s not for everybody. The likely goal of this initiative is not to produce great programmers but rather to increase software company profits by flooding the market with large numbers of poor programmers, which will drive down wages. The people behind this push don’t care very much about code quality—they also push for legislation that limits their liability for defective products. Of course, you can program for fun just like you can play football for fun. Just don’t expect to be drafted for the Super Bowl.

In 2014, President Obama said that he had learned to code. He did drag a few things around inthe excellent visual programming tool Blockly, and he even typed in one line of code in JavaScript (a programming language unrelated to Java, which was invented at Netscape, the predecessor to the Mozilla Foundation that maintains numerous software packages, including the Firefox web browser.) Now, do you think that he actually learned to code? Here’s a hint: if you do, you should probably work on honing your critical thinking skills in addition to reading this book. Sure, he may have learned a teensy bit about programming, but no, he didn’t learn to code. If he could learn to code in an hour, then it follows that coding is so trivial that there wouldn’t be a need to teach it in schools.

Importance of Low-Level Knowledge
An interesting and somewhat contrary view about how to teach programming was expressed in a blog post titled “How to Teach Computational Thinking” by Stephen Wolfram, the creator of Mathematica and the Wolfram language. Wolfram defines computational thinking as “formulating things with enough clarity, and in a systematic enough way, that one can tell a computer how to do them.” I completely agree with this definition. In fact, it’s in large part my motivation for writing this book.

But I strongly disagree with Wolfram’s position that those learning to program should develop computational thinking skills using powerful high-level tools, such as those that he’s developed, instead of learning the underlying foundational technologies. For example, it’s clear from the rising interest in statistics over calculus that “data wrangling” is a growing field. But what happens when people just feed giant piles of data into fancy programs that those same people don’t intimately understand?

One possibility is that they generate interesting-looking but meaningless or incorrect results. For example, a recent study (“Gene Name Errors Are Widespread in the Scientific Literature” by Mark Ziemann, Yotam Eren, and Assam El-Osta) showed that one-fifth of published genetics papers have errors due to improper spreadsheet usage. Just think of the kinds of errors and ramifications that more powerful tools in the hands of more people could produce! Getting it right is crucial when people’s lives are affected.

Understanding underlying technologies helps you develop a sense of what can go wrong. Knowing just high-level tools makes it easy to ask the wrong questions. It’s worth learning to use a hammer before graduating to a nail gun. Another reason for learning underlying systems and tools is that it gives you the power to build new tools, which is important because there will always be a need for tool builders, even if tool users are more common. Learning about computers so that the behavior of programs isn’t a mystery enables you to craft better code.

Who Should Read This Book?
This book is for people who want to become good programmers. What makes a good programmer? First and foremost, a good programmer has good critical thinking and analysis skills. To solve complex problems, a programmer needs the ability to evaluate whether or not programs actually solve the right problem correctly. This is more difficult than it sounds. It’s not uncommon for an experienced programmer to look at someone else’s program and snarkily comment, “Why, that’s a complex nonsolution to a simple nonproblem.”

You may be familiar with a classic fantasy trope of wizards acquiring power over things by learning their true names. And woe be to the wizard who forgets a detail. Good programmers are like these wizards who can hold the essence of things in their minds without dropping details.

Good programmers also have some degree of artistry, like skilled craftspeople. It’s not uncommon to find code that is completely incomprehensible, just like many English speakers are baffled by James Joyce’s novel Finnegans Wake. Good programmers write code that not only works but is also easy for others to understand and maintain.

Finally, good programmers need a deep understanding of how computers work. You can’t solve complex problems well using a shallow base of knowledge. This book is for people who are learning programming but are unsatisfied with the lack of depth. It’s also for people who are already programming but want more.