PE 101

For some reason, this picture brightened my day


This is water

Adapted from a commencement speech given by David Foster Wallace to the 2005 graduating class at Kenyon College. Mr. Wallace, 46, died last Friday, after apparently committing suicide

There are these two young fish swimming along, and they happen to meet an older fish swimming the other way, who nods at them and says, "Morning, boys, how's the water?" And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes, "What the hell is water?"

If at this moment, you're worried that I plan to present myself here as the wise old fish explaining what water is to you younger fish, please don't be. I am not the wise old fish. The immediate point of the fish story is that the most obvious, ubiquitous, important realities are often the ones that are the hardest to see and talk about. Stated as an English sentence, of course, this is just a banal platitude -- but the fact is that, in the day-to-day trenches of adult existence, banal platitudes can have life-or-death importance. That may sound like hyperbole, or abstract nonsense.

A huge percentage of the stuff that I tend to be automatically certain of is, it turns out, totally wrong and deluded. Here's one example of the utter wrongness of something I tend to be automatically sure of: Everything in my own immediate experience supports my deep belief that I am the absolute center of the universe, the realest, most vivid and important person in existence. We rarely talk about this sort of natural, basic self-centeredness, because it's so socially repulsive, but it's pretty much the same for all of us, deep down. It is our default-setting, hard-wired into our boards at birth. Think about it: There is no experience you've had that you were not at the absolute center of. The world as you experience it is right there in front of you, or behind you, to the left or right of you, on your TV, or your monitor, or whatever. Other people's thoughts and feelings have to be communicated to you somehow, but your own are so immediate, urgent, real -- you get the idea. But please don't worry that I'm getting ready to preach to you about compassion or other-directedness or the so-called "virtues." This is not a matter of virtue -- it's a matter of my choosing to do the work of somehow altering or getting free of my natural, hard-wired default-setting, which is to be deeply and literally self-centered, and to see and interpret everything through this lens of self.

People who can adjust their natural default-setting this way are often described as being "well adjusted," which I suggest to you is not an accidental term.

Given the triumphal academic setting here, an obvious question is how much of this work of adjusting our default-setting involves actual knowledge or intellect. This question gets tricky. Probably the most dangerous thing about college education, at least in my own case, is that it enables my tendency to over-intellectualize stuff, to get lost in abstract arguments inside my head instead of simply paying attention to what's going on right in front of me. Paying attention to what's going on inside me. As I'm sure you guys know by now, it is extremely difficult to stay alert and attentive instead of getting hypnotized by the constant monologue inside your own head. Twenty years after my own graduation, I have come gradually to understand that the liberal-arts cliché about "teaching you how to think" is actually shorthand for a much deeper, more serious idea: "Learning how to think" really means learning how to exercise some control over how and what you think. It means being conscious and aware enough to choose what you pay attention to and to choose how you construct meaning from experience. Because if you cannot exercise this kind of choice in adult life, you will be totally hosed. Think of the old cliché about "the mind being an excellent servant but a terrible master." This, like many clichés, so lame and unexciting on the surface, actually expresses a great and terrible truth. It is not the least bit coincidental that adults who commit suicide with firearms almost always shoot themselves in the head. And the truth is that most of these suicides are actually dead long before they pull the trigger. And I submit that this is what the real, no-bull- value of your liberal-arts education is supposed to be about: How to keep from going through your comfortable, prosperous, respectable adult life dead, unconscious, a slave to your head and to your natural default-setting of being uniquely, completely, imperially alone, day in and day out.

That may sound like hyperbole, or abstract nonsense. So let's get concrete. The plain fact is that you graduating seniors do not yet have any clue what "day in, day out" really means. There happen to be whole large parts of adult American life that nobody talks about in commencement speeches. One such part involves boredom, routine, and petty frustration. The parents and older folks here will know all too well what I'm talking about.

By way of example, let's say it's an average day, and you get up in the morning, go to your challenging job, and you work hard for nine or ten hours, and at the end of the day you're tired, and you're stressed out, and all you want is to go home and have a good supper and maybe unwind for a couple of hours and then hit the rack early because you have to get up the next day and do it all again. But then you remember there's no food at home -- you haven't had time to shop this week, because of your challenging job -- and so now after work you have to get in your car and drive to the supermarket. It's the end of the workday, and the traffic's very bad, so getting to the store takes way longer than it should, and when you finally get there the supermarket is very crowded, because of course it's the time of day when all the other people with jobs also try to squeeze in some grocery shopping, and the store's hideously, fluorescently lit, and infused with soul-killing Muzak or corporate pop, and it's pretty much the last place you want to be, but you can't just get in and quickly out: You have to wander all over the huge, overlit store's crowded aisles to find the stuff you want, and you have to maneuver your junky cart through all these other tired, hurried people with carts, and of course there are also the glacially slow old people and the spacey people and the ADHD kids who all block the aisle and you have to grit your teeth and try to be polite as you ask them to let you by, and eventually, finally, you get all your supper supplies, except now it turns out there aren't enough checkout lanes open even though it's the end-of-the-day-rush, so the checkout line is incredibly long, which is stupid and infuriating, but you can't take your fury out on the frantic lady working the register.

Anyway, you finally get to the checkout line's front, and pay for your food, and wait to get your check or card authenticated by a machine, and then get told to "Have a nice day" in a voice that is the absolute voice of death, and then you have to take your creepy flimsy plastic bags of groceries in your cart through the crowded, bumpy, littery parking lot, and try to load the bags in your car in such a way that everything doesn't fall out of the bags and roll around in the trunk on the way home, and then you have to drive all the way home through slow, heavy, SUV-intensive rush-hour traffic, etcetera, etcetera.

The point is that petty, frustrating crap like this is exactly where the work of choosing comes in. Because the traffic jams and crowded aisles and long checkout lines give me time to think, and if I don't make a conscious decision about how to think and what to pay attention to, I'm going to be pissed and miserable every time I have to food-shop, because my natural default-setting is the certainty that situations like this are really all about me, about my hungriness and my fatigue and my desire to just get home, and it's going to seem, for all the world, like everybody else is just in my way, and who are all these people in my way? And look at how repulsive most of them are and how stupid and cow-like and dead-eyed and nonhuman they seem here in the checkout line, or at how annoying and rude it is that people are talking loudly on cell phones in the middle of the line, and look at how deeply unfair this is: I've worked really hard all day and I'm starved and tired and I can't even get home to eat and unwind because of all these stupid g-d- people.

Or, of course, if I'm in a more socially conscious form of my default-setting, I can spend time in the end-of-the-day traffic jam being angry and disgusted at all the huge, stupid, lane-blocking SUV's and Hummers and V-12 pickup trucks burning their wasteful, selfish, forty-gallon tanks of gas, and I can dwell on the fact that the patriotic or religious bumper stickers always seem to be on the biggest, most disgustingly selfish vehicles driven by the ugliest, most inconsiderate and aggressive drivers, who are usually talking on cell phones as they cut people off in order to get just twenty stupid feet ahead in a traffic jam, and I can think about how our children's children will despise us for wasting all the future's fuel and probably screwing up the climate, and how spoiled and stupid and disgusting we all are, and how it all just sucks, and so on and so forth...

Look, if I choose to think this way, fine, lots of us do -- except that thinking this way tends to be so easy and automatic it doesn't have to be a choice. Thinking this way is my natural default-setting. It's the automatic, unconscious way that I experience the boring, frustrating, crowded parts of adult life when I'm operating on the automatic, unconscious belief that I am the center of the world and that my immediate needs and feelings are what should determine the world's priorities. The thing is that there are obviously different ways to think about these kinds of situations. In this traffic, all these vehicles stuck and idling in my way: It's not impossible that some of these people in SUV's have been in horrible auto accidents in the past and now find driving so traumatic that their therapist has all but ordered them to get a huge, heavy SUV so they can feel safe enough to drive; or that the Hummer that just cut me off is maybe being driven by a father whose little child is hurt or sick in the seat next to him, and he's trying to rush to the hospital, and he's in a way bigger, more legitimate hurry than I am -- it is actually I who am in his way. Or I can choose to force myself to consider the likelihood that everyone else in the supermarket's checkout line is just as bored and frustrated as I am, and that some of these people probably have much harder, more tedious or painful lives than I do, overall.

Again, please don't think that I'm giving you moral advice, or that I'm saying you're "supposed to" think this way, or that anyone expects you to just automatically do it, because it's hard, it takes will and mental effort, and if you're like me, some days you won't be able to do it, or you just flat-out won't want to. But most days, if you're aware enough to give yourself a choice, you can choose to look differently at this fat, dead-eyed, over-made-lady who just screamed at her little child in the checkout line -- maybe she's not usually like this; maybe she's been up three straight nights holding the hand of her husband who's dying of bone cancer, or maybe this very lady is the low-wage clerk at the Motor Vehicles Dept. who just yesterday helped your spouse resolve a nightmarish red-tape problem through some small act of bureaucratic kindness. Of course, none of this is likely, but it's also not impossible -- it just depends on what you want to consider. If you're automatically sure that you know what reality is and who and what is really important -- if you want to operate on your default-setting -- then you, like me, will not consider possibilities that aren't pointless and annoying. But if you've really learned how to think, how to pay attention, then you will know you have other options. It will actually be within your power to experience a crowded, loud, slow, consumer-hell-type situation as not only meaningful but sacred, on fire with the same force that lit the stars -- compassion, love, the sub-surface unity of all things. Not that that mystical stuff's necessarily true: The only thing that's capital-T True is that you get to decide how you're going to try to see it. You get to consciously decide what has meaning and what doesn't. You get to decide what to worship...

Because here's something else that's true. In the day-to-day trenches of adult life, there is actually no such thing as atheism. There is no such thing as not worshipping. Everybody worships. The only choice we get is what to worship. And an outstanding reason for choosing some sort of God or spiritual-type thing to worship -- be it J.C. or Allah, be it Yahweh or the Wiccan mother-goddess or the Four Noble Truths or some infrangible set of ethical principles -- is that pretty much anything else you worship will eat you alive. If you worship money and things -- if they are where you tap real meaning in life -- then you will never have enough. Never feel you have enough. It's the truth. Worship your own body and beauty and sexual allure and you will always feel ugly, and when time and age start showing, you will die a million deaths before they finally plant you. On one level, we all know this stuff already -- it's been codified as myths, proverbs, clichés, bromides, epigrams, parables: the skeleton of every great story. The trick is keeping the truth up-front in daily consciousness. Worship power -- you will feel weak and afraid, and you will need ever more power over others to keep the fear at bay. Worship your intellect, being seen as smart -- you will end up feeling stupid, a fraud, always on the verge of being found out. And so on.

Look, the insidious thing about these forms of worship is not that they're evil or sinful; it is that they are unconscious. They are default-settings. They're the kind of worship you just gradually slip into, day after day, getting more and more selective about what you see and how you measure value without ever being fully aware that that's what you're doing. And the world will not discourage you from operating on your default-settings, because the world of men and money and power hums along quite nicely on the fuel of fear and contempt and frustration and craving and the worship of self. Our own present culture has harnessed these forces in ways that have yielded extraordinary wealth and comfort and personal freedom. The freedom to be lords of our own tiny skull-sized kingdoms, alone at the center of all creation. This kind of freedom has much to recommend it. But of course there are all different kinds of freedom, and the kind that is most precious you will not hear much talked about in the great outside world of winning and achieving and displaying. The really important kind of freedom involves attention, and awareness, and discipline, and effort, and being able truly to care about other people and to sacrifice for them, over and over, in myriad petty little unsexy ways, every day. That is real freedom. The alternative is unconsciousness, the default-setting, the "rat race" -- the constant gnawing sense of having had and lost some infinite thing.

I know that this stuff probably doesn't sound fun and breezy or grandly inspirational. What it is, so far as I can see, is the truth with a whole lot of rhetorical bullshit pared away. Obviously, you can think of it whatever you wish. But please don't dismiss it as some finger-wagging Dr. Laura sermon. None of this is about morality, or religion, or dogma, or big fancy questions of life after death. The capital-T Truth is about life before death. It is about making it to 30, or maybe 50, without wanting to shoot yourself in the head. It is about simple awareness -- awareness of what is so real and essential, so hidden in plain sight all around us, that we have to keep reminding ourselves, over and over: "This is water, this is water."

David Foster Wallace on Life and Work

Steve Wozniak wrote BASIC for the Apple computer in binary

“If you wanted to write a computer program like the programs of the Apple II, you would write your program with another computer that would compile the code and turn it into 1s and 0s that my microprocessor could understand. Well, I couldn’t afford this little program called a compiler. You could rent terminals and time-shared computer systems, and pay a certain amount of money per month, and you could actually write your programs. But since I couldn’t afford that, either, I wrote my programs on one side of a piece of paper by hand. Then I wrote the 1s and 0s that they would translate into on the other side, figuring it out from little cards I had about how the microprocessors work. No other project that large has probably ever been done that way. I still have the whole handwritten manual. But that made me very intimate with the code. Every little line mattered a lot, and it was a representation of myself, too. It had to be so perfect that nobody else could have thought of a better way. If I ever thought of any little section of code that had a slightly better way, I would change it and go that way. The lack of money actually helped lead to that because the lack of money forced me to be very intimate with the code I was writing. Then I would have to type the 1s and 0s into my computer. For BASIC, it took me 40 minutes. I’d turn on the power, type it in for 40 minutes, test that there weren’t any errors, and then go on debugging the next section. So it was like, no tools, no money—I did it all myself without tools, and that led to a very noticeable type of skill excellence.”



The Parable of the Two Programmers

Once upon a time, unbeknownst to each other, the "Automated Accounting Applications Association" and the "Consolidated Computerized Capital Corporation" decided that they needed the identical program to perform a certain service.

Automated hired a programmer-analyst, Alan, to solve their problem.

Meanwhile, Consolidated decided to ask a newly hired entry-level programmer, Charles, to tackle the job, to see if he was as good as he pretended.

Alan, having had experience in difficult programming projects, decided to use the PQR structured design methodology. With this in mind he asked his department manager to assign another three programmers as a programming team. Then the team went to work, churning out preliminary reports and problem analyses.

Back at Consolidated, Charles spent some time thinking about the problem. His fellow employees noticed that Charles often sat with his feet on the desk, drinking coffee. He was occasionally seen at his computer terminal, but his office mate could tell from the rhythmic striking of keys that he was actually
playing Space Invaders.

By now, the team at Automated was starting to write code. The programmers were spending about half their time writing and compiling code, and the rest of their time in conference, discussing the interfaces between the various modules.

His office mate noticed that Charles had finally given up on Space Invaders. Instead he now divided his time between drinking coffee with his feet on the table, and scribbling on little scraps of paper. His scribbling didn't seem to be Tic Tac Toe, but it didn't exactly make much sense, either.

Two months have gone by. The team at Automated finally releases an implementation timetable. In another two months they will have a test version of the program. Then a two month period of testing and enhancing should yield a completed version.

The manager of Charles has by now tired of seeing him goof off. He decides to confront him. But as he walks into Charles's office, he is surprised to see Charles busy entering code at his terminal. He decides to postpone the confrontation, so makes some small talk then leaves. However, he begins to keep a closer watch on Charles, so that when the opportunity presents itself he can confront him. Not looking forward to an unpleasant conversation, he is pleased to notice that Charles seems to be busy most of the time. He has even been see to delay his lunch, and to stay after work two or three days a week.

At the end of three months, Charles announces he has completed the project. He submits a 500 line program. The program appears to be clearly written, and when tested it does everything required in the specifications. In fact it even has a few additional convenience features which might significantly improve the usability of the program. The program is put into test, and, except for one quickly corrected oversight, performs well.

The team at Automated has by now completed two of the four major modules required for their program. These modules are now undergoing testing while the other modules are completed.

After another three weeks, Alan announces that the preliminary version is ready one week ahead of schedule. He supplies a list of the deficiencies that he expects to correct. The program is placed under test. The users find a number of bugs and deficiencies, other than those listed. As Alan explains, this is no surprise. After all this is a preliminary version in which bugs were expected.

After about two more months, the team has completed its production version of the program. It consists of about 2,500 lines of code. When tested it seems to satisfy most of the original specifications. It has omitted one or two features, and is very fussy about the format of its input data. However the company decides to install the program. They can always train their data-entry staff to enter data in the strict format required. The program is handed over to some maintenance programmers to eventually incorporate the missing features.


At first Charles's supervisor was impressed. But as he read through the source code, he realized that the project was really much simpler than he had originally though. It now seemed apparent that this was not much of a challenge even for a beginning programmer.

Charles did produce about 5 lines of code per day. This is perhaps a little above average. However, considering the simplicity of the program, it was nothing exceptional. Also his supervisor remembered his two months of goofing off.

At his next salary review Charles was given a raise which was about half the inflation over the period. He was not given a promotion. After about a year he became discouraged and left Consolidated.

At Automated, Alan was complimented for completing his project on schedule. His supervisor looked over the program. With a few minutes of thumbing through he saw that the company standards about structured programming were being observed. He quickly gave up attempting to read the program however; it seemed quite incomprehensible. He realized by now that the project was really much more complex than he had originally assumed, and he congratulated Alan again on his achievement.

The team had produced over 3 lines of code per programmer per day. This was about average, but, considering the complexity of the problem, could be considered to be exceptional. Alan was given a hefty pay raise, and promoted to Systems Analyst as a reward for his achievement.


The Story of Mel, a Real Programmer

This was posted to USENET by its author, Ed Nather on May 21, 1983.

"A recent article devoted to the *macho* side of programming made the bald and unvarnished statement:

<<Real Programmers write in FORTRAN.>>

Maybe they do now, in this decadent era of lite beer, hand calculators, and "user-friendly" software but back in the Good Old Days, when the term "software" sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.

Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a Real Programmer wrote code. I'll call him Mel, because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp., a now-defunct subsidiary of the typewriter company. The firm manufactured the LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and had just started to manufacture the RPC-4000, a much-improved, bigger, better, faster --- drum-memory computer. Cores cost too much, and weren't here to stay, anyway. (That's why you haven't heard of the company, or the computer.)

I had been hired to write a FORTRAN compiler for this new marvel and Mel was my guide to its wonders. Mel didn't approve of compilers.

"If a program can't rewrite its own code", he asked, "what good is it?"

Mel had written, in hexadecimal, the most popular computer program the company owned. It ran on the LGP-30  and played blackjack with potential customers at computer shows. Its effect was always dramatic. The LGP-30  booth was packed at every show, and the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed.

Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located.

In modern parlance, every single instruction was followed by a GO TO! Put *that* in Pascal's pipe and smoke it.

Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the "read head" and available for immediate execution. There was a program to do that job, an "optimizing assembler", but Mel refused to use it.

"You never know where it's going to put things", he explained, "so you'd have to use separate constants".

It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant.
He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.

I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way.

Mel never wrote time-delay loops, either, even when the balky Flexowriter required a delay between output characters to work right. He just located instructions on the drum so each successive one was just *past* the read head when it was needed; the drum had to execute another complete revolution to find the next instruction. He coined an unforgettable term for this procedure. Although "optimum" is an absolute term, like "unique", it became common verbal practice to make it relative: "not quite optimum" or "less optimum" or "not very optimum". Mel called the maximum time-delay locations the "most pessimum".

After he finished the blackjack program and got it to run ("Even the initializer is optimized", he said proudly), he got a Change Request from the sales department. The program used an elegant (optimized) random number generator to shuffle the "cards" and deal from the "deck", and some of the salesmen felt it was too fair, since sometimes the customers lost. They wanted Mel to modify the program so, at the setting of a sense switch on the console, they could change the odds and let the customer win.

Mel balked. He felt this was patently dishonest, which it was, and that it impinged on his personal integrity as a programmer, which it did, so he refused to do it. The Head Salesman talked to Mel, as did the Big Boss and, at the boss's urging, a few Fellow Programmers. Mel finally gave in and wrote the code, but he got the test backwards, and, when the sense switch was turned on, the program would cheat, winning every time. Mel was delighted with this, claiming his subconscious was uncontrollably ethical, and adamantly refused to fix it.

After Mel had left the company for greener pa$ture$, the Big Boss asked me to look at the code and see if I could find the test and reverse it. Somewhat reluctantly, I agreed to look. Tracking Mel's code was a real adventure.

I have often felt that programming is an art form, whose real value can only be appreciated by another versed in the same arcane art; there are lovely gems and brilliant coups hidden from human view and admiration, sometimes forever, by the very nature of the process. You can learn a lot about an individual just by reading through his code, even in hexadecimal. Mel was, I think, an unsung genius.

Perhaps my greatest shock came when I found an innocent loop that had no test in it. No test. *None*. Common sense said it had to be a closed loop, where the program would circle, forever, endlessly. Program control passed right through it, however, and safely out the other side. It took me two weeks to figure it out.

The RPC-4000 computer had a really modern facility called an index register. It allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series. He had only to increment the index register each time through. Mel never used it.

Instead, he would pull the instruction into a machine register, add one to its address, and store it back. He would then execute the modified instruction right from the register. The loop was written so this additional execution time was taken into account --- just as this instruction finished, the next one was right under the drum's read head, ready to go. But the loop had no test in it.

The vital clue came when I noticed the index register bit, the bit that lay between the address and the operation code in the instruction word, was turned on --- yet Mel never used the index register, leaving it zero all the time. When the light went on it nearly blinded me.

He had located the data he was working on near the top of memory --- the largest locations the instructions could address --- so, after the last datum was handled, incrementing the instruction address would make it overflow. The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction. Sure enough, the next program instruction was in address location zero, and the program went happily on its way.

I haven't kept in touch with Mel, so I don't know if he ever gave in to the flood of change that has washed over programming techniques since those long-gone days. I like to think he didn't. In any event, I was impressed enough that I quit looking for the offending test, telling the Big Boss I couldn't find it. He didn't seem surprised.

When I left the company, the blackjack program would still cheat if you turned on the right sense switch, and I think that's how it should be. I didn't feel comfortable hacking up the code of a Real Programmer."