This excerpt first appeared in the September 1998 issue of Wired magazine (Wired 6.09).

For the few of us into computers at Horace Mann in 1982, the computer room on the third floor of Tillinghast Hall was the greatest place at school. With its lead-paned windows overlooking the football field, its polished floor and rows of terminals in tidy rows, the computer room existed as our private library and club room. During free periods, when other kids might go outside to play touch football or gossip in the cafeteria, I could be found upstairs at a terminal, playing games and programming with my friends. There, amid the silence, interrupted by the clicking of keys and the soft tapping of chalk on the blackboard, we competed fiercely to be the best programmers. It was a place where things happened quietly, but explosively.

Pranks were a natural part of the room. I'd written programs that fooled seventh-graders into thinking our shared computer, a Digital Equipment Corporation PDP-11, was conscious. Others had found ways to fool skilled programmers into thinking the computer could no longer add properly (2 + 2 = 5!). Creativity ran rampant. The walls were covered with elegant "ASCII art" ­ pictures of Snoopy and the New York skyline we'd made from collections of letters that from a distance assembled themselves into an image. A few had mastered the eight-pen color plotter, learning to produce marvelous geometric shapes, swirling vortices, and rippling landscapes. I was in awe of some of the older kids who'd reverse-engineered the PDP's operating system and were trying to build a new one from scratch.

The computer room was also a safe haven, a family of sorts. We were mostly boys ­ though a few girls spent time there ­ and many of us came from families with divorced parents. I faced turmoil at home, living between my mom and dad, separated from my sister. Another boy, Misha, faced such acrimony at home as his parents underwent a particularly bitter breakup that he threw himself into programming with relentless intensity, eventually creating an after-school business writing programs for Wall Street corporations and earning enough money to pay for college himself. In the computer room, all the worries of the real world faded away, replaced by the exhilaration of the quest, a gleeful sense of discovery, and the joy of being best at something.

I was exposed to a remarkable computer curriculum, and nearly everything I know about computers and technology comes from those years on the third floor of Tillinghast. My friends and I were among the first at our Bronx school, and in America, to have computers at home. At 13 I owned an Atari 800 with 48K of RAM; Jeremy Bozza had an Apple II; Misha had a TRS-80; others had Commodore 64s and VIC-20s. At school we used the PDP, which, like our early home computers, was special because it was so transparent. The barrier between us and the machine was low; we could fairly easily get to the innards of it. It was a unique time, the Golden Age for computer and kid. The machine was available to us unconcealed, stripped to its component parts, at the same time when most adults barely understood what we were doing. The evolution of the machine briefly matched the evolution of our adolescent selves, becoming a vessel and partner, a co-conspirator in our coming of age.

One of the rare adults who did understand computers was our teacher, Mr. Moran. He was a big man with a red beard, red hair, and heavy forearms like a lumberjack's. His eyes were luminous gray-blue, and he always wore silver glasses, which softened his appearance, giving him an intelligent presence, as if he noticed everything. He existed in my mind as a descendant of Vikings, a benevolent warrior, at the helm of our ship, guiding the room through waters of knowledge.

Mr. Moran left Horace Mann in 1988. Today he doesn't teach kids; he teaches adults through the Global Knowledge Network, an outfit that provides continuing education to corporate employees. For Mr. Moran (his first name is Ed, but I still find it impossible to call him anything but Mr. Moran), who has taught for 23 years, computer education has shifted from learning how to program to a form of digital bricolage where prewritten subroutines are linked together to form programs. Mr. Moran doesn't even program anymore. A few months ago he removed C++ from his home computer to make room for Windows 98. "It hadn't occurred to me at the time, but this was my last compiler," he told me the other day, referring to C++. "I still can't quite get over the fact that I'm sitting here with a computer that has no programming capability whatsoever, unless you count things like Word macros, which I don't."

If Mr. Moran finds it difficult to program computers these days, it's easy to see how difficult it is for 14-year-olds. Computers are now infinitely more powerful than they were when I mastered them. They're also far more opaque. For a kid now, getting beneath Windows 98 or Mac OS 8.0 is nearly impossible. Our priority has shifted to teaching people how to be Power Users: dexterous at using software, rather than creating it. Added power and opacity, however, has its virtues. Using computers "out of the box" is a lot easier than it used to be. Clicking on an icon requires less study than going into a Basic programming environment and typing RUN. These systems have broadened access and turned what was mostly a hobbyist subculture into a part of mass culture. What is lost is the idea that kids can ever learn to understand computers, or that any of us, as computer users, can have fundamental control over what they do. We're supposed to know how to use the tools, not make the tools.

Mr. Moran taught us to make things, using the elements of computing as our tools; the notion that we would become merely educated consumers would have seemed ludicrous and unworthy as a goal. I grew up feeling I really understood computers. While I don't program anymore (the last time I programmed was in 1993, when I wrote databases for a management consulting company), the experiences I had at home with my Atari and in the computer room with Mr. Moran and my classmates have given me a perspective that, no matter how opaque and turbocharged computers become, lets me use them without feeling bewildered and dominated.

In 1979, when Mr. Moran asked Horace Mann's administration to provide him with US$200,000 to buy the PDP-11 and create a sophisticated computer room, the future was supposed to be different. "Some trustee asked me why I needed so much money for so much equipment," he recalled. "Why didn't we just get a few PCs and teach everyone how to use a wordprocessor and that would be it. I replied that someone had to design the future wordprocessors, and I wanted my students to be able to do that. That seemed so obvious to me then, and still does today. But as computers get easier to use, and more people use them, they are getting harder to really understand, and fewer people really understand them."

When I entered the computer room for the first time, I felt the future was hidden there, waiting to be discovered. There are moments between people in that room that stick in my mind as permanent testaments to the kind of learning we experienced. In his quiet way, Mr. Moran had created something unique at school: student teachers. There was no boundary between learning in class from Mr. Moran and learning out of class from "Superusers" and younger students who might one day become Superusers. Superuser was a title awarded by Mr. Moran to the best programmers in the room. Being a Superuser was not an academic distinction ­ though any student who earned it typically received straight As in computer class ­ but a mark of responsibility. Superusers were system administrators. They, as much as Mr. Moran, ran the room.

It was a post we all wanted. A Superuser was expected to be present whenever Mr. Moran was out of the room, but Superusers didn't just babysit; they installed and upgraded new programs that were then made available to everyone. They also wrote software, creating applications that otherwise wouldn't exist. In part, this reflected necessity. In the early 1980s, when high school computer education was in its infancy, student-crafted software was essential to the curriculum. Schools nationwide hadn't begun to invest in computer courses, and few companies provided software environments for teaching below the university level.

Mr. Moran, through organic evolution, trial and error, created an open system, both in the way the computer functioned and in the social fabric of the computer room. The machine and the kids existed in symbiosis, each a part of the other. Without the student system administrators writing programs, updating software, managing the younger students, answering their questions, Mr. Moran would have been incapable of being teacher, guide, administrator, and sometimes policeman. More important, centralized control by one teacher was antithetical to the ethic of exploration and gleeful discovery fostered by access to computers. Mr. Moran recognized this and promoted its inverse ­ decentralization and communal ownership of the computer system ­ by empowering kids to strive for total access.

The Superuser had no restrictions: With the title came the right to access any other student's account, including that of other Superusers. In principle, if a Superuser wanted to crash the system, delete every file, snoop anywhere, he could. This was not reverse psychology or a sophisticated ploy to divide and conquer. Rather, it reflected the belief that for kids to be well-educated, responsible citizens in the digital age, knowing how computers worked would not be enough. Their education would be incomplete without a genuine understanding of the moral and ethical questions brought up by information technology. Who owns software? Where does someone's electronic property or territory begin and end? At what point do shared systems become public? I couldn't have expressed these convictions outright back then. They were ingrained in us as we went. As was a certain pride ­ encouraged by Mr. Moran without any fanfare ­ in what we were accomplishing. We were not covering well-worn paths in our learning. We were striking out, sometimes wildly, into a little-known territory. Reward for our journeys came in the form of profound and gut-wrenching insights, palpable moments of learning. One of these occurred in my junior year, while working on Cheese, the most complex and ambitious programming challenge Mr. Moran ever gave us.

That fall of 1984, I'd enrolled in Advanced Placement Computer Science, the final course Mr. Moran offered, counting for college credit. In AP Computer, as we called it, Mr. Moran taught us Pascal, a programming language designed to give students good programming habits ­ modular, well-documented code. Invented in the late '60s by Niklaus Wirth, a Swiss educator and computer scientist, Pascal charmed me with its elegance. Unlike Basic, Fortran, or Assembly language, which I'd learned in previous years, Pascal had no line numbers. Rather than taking the long, rectangular shape of rows of programming instructions, Pascal programs were sinewy. They wove down the page, with indented lines indicating subroutines. Pascal floated as a poetry of algorithms. AP Computer demanded mastery of Pascal.

Mr. Moran's trimester-long Cheese assignment, meant to simulate the workings of a cheese factory, was the ultimate test of our skills. Each of us had to write a Cheese program to handle inventory control, managing piles of data on what cheeses were in or out of stock ­ Gouda, Havarti, Brie, Swiss, and so on ­ and reorder what was missing. The most difficult part was the reporting functions. The program had to provide statistics on which cheeses sold best, what combinations of cheese shipped most frequently, and financial averages on the cost of typical cheese orders. These then had to be printed out in neat reports ­ the kind a factory manager would like to read.

In the spring of my junior year, Cheese permeated the computer room ­ cheese, cheese, cheese. Scraps of sorting functions, with tell-tale variables like "Muenster" or "cheddar," would be left, half erased on the board. Printouts, sometimes shredded, other times left underfoot, would clutter the area around the printer. Picking them up would reveal ... cheese. I began to feel that Cheese was all that mattered. And it was while working on Cheese that I had my epiphany, a moment of learning, of the sort that stays with one ever afterward.

One procedure kept crashing my Cheese program. It seemed simple, a routine control structure. The procedure read from the database of cheese inventory, looking for a particular cheese. The idea was to scan each record, checking if it equaled the cheese value sought. If it found a match, the procedure copied that record's address and returned to the previous part of the program. Mission accomplished.

If, however, the cheese was not there, the procedure tried again, moving down the list to the next record. This was a generic conditional loop, designed to persist until the desired result is attained. But for some reason, it didn't work. If the chosen cheese didn't come up in the first dozen or so records, the program fatally crashed, claiming it had run out of memory. That made no sense. It was just a loop. The procedure looked like this:

PROCEDURE get_cheese(VAR wanted_cheese : cheese, output_location : integer);
VAR 
	cheese : cheese
	location : integer

BEGIN {procedure get_cheese}
	read_database(cheese, location)
	IF cheese = wanted_cheese
		THEN 
			output_location := location
			END
				ELSE
					get_cheese(wanted
					_cheese; location)
	END; {procedure get_cheese}

The idea was to scan the database of cheese by calling the get_cheese procedure. Get_cheese goes through the database using another procedure called read_database, which I created to handle all data search requests throughout the entire Cheese program. That's the power of Pascal: You write one procedure and can use it throughout the rest of the program, rather than rewriting the command over and over. If read_database does not find a cheese value that matches what you want, get_cheese moves down to the next record by calling itself. I pictured the whole thing like a GOTO loop.

The little pointer moves down the procedure, and if read_database does not return what is sought, then get_cheese invokes get_cheese(wanted_cheese; location) and starts over, until the wanted cheese is found. But then it crashed.

[PROGRAM STOPPED OUT OF MEMORY]
$

Why?

Grappling with my program at school, I knew the get_cheese variable couldn't be the problem. It had worked flawlessly in other procedures throughout my Cheese program, so I loaded the debug program that comes with the Pascal compiler. Debug let me step through the code, one execution at a time, watching exactly what the PDP was doing. That time, debug didn't help. I watched as the program stepped, one instruction at a time, just as I thought it should: moving down the procedure and calling itself until the cheese is found. But every time, around the 12th iteration of the loop, the program crashed. Why, why, why? It turned into one of those ghost-in-the-machine moments, when you're convinced computers are much more mysterious than you realize. Perhaps sentient.

Jeremy and Kenny were in the room, too, across from me, on the other side of the table. I was embarrassed to ask Mr. Moran for help in front of them. What if it's a stupid problem? So I ran debug again. Maybe I had missed something.

[PROGRAM STOPPED OUT OF MEMORY]
$

Mr. Moran sat at his terminal grading programs. Behind him, the blackboard, scuffed with yellow chalk, revealed the wonders of logic gate design, control structures, database design, hexadecimal arithmetic. On his desk at the head of the table, a sign read "To err is human. To really foul things up, you need a computer."

I could have just asked him, but I was afraid of wasting his time with what could turn out to be a silly question. "Mr. Moran," I said quietly from my terminal near his desk, "Can you help me?"

He looked up and told me to come over.

I pulled up a chair beside his desk and laid out the program. We looked at it together. "This procedure is crashing, and I don't know why. See, this is what it's trying to do." I explained it to him. Mr. Moran used his silver pen as a pointer, just as I imagined the computer did somewhere in the abstract matrix of memory. He followed the lines, pointing. "Hmm," he said.

I felt better. "Hmm" was good. That meant my question wasn't so stupid after all. "Hmm. It looks right," he said.

I was thrilled. Mine was a smart problem.

"Let me see," he said, getting up. We went to my terminal and I ran debug, taking him to the crash. I pictured the magic pointer, moving up and down, like a finger passing along a stack of books.

Mr. Moran looked at the code.

"Of course," he said, suddenly smiling, his face turning red. "This isn't a loop. It's recursive. Every time you call get_cheese it calls itself inside itself. If the condition is still false, it calls itself again, until the computer runs out of memory."

I was confused. "It calls itself inside itself?" Inside itself? Then it happened, as if the floor fell away from my feet and I too was falling, the bigness of the whole thing suddenly in my stomach. This isn't a loop! It's a snake eating its tail! It's infinity, the procedure self-replicating inside itself! It's creating a whole new universe inside another universe, and again and again, and would do so forever, were it not for the limits of the PDP. One inside the next, except each one is both the same size yet inside the preceding one, an impossible simultaneous state of two existences. Of course the PDP crashed. Nothing finite can contain the infinite. I'd never felt that before, the reality of infinity. There it was, a wordless revelation.

"Thanks Mr. Moran," I said. And he went back to his desk.

ORDER THE BOOK