3 Think Like a Computer
There’s a skill fundamental to software development I’ve always found useful. This skill is essential when working with every programming language, including PHP and when working across PHP frameworks. Like all skills, mastery comes from study and practice.
What is this skill? It’s learning to think like a computer and to view software from the computer’s perspective. We’ll first see how I learned the skill way back when—that’s part of the story—and then learn about a Kickstarter product which teaches this very skill. We’ll even discuss how beginners can practice this skill with just HTML and CSS.
I have been trying, for two years now, to explain and teach a particular software development skill. I’ve missed it every time. It’s more subtle, more fundamental than I recognized.
We’ll need to travel back to when I began to learn this mysterious skill. I’ll show you what this skill appears to be. I’ll show you how to acquire this skill. Is the skill important today? I believe so, and I’ll explain that too.
Dr. Heather D. Pfeiffer, in her 2001 lecture notes for CS 273 (Machine Programming and Organization), writes:
Computers work through a serendipitous interplay of four developments:
We are interested in the first three items.
I learned radix arithmetic in primary school. I was around nine years old, in 4th or 5th grade. We learned to convert from standard base-10 numbers to base-12, base-2, or whatever number system we needed to. We learned simple addition and subtraction in the alternate number system. That skill is no longer (as far as I know) taught in primary school. Is it an important skill? Perhaps not; it’s not a skill used day-to-day.
It is, however, a skill I have used throughout my career, so I have assumed it’s crucial. Yet, software gets developed without actual working knowledge of binary or hexadecimal arithmetic. So, it’s not the important skill, even though it’s a useful skill.
I was nine when I took a pair of summer enrichment classes; one was cryptography. I was excited about that one! However, to my surprise, most of that session involved matrix multiplication . I had a rough time with matrix multiplication and could not make the connection from matrix multiplication to cryptography. I still don’t know the connection! What did I learn? I learned I would never become a professional cryptographer, not with all that math.
The other summer school class was about Boolean logic or Boolean algebra. That sounded like math, so I didn’t know if I’d like it or not. But, it related to computers in some way so I hoped it would be fun. It was.
It was easy enough to understand AND, OR, and NOT “gates” (operators), and from those gates construct NAND and NOR. Two inputs and one output defined each gate. Everything was consistent. It was like knowing three plus two always produces five. Add three and two, or two and three, and the result is always five. Every time. To me, this made sense.
But then we did something I’d never seen before. We connected these logic gates in a sequence, one after another. We learned equivalent expressions, such as (a or b) inverted produces (not-a and not-b), while (a and b) inverted produces (not-a or not-b). When inverting, swap the “and” for “or” and vice versa using de Morgan’s Theorem . We drew out the diagrams to prove this.
We also had a rudimentary plugboard where we could physically wire up the logic gates, one gate propagating (cascading) to the next. There was a little light bulb showing the state of each input and each output. We could see the whole thing.
The whole thing was totally awesome. I could see what was happening. Therefore each piece or step made sense. I did not really understand why negating a Boolean term means swapping “and” for “or,” but I could see that it did. If someone could articulate the rules, I could follow the rules. For example, I already knew the commutative property of addition states that three plus two produces the same result as two plus three. We can swap the operands with each other without altering the result.
In other words, “a plus b” equals “b plus a.” I could immediately transfer that knowledge to Boolean algebra: “a AND b” equals “b AND a,” and “a OR b” equals “b OR a.” The material was presented in such a way that I could bridge the gap from arithmetic to Boolean logic.
Then came the gap I couldn’t bridge.
Popular Electronics
Popular Electronics magazine (April 1968) published Demonstrating Binary Computation with the Binary Adder (Figure 3.1). It was a 4-bit binary adder! I was able to draw out the logic diagram on paper, but this was the actual electrical circuit built with resistors, diodes, switches, and lights. Mom drove me around to electrical supply stores to get the necessary discrete parts, and Dad helped me with the soldering. I became fascinated with the colored bands on resistors because they encrypted coefficient, mantissa, degree of precision, and range of error.
Figure 3.1. Binary Adder project
I built the thing. Figure 3.2 shows me demonstrating the 4-bit binary adder with my sister Vicki on the left.
Figure 3.2. Four-bit binary adder
I was quite proud of the thing. Nobody else in my grade school had built their computer from loose parts. I could explain what it did, and why , but I could not explain how it worked. I had learned how to draw out the logic diagram for a binary adder the previous summer, and I knew this computer was a physical implementation of that diagram (Figure 3.3). But there was nothing I could point to inside the thing and say, “That’s the AND gate.” I could point to the wire representing the carry bit (“CARRY IN” at the upper right of Figure 3.3), and I could point to the wires representing the input (the switches on the front). But I could not explain how the electrical circuit got from input to output. I could follow the circuit from the ground symbol at the bottom of Figure 3.3 to the neon output light at the top (marked NE2H). But I could not match that electronic circuit diagram to the equivalent Boolean logic diagram (Figure 3.4). There was a gap in knowledge, and I never did bridge that gap.
Figure 3.3. Adder circuit
Have we found that elusive skill? We’re getting close. Remember, Dr. Pfeiffer said computers work because of binary arithmetic, Boolean logic, and digital electronics. We just demonstrated all three. But should we be searching out some obscure project from 1968? Certainly not. We can do better. And, by the way, the elusive skill is not any of these three. It’s not binary arithmetic, Boolean logic, or digital circuitry.
Figure 3.4. Full adder logic diagram
Let’s close out the flashback and return to today.
Turing Tumble
Almost precisely 50 years later, Paul Boswell created a Kickstarter campaign called Turing Tumble . The $48,000 goal received more than $400,000 pledged. (I have no relationship to the product or its creators.) We’ll be using Turing Tumble, but not for its stated purpose.
Boswell explains,
I’m all about teaching kids to code. When I was a professor at the University of Minnesota, I saw how valuable it is for all students to be coders. I have three young kids and I’ve tried all sorts of games to build their interest in coding. The problem is that they all treat computers like abstract, black boxes. They overlook the fundamental, incredible concept: how simple switches, connected together in clever ways, can do incredibly smart things.
Kids learn best when they use their senses to explore concepts. Turing Tumble is the only game that lets kids see and feel how computers work. The logic isn’t hidden inside a computer chip—it’s all right there in front of them. It builds logic and critical thinking skills, fundamental coding concepts, and grounds their understanding of computers.
And adults, this game is not just for kids!
It’s a game unlike any you’ve ever played. It takes creative thinking to come up with a solution to each puzzle—you can’t just stumble across the solution by trial and error—and it’s extremely gratifying to build it and watch it work. Even if you’re an expert programmer, I guarantee you’ll find the latter puzzles a challenge.
I missed the Kickstarter, but went down to Games by James and purchased a copy for $70 (Figure 3.5). It’s as good as advertised if you look past its simplicity. The game is packaged as a graphic novel with a storyline, laying out the quest with 60 puzzles to solve. The game implements such fundamental concepts as AND , OR , bits, registers, addition, counting, and loops. The game is Turing Complete , meaning that with a big enough playing board, and enough parts, we could implement any digital algorithm.
Figure 3.5. Running Turing Tumble puzzle 8
Figure 3.6 shows Challenge 56, which is to design a multiplication circuit. The lower-left frame illustrates the starting setup. Use any parts needed from the list at the lower right to design the circuit flow.
Figure 3.6. Multiplication Circuit (licensed Creative Commons 4.0)
Let’s first look at the situation for an eight to 10-year-old, then as professional software developers. There’s an important skill hidden here, but we need a bit more analysis to get there.
Crypto
Do you recall my describing the cryptography class I took when I was nine? I had such hopes—and the matrix multiplication dashed them. I couldn’t do it. But a few years later, in college physics, those struggles helped me to understand dot products. When I realized, in computer science, the implementation can be a multi-dimensional array, I was home free. Countless memory-related or data-related concepts tied back to my attempts to learn cryptography in grade school.
For an eight to 10-year-old, Turing Tumble is a similar situation. I could learn to create patterns resulting in AND , OR , loops, and counting, but I wouldn’t be able to make the leap from the plastic pieces and gravity power to how the silicon chip works sitting unseen in the IBM cloud. Or, looking in the other direction as a child, I couldn’t make the leap from the binary fundamentals to designing an interactive webpage. There’s a gap.
Or is there? Let’s look at another example.
When adults want to “learn coding” and wonder where to start, I suggest they begin by learning to hand-code webpages. I explain that HTML and CSS are, in fact, programming languages. They are providing instructions for your browser to execute. Webpages (when just HTML and CSS) are plain text and thus easy to see, create, edit. But the most critical point is, for anyone who asks, they are already familiar with how webpages work.
Webpages, in that sense, provide a comfort level. We’ve all dealt with webpages at their best and their worst, with good internet connections and bad. We understand what they do and how they work. Thus, as we are learning to create one by hand-coding the markup and styles, we can “bridge the gap” and understand the result.
In the same way, the more we gain experience with what computers do, the better we can bridge the gap between the extreme fundamentals (taught by Turing Tumble) and actual computer hardware.
Here’s my takeaway. By learning these fundamentals at age eight to 10, it becomes possible to “bridge” all sorts of gaps throughout one’s career. The intuitive leaps happen because of prior knowledge. How do I know this is the case? Because of those summer classes and building that binary adder. That’s why I told the story, so you’d know why I’m certain Turing Tumble is useful training for your career.
According to Dr. Pfeiffer, computers work through a serendipitous interplay of four developments: binary arithmetic, Boolean logic, digital electronics, and computability theory. Turing Tumble teaches those first three areas through its series of 60 ever-more-challenging, hands-on puzzles. That’s great, but do those three areas represent the skills we need in our day-to-day software development? No.
There’s something else. It’s so simple you might get angry that I took so long to explain it.
Flow
As software developers, we can understand (in theory) any particular piece of code. It might calculate the square root of a number, for example. We know what that means. We know its constraints (input must be non-negative and less than the maximum available floating-point number; output is limited to a certain number of digits’ precision). We can look at the code listing and see how it implements the algorithm.
Note that I’m describing the code as a thing not a journey . We think of the code as producing a result. On the other hand, a great way to understand the code would be to run through the calculation using a pencil and paper. Walk through the algorithm step by step, doing each calculation to the last digit, and no further, at every step. Mark Twain explained there is no substitute for first-hand experience:
If you hold a cat by the tail, you learn things that cannot be learned in any other way.
None of us is in the habit of walking through every piece of software, doing every step by hand. Even with tools like XDebug available, we don’t step through our code every time! That’s why we have computers. (By the same thinking, none of us needs to test our software; that’s why we have users.) Instead, we look at the software and recognize what it does . There’s a gap here. It’s subtle. But Turing Tumble can help bridge that gap.
Computers run on electricity, that is, electrons flowing through circuits. The Turing Tumble computer runs on falling marbles running through circuits. We can’t see the electrons, but we can watch the marbles. Where electricity takes only two nanoseconds to travel through a foot of circuitry, the marble takes several seconds to travel that same distance through the Turing Tumble circuitry.
Because the electronic computer is so nearly instantaneous (unless using JavaScript), I can only picture the computer’s result . I don’t visualize the flow that got us there. I focus on the result rather than the journey. However, the bugs tend to hide in the journey rather than the result.
Each of the 60 Turing Tumble puzzles asks you to design a flow which achieves a result. Once designed, you then press “start” and watch the flow. The flow is the solution. The result merely confirms that you achieved the correct flow.
Turing Tumble teaches that computers work because electrons flow. That’s great to know, but how does that help with modern software development? We’re almost to that subtle skill; in fact, we’ve arrived.
Journey Versus Destination
What’s the big secret? It’s thinking about software in terms of flow rather than the result. I don’t mean the flow of data through a system; I mean the flow of the processor (CPU and friends) executing your instructions (the software).
Is binary arithmetic essential to day-to-day software development? Not usually. But learning how computers do binary arithmetic leads to understanding how computers process instructions.
We understand how flow-of-control works through a piece of software. We can read an if/else test. We know a loop runs a certain number of times, and then flow continues past the loop. We know that, given “these” input conditions, a square-root function produces “that” output result.
But all of that is at a relatively high level. The subtle skill here is the more intimate understanding. Think of the flow at a more fundamental level.
Software development is, in essence, instructing computers how to do things. Thus, it’s important to understand how computers carry out those instructions. If you instruct the computer to add “one-third plus one-third plus one-third,” the answer probably won’t be the number one. It will be a number very slightly less than one because that’s how computers work.
Software development is also, in essence, designing a flow to achieve a result. When we write software, we’re describing the flow. When the computer runs the software, what does it do? It flows. Electrons flow. The CPU (and friends such as GPU, instruction bus, etc.) flows. Program control flows. When the computer is running software, it’s literally the journey, not the destination.
What’s the secret skill? It’s to think as a computer does. Form empathy, so to speak. Look at your software from a computer’s point of view, not a person’s point of view.
If you were to write a cookbook for children, for example, you would need to visualize how a child would follow your recipe and cooking instructions. You need to get past how you , as an adult, would implement the recipe, and instead follow the instructions as if you were the target audience. That can be difficult, depending on your level of empathy.
It can be equally challenging to look at your software—or anyone’s software—from a computer’s perspective, to think in terms of the computer’s processing flow. It takes a certain level of empathy. Each Turing Tumble puzzle, in that sense, is an empathy-first design.
Skill comes with practice. The skill here is to visualize the processing flow from the computer’s perspective. Have fun! Fun is important, and keeps the boredom at bay:
“Look. My job’s pretty simple,” Randy says. “There’s that big cable from Taiwan down to Luzon. A router at each end. Then there’s the network of short-run, inter-island cables that the other people are laying in the Philippines. Each cable segment begins and ends at a router, as you know. My job is to program the routers, make sure that the data will have a clear path from Taiwan to here.”
John Cantrell glances away, worried that he’s about to get bored. Randy practically lunges across the table, because he knows it’s not boring. “John! you are a major credit card company!”
“Okay.” Cantrell meets his gaze, slightly unnerved.
“You are storing your data in the data haven we’re building. You need to download a terabyte of crucial data. You begin the process—your encrypted bytes are screaming up through the Philippines at a gigabyte per second, to Taiwan, from there across to the States.” Randy pauses and swigs Guinness, building the drama. “Then, a ferry capsizes off Cebu.”
“So?”
“So, in the space of ten minutes, a hundred thousand Filipinos all pick up their telephones simultaneously.”
Cantrell actually whacks his forehead. “Oh, my god!”
“Now you understand! I’ve been configuring this network so that no matter what happens, the data continues to flow to that credit-card company. Maybe at a reduced speed—but it flows.”
—Cryptonomicon (1999) by Neal Stephenson (p. 307)
We all visualize sequences of events. We can picture the result of that (fictional) ferry capsizing off Cebu. It caused an overwhelming traffic spike. Get in the habit of visualizing the events with all software, and you’ll develop a valuable skill for all software development.
Summary
It’s a tricky undertaking to think of software the way the computer thinks about the software. The key is to think about the flow rather than the result. Picture the journey rather than the destination. Seeing the destination is easy; it’s right in front of you. Seeing the journey is the subtle skill to be developed. I’m particularly pleased with Turing Tumble because it provides a way to see, picture, study, and internalize the journey. With practice, the perspective becomes second nature.