Chapter Two:
Tech

The Hacker Skill, concentration, resourcefulness, attention to detail. Aversion to authority, organization, governance - the symbol of anarchy hovers nearby. The Hacker has few friends but a prodigious appetite for caffeinated soft drinks. The computer might burn metaphorically with the Hacker's productivity and innovation, or it might just be actually burning - as the Hacker destroys it for fun. His powers are great; he could rule the Valley - if he could just see the big picture. The Hacker appears against a field of green; he is jealous of your computing resources. Innovation, brilliance, unconventional wisdom. Reversed: destruction, perversity, immaturity, bad personal hygiene, profound personality deficits. Silicon Valley Tarot © 1998, Thomas Scoville.

I have described all of the above fifteen qualities of the personality of the techie as an an aid to your evaluation of your own strengths and weaknesses. As such the list has been mostly descriptive, documenting the way things tend to be. (I did throw in a little advice, because I can't help myself.) If you don't have most of the above qualities (foregoing the orneriness if you can), you just might not be a techie. (Apologies to Jeff Foxworthy's line, "You just might be a redneck..." in You Might Be a Redneck If..., 1993 audio comedy album [ASIN: B000002MKQ].)

From here on out, I will be prescriptive, offering you concrete advice on how to improve your technical capabilities.

{2.5} SUPERLEARNING

Education is what survives when what has been learnt has been forgotten.
— Burrhus Frederic Skinner (1904 - )

Media guru Marshall McLuhan wrote in Culture Is Our Business [ISBN/ASIN: 007045437X] in 1970:

Now is the first 'software' generation. The TV youngsters are the first to be divorced from the old dominant hardware of books and machines. This generation was babysat by TV. They watched it from their play pens. Gray at age three, they had seen the gamut of adult violence and confusion in every part of the world. At the age of six, confronted by the old schoolhouse hardware of texts and tests: See Dick run, See Jane jump, ... [they] dropped out.

This was written two generations ago, but it is even more true in the internet era. Many of the students in my child's grade school class have broadband cable modem at home, and most have cable TV. Meanwhile, the school is still looking forward to the day they can have one computer in each classroom, and then they still won't know what to do with it. I am quite certain most students will have a laptop computer in their backpack, as well as internet access on their cell phone, long before their school issues them their own computer for classroom use.

The point is that our slow-changing educational institutions treat information as a scarce commodity to be rationed, as it was in our agrarian past. In the little red schoolhouse, books were often shared because there weren't enough to go around, and much time was consumed with lining up, taking attendance, handing out and passing in assignments, attending to discipline, and other activities besides the actual learning. But in today's world the problem is information overload, and the skills students need are more along the lines of:

• deciding what's worth paying attention to,
• asking good quality questions,
• tuning out irrelevancies,
• judging the quality and reliability of information sources,
• concentration and focus, and
• documenting or otherwise capturing good information for later reference, once its utility has been determined.

For example, I spent a half-hour in a quick research project a few years back. I had just loaded the latest Java 2 Software Developers Kit (J2SDK) from Sun (now Oracle: java.oracle.com [LINK_2-37] ), which was up to version 1.4.1 at the time, and I wanted to see if some of my old code from version 1.0 still worked, as a quick sanity check. I compiled a randomly chosen applet, and got a warning that I was using an Application Programming Interface (API) that was "deprecated." This was Sun's way of warning me that some day my code won't work unless I upgrade it, but I was still in the "grace period" before total lack of support. I had been seeing this warning for years, and I'd known that sooner or later I would need to do something about it. I decided then and there that "today was the day."

Just to make a point, I went to the web site of a local community college to see if there was a class I could take that might provide the answer. On their web page I found the course description for CS182: Introduction to JAVA Programming [LINK_2-38]:

CS182: Introduction to JAVA Programming
4 Units (3 lecture hours, 3 lab hours)

Introductory course in the basics of the Java programming language focusing on object-oriented methodology. Topics covered include classes, methods, parameters, arrays, modularity, abstraction, exception handling, and stream and file I/O. In addition to writing and using new classes, students will utilize the AWT and/or Swing libraries of classes. Basic inheritance is introduced, although it is covered in more depth in the Intermediate Java programming class.

Semesters Offered: Fall, Spring

I'm sure this is a fine course, and I don't mean to imply otherwise. (After all, a friend of mine teaches there.) But I wanted an answer in half an hour, not half a year. So first I asked the computer. When I used the "-deprecation" option, the Java compiler even told me which lines of code used the offending method. The first was:

int wid = size().width;

and the problem was identified as:

warning: size() in java.awt.Component has been deprecated

So I went to the Google search engine:

google.com       [LINK_2-39]

java.awt.Component size deprecated

Which brought me to a java.awt Class Component page:

java.sun.com/j2se/1.4/docs/api/java/awt/Component.html       [LINK_2-40]

(Note that the page is now hosted at docs.oracle.com, since Oracle bought Sun, but a redirect still works.) Here I found that the size() method had been "Deprecated. As of JDK version 1.1, replaced by getSize()" — and farther down, this documentation of the getSize() method:

getSize public >Dimension getSize() Returns the size of this component in the form of a Dimension object. The height field of the Dimension object contains this component's height, and the width field of the Dimension object contains this component's width. Returns: a Dimension object that indicates the size of this component Since: JDK1.1 See Also: setSize(int, int)

Bingo! What I needed to know in less than half an hour. I changed size() to getSize() in two places and the warning went away, and my code was safe until the Java folks changed something again.

I like to think that Marshall McLuhan would be proud. Here I taught myself something I needed to know, completely bypassing the traditional educational system. Of course, I didn't get a grade, or earn any units at an accredited university, but it didn't cost me much time and effort, or any money (beyond what I already spend on bandwidth and PC maintenance), either.

So what can you do to improve your superlearning skills? In the sections that follow are the principles I recommend.

{2.5.1} Get To The Bottom of Things

There are layers of knowledge. Most people seem satisfied with the most superficial of explanations. (This may explain how pervasive urban legends are.) Usually there are deeper explanations available. Sometimes it is actually possible to get to the bottom layer. It is worth the effort.

For example, In learning to play chess, some people get only as far as learning how each of the pieces move normally. But there are more subtle details: castling with the king and rook, queening when a pawn reaches the eight row, and en passant — a tricky form of capture by pawns which have not left the second row. Also, there are subtleties in the protocols of the game: the touch rule (if you touch a piece you must move it), the fact that the king is never actually captured in play (it is either mated or resigns), and the rule that if the same position, with the same player to move, is repeated three times in the game, the player to move can claim a draw. I have met many players who are unaware of these subtleties, but these rules are few in number and it is not difficult to learn them all.

Often I have found that this effect manifests as a tendency for knowledge to be simplified into lists of three categories. For some reason when you probe deeper, the number often turns to six. For example:

• We are taught as children that there are three "primary" colors: red, yellow, in blue. But in fact, when colors are added (like when you shine multiple spotlights on a white screen) the primaries are red, green, and blue. (These are the colors of the dots on a color TV or computer monitor.) When colors are subtracted, like when light is passed through successive filters or gels, the primaries are magenta, cyan and yellow. (These are the colors of inks in a color printer.)

• We are also taught as students that the three phases of mater are solid, liquid and gas. But in fact, scientists now recognize six phases of matter: solid, liquid, quasi-crystals (which are like gelatin), gas, plasma (superheated gasses of atoms with their electrons stripped off), and degenerate matter (the super-dense material that neutron stars are made of).

• It is frequently said that the time zones of the United States are three hours across (from Eastern, through Central and Mountain to Pacific), that is, the most you should have to change your watch after a transcontinental flight is by three hours. But if you include Alaska and Hawaii, the country is six hours across, since you must add the Alaskan, Aleutian and Hawaiian time zones to the west.

{2.5.2} Develop Your Technical Reading Skills

When I have trouble getting to sleep, especially on road trips, I've found nothing works quite as well as reading a tech manual in bed, especially if it's poorly written, full of grammatical and technical errors, and otherwise confusing.

But if I'm not trying to fall asleep, reading technical manuals can be a challenge sometimes. I have evolved these strategies:

1. Read the table of contents aloud.

   To avoid disturbing coworkers, and to keep blood flowing to my brain, I usually do this while taking a walk around the outside of the building. When the information goes in your eyes, comes out your mouth — and you can feel your jaw moving — and then it goes back in your ears, it makes more of an impression because all of your senses are involved. Later, when you encounter a problem with some specific nuance of a technology, you are more likely to remember that there is a section or appendix that discusses it.

2. Don't read lying down.

   Sometimes it can help to read standing up, just to keep alert. If I'm staying in a hotel, sometimes I'll go down to the bar and sit on a stool. (Have a coffee, or decaf if it's late, or maybe a tonic water with lime, but no alcohol — not for this activity.) If you're stuck in your room, sit at the desk, or in a chair, or if there are no other options, on the edge of the bed.

3. Distinguish skimming (fast) from dredging (slow).

   When you first get a technical document it is a good idea to skim through it quickly, just to get an idea of what's in it: big blocks of text, diagrams, code examples, or what have you. But sooner or later you're going to have to go through it in detail, which I call dredging.

4. Mark your place with a Post-It^TM note.

   When you're reading a novel, you can mark your place with a standard bookmark and next time you read it's not too hard to find where you were on the page. But with the higher density of information in a technical manual, you can waste a lot of time finding your place, and also sometimes miss stuff. That's why I prefer to mark the exact spot I stopped reading with a yellow sticky.

   If what you are reading is vital to your job, you may want to go one step further and — in pencil — initial and date each paragraph after you read it. This is a great antidote to the tendency to start skimming a book when the text starts getting very impenetrable, which can in turn lead to just flipping through pages, and then tossing the book aside in despair. If you initial a paragraph, you are putting yourself on the line as having read and comprehended it. Which leads me to the next tip...

5. Don't go on until you understand.

   If something doesn't make sense, slow down. (If nothing makes sense, you're reading the wrong book. Ask around until you find the right book.) Everything is there for a reason, and what comes next usually depends on what came before, so make sure you "get it" before you continue.

   If you can't figure it out, there are a few alternatives: it is very badly written, or there is a typo, or you lack some prerequisite. If this book comes from the company you work for, the good news is that there must be somebody (if only the person who hired you) who really wants you to succeed, and can get you help. If you can figure out the mess, you will have a extraordinary opportunity to make a contribution: you may help in the process of making the book more understandable. After all, companies with gibberish in their tech manuals can have lots of trouble selling their technology.

6. Write down your questions.

   If you can't get help right away, and you encounter minor barriers to understanding (some jargon or an acronym you don't know, or reference to a procedure you don't know how to perform, for example), then write down your questions. When you have a full page of questions, go find answers. If you don't understand the answers, persist, or ask someone else. Sometimes it's even useful to ask the same questions of different people and compare the answers. If you want to see sparks fly, email everybody you asked the questions all of the answers you got, and then stand back while a debate ensues.

7. Intermix reading with experiments.

   You can only read so much before you need to try things out. This is why most science classes have labs. If you just read without experimenting you won't know what the real problems and issues are. Conversely, if you just experiment without reading you will typically miss large aspects of the subject that you didn't stumble on. Intermixing them is ideal.

8. Get third party books whenever possible.

   In most cases the official documentation for a product is misleading, in that it won't tell you when something is poorly designed or hard to use. After all, the manual is a sales tool. But, if it exists, a "third party" book written by someone who doesn't work for the company will share these insights with you. When you are going crazy because something seems funky, it can be a big help to read in a third-party book that, yes, it really is funky.

   To aid you in tracking down these books, it really helps to find a good technical bookstore that covers your field. (A general purpose bookstore is usually not good enough.) Often these tech bookstores are in industrial parks, or near universities, or especially in industrial parks that are located near universities. Campus bookstores are also sometimes good. Also, some computer and electronics stores have good book sections. Ask around. If you run across someone with a well-stocked bookshelf, ask them where they shop. Also, you can look on the web for on-line specialty bookstores, as well as get recommendations there. But I really like being able to examine the books before I buy, and being able to talk to knowledgeable staff.

   This brings me to how I shop for tech books. I wait until I have a problem that confounds me, and I can't seem to solve any other way (on-line documentation, web search, asking around, etc.). Then I go into my favorite tech bookstore and look at each book on the topic. Using the index, I look for the answer to my question. Whichever book provides the most useful information is the one I buy. It has worked every time for me. (If no book has the answer, I don't buy any of them.) Also, sometimes when I am trying to solve a tough technical problem, just flipping through books at a bookstore gives my an inspiration of a new approach. (No, really.)

{2.5.3} Write Your Own Documentation

It is sad but true that techies must often reverse-engineer the user interfaces and Application Programming Interfaces (APIs) for products they have legal licenses to, or even products made by their own company, due to the dismal state of documentation.

The reasons for this are many, but the main ones I've encountered are:

• the tech writer may be incompetent (this actually doesn't happen very often)
• engineering was very late getting the product done, and didn't give much help to the writer in advance, and so on "release day" the product was dumped in the writer's lap, who hurriedly got the book done — this then allowed engineering to blame some of their delay on the writer, creating a "smokescreen" for their own failings
• the company doesn't like for its customers to able to figure out the product without the help of their expensive post-sale consultants (this of course is madness)
• in a "boom" year, the product is changing so fast (due to competitive pressure) and there are so many releases a year that there is never time to get the docs right
• in a "bust" year there aren't enough resources (i.e., enough money) to get the docs right

Even when you are not following a specific manual closely to learn how to perform a specific task, it is very useful to keep an ongoing technical log. Your "tech log" should record every significant problem you encounter and how you resolved it. If you face the same problem months or years later in can be invaluable. This is also a good place to record unanswered questions (as mentioned previously) and subsequent answers you find. (I will have more to say about this in section 2.10, "THE ART OF TROUBLE SHOOTING AND DEBUGGING".) Of course this can be the beginning of a Frequently Asked Questions (FAQ) list to help other newbies later on.

{2.5.4} Practice Makes Perfect

Without a doubt, the way to get good at something and stay good at it is to do it every day. No amount of "crash course" study or "pulling an all-nighter" can substitute for consistent practice over a long stretch of time.

For example, in job L, I was using a programming language and a development environment that were entirely new to me. I went through the tutorial in the documentation, but then I ran out of tutorial before I had learned nearly enough. This was not a programming job per se; it was a pre-sales technical support job that only occasionally involved a programming assignment. I knew that without a lot of hands-on experience I wasn't going to have the knowledge I needed when I needed it. So one thing I did was to embark on a discipline I called "a method a day." I found a fairly complex sample program, and every day I found a method named in that code which I wasn't familiar with, and looked up its entry in the reference manuals. I also wrote a small "testbed" program that didn't do much except print out information, and I kept adding the new methods I'd learned and printing out their results.

After I'd learned enough to be able to do something nontrivial, I embarked on writing a demo application (based on a number of similar customer requests) that used many aspects of the system, and I worked on it every day I was in the office. This combination of efforts proved sufficient to get me "up to speed." This regime had several advantages:

• I quickly found out how to navigate my way through the extensive documentation,

• I found out what the real problems were that one must solve to get a job done with the tools, and

• I kept the whole process fresh in my mind, so that I could answer questions and assist customers with confidence.

Not too long afterwards, I took a self-funded sabbatical. In 1997 the small startup I had been working for had been swallowed by a Fortune 500 company, and I knew I didn't fit in to the corporate culture. (For tips on how to determine your ideal corporate culture, see section 3.4.9, "Know Where You Fit.") In cost-cutting move this company had just announced it was ending its long-standing sabbatical policy, which offered six weeks off with pay every five years. I hadn't been there long enough to qualify, but I had recently received a pay-out from a stock option from another job, and it occurred to me that I had been working steadily without more than a week's vacation for eleven years, so I bought myself a three month break. I resigned, and spent those months writing science fiction, playing with my four-year-old daughter (we took ice skating lessons together and also enjoyed an annual pass to Disneyland), and thinking about my career future. It was great, and in the end I realized I wanted to move back from the Los Angeles basin to my home town of San Diego. But I was worried that I would lose my technical edge during my hiatus from high-tech, so I made it a priority to keep programming. At that point it looked like Java was the "Next Big Thing," so I resolved to write at least one line of Java code every day. (Of course, once I got started I usually wrote much more each day.) To structure my efforts, I took the venerable classic Software Tools (1976) [ISBN/ASIN: 020103669X] by Brian W. Kernighan and P. J. Plauger, which originally gave all of its examples in FORTRAN and PL/1 (!), and translated many of the programs into Java.

A friend of mine, Wayne H., faced a similar challenge when he went into semiretirement after a very rewarding but demanding career as owner and chief executive of a computer games company (back when it was still possible for small companies to compete in that market), to concentrate for a while on raising his young daughter. He also thought Java was the Next Big Thing, and so as his main discipline he read the Java newsgroups and answered as many questions for other people as he could, and kept a tech log of his results. He found that tracking down answers to other people's tough problems (mostly by doing coding experiments) allowed him to keep his edge, and he even was able to report a number of bugs in the language to Sun Microsystems, the maintainers of the language at the time.

Both of us were able to easily transition back into Java programming jobs when the time was right as a result of keeping up our skills.

{2.5.5} Memory Improvement

"Bad Boys Rape Our Young Girls, But Violet Goes Willingly, God Save Her
(Black Brown Red Orange Yellow Green Blue Violet Grey White Gold Silver)"
— traditional mnemonic for remembering the color bands on resistors

• Use all three major sensory modes: sight sound, and touch.

  Earlier I mentioned the value of reading aloud: you see and hear the words, and feel your mouth forming them. This trio of senses can be used in other ways. Someone asks you to shred a sensitive document on your way out to lunch (and keep it out of sight until then), but you have to make a lengthy phone call first, so you put the document in your desk drawer. How to remember? Look at, touch it, crinkle it so it makes a sound. It helps to slam your finger in the desk drawer, too — pain is always memorable. While you're at it, future pace: imagine you are opening the outer door of the office to leave; imagine how it looks, sounds, and feels, then imagine asking yourself, "Did I shred that document?" That ought to do it.

  If this procedure fails, try tying a small bell to your finger, tightly, where you can see, hear and feel it.

• Come up with a checksum.

  A checksum is a number computed from a long message of some kind which provides a check against data corruption. You can do an analogous operation to help you remember complicated stuff. Say someone gives you a URL to remember:

  http://www.somedomain.com/files/documents/folders/more_files/foo.html

  A first step would be to notice there are six pieces involved, that is, six strings of text separated by slashes. A more sophisticated check would be to notice that, after the domain, the five additional pieces start with F, D, F, M, F. This doesn't guarantee that you will remember it right, but it does provide a check against the most common error: dropping out one piece.

• Chunk things into sevens or less.

  A milestone article in the psychology of perception, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" [LINK_2-44] by George A. Miller (originally published in The Psychological Review, 1956, vol. 63, pp. 81-97) argues that we can't keep more than about seven things in short term memory at one time. We see evidence of this almost everywhere humans are committing things to memory. Take the Alphabet Song most of us learned as children:

  A B C D E F G,
  H I J K LM NO P,
  

  ... and so on. The first line breaks the letters into a chunk of seven. The second line seems to use a chunk size of nine, but those pairs "LM" and "NO" (usually pronounced "ellem" and "enno") each sound like single two-syllable items, reducing the chunk size again to seven.

  If you chunk things to remember in this way, you are much more likely to retain them.

• Practice remembering.

  There are games you can play to develop your memory. Like anything else, memory improves with practice. One of the easiest games is the child's travel game, usually played on long car trips, called "I packed my bag and in it I took." The first person begins by saying "I packed my bag and in it I took..." and names something that starts with A, like an apple. The next player repeats what was said, and adds something starting with B, like a banana. Each player in turn must repeat what has been said before and then add something beginning with the next letter of the alphabet. I mention this game because it is so very easy. It is designed to be easy so that children can play it without much frustration, and what makes it easy is that it uses our memory in a way that exploits its strengths. A mnemonic device is used — the alphabet — and repetition is built in. As a result, chains of items much longer than the "magic seven" can usually be remembered fairly reliably by all players.

  In contrast, there is another memory game which is very hard, because it exploits some of the weaknesses of our memory. In this two-player game one player, the tester, fills a tray with miscellaneous junk, each item unique; for example: a hex nut, a thread spool, a ball bearing, a golf pencil, a key, a rock, a jack (from the game jacks), a ring, a penny, a thumb tack, and so on, totaling maybe fifteen items. The other player, the one being tested, has a short time to study the tray, usually about a minute. Then the tested covers their eyes while the tester removes one item and rearranges the remaining items. The tested must say what is missing. This is repeated until all of the items have been removed one at a time. People playing this game for the first time are often maddened by the discovery that they can't seem to name a single missing item correctly. Without a structure, such as a spatial organization or some narrative connecting the items, it becomes very difficult to look at the tray of remaining items and remember what used to be there. (An especially cruel variation is to play this as a drinking game, so that each incorrect answer requires one to take another drink. Of course, proficiency deteriorates rapidly.)

  If I do say so myself I am exceedingly good at this game. My secret strategy is to transfer the game into "I packed my bag..." through associations. In the above example, as I studied the tray for my minute, I would imagine the hex nut slid over the stem of an apple, the spool wrapped in a banana peel, the ball bearing on a cabbage leaf, the golf pencil in a dog's mouth, and so on. In other words, I associate each item with a sequence of items starting with the letters of the alphabet: Apple, Banana, Cabbage, Dog, etc. With each turn, I run back through my alphabet of associations, and quickly notice what's missing. So I have added structure, mnemonics and repetition to this game.

  If want a game that will really improve your memory, go to Las Vegas or Atlantic CIty (or a similar place where gambling is legal) and play Blackjack using a card-counting strategy. It can really improve your concentration to have your own money at stake.

  If there are logistical or moral reasons why you can't or won't do this, there is a card game you can play with friends called "The Memory Game," "Pick a Pair," and "Concentration." It was first described in an edition of "Hoyle's Rules of Card Games" around 1930 under the name "Pelanism," and the popular television game show "Concentration" is based on it. You probably know the rules, but just in case, here is a quick summary of one way to play (there are many variations):

  Remove the jacks from a deck of 52 cards, leaving 48. Deal the cards onto the table in a six by eight array, face down. Any number may play, but in practice four players is about the limit. Each player, in turn, chooses two cards one at a time to turn face up. If they match both value and color, the player takes the cards and gets another turn. If not, the cards are turned face down again. The winner is the player with the most pairs after all cards are taken.

  (I feel obligated at this point to mention that I think gambling is usually a pretty stupid thing to do. The antidote is to study probability theory. Blackjack is the only casino game in which skill plays an important part, and of course if you get any good the casinos can and will ban you. The only reliable way to make money gambling is to own a casino. I will have more to say about this in section 2.15 "RISK MANAGEMENT.")

• Let your unconscious help you locate missing things.

  Cable television comedy show "Not Necessarily the News" had a feature called "Sniglets" which offered made-up words for ideas that they thought needed new words to describe them. Later a series of sniglet books were produced. One of my favorite sniglets was "destinesia," defined as "walking into a room and then forgetting why you went there." I sometimes hear old folks complaining when they do this that they are losing their memory; young people are left without an excuse. But I have found a solution which often works: go back to the other room and continue what you were doing before. It usually takes only a few seconds to reproduce the thought processes.

  This strategy seems to me related to ways I have found to locate missing objects, especially if they were "right here a minute ago." First of all, when you are looking for a lost object, say its name. I know this may sound silly, but I have discovered quite by accident that it really helps. Countless times my wife has asked me, "What are you looking for?" and as soon as I replied, I realized I was staring right at the missing item and somehow not recognizing it.

  If calling its name doesn't work, here is a more advanced technique: get another object that is as close to the same size and shape as possible. Carry it around and try not to think about it. Pretend you are distracted by something completely unrelated. Now, put the object down somewhere. Don't think too much about where, just stick it someplace. Surprisingly often, the place you put the duplicate will be where the missing object is.

  (If there is an item which you repeatedly misplace, it is a good idea to store in the first place where you look for it. Also, you can make a frequently-misplaced item more findable by attaching something larger and/or brighter to it. I used to have trouble finding the chuck key for my drill — would always slip under other junk on my workbench. Then my my wife tied a three-foot length of fluorescent orange yarn to it. I've never lost it since.)

• Know your limits.

  Don't try to remember everything. This is no dishonor in taking and referring to notes. In fact, it is my opinion that someone who declines to take notes when being given complex instructions is not serious about getting the job done. Better to have them and not need them than to need them and not have them. Plus, the act of writing things down will help you remember.

  It pays to keep important pieces of paper in an easy-to-find-place, like a clipboard or a notebook. Even better is to "virtualize" information, by keying or scanning it into a computer. Then it can be copied to multiple places, like a web site or a smart phone.

  I have a watch I'm fond of, but I used to go nuts twice a year trying to find the instructions so I could reset it when Daylight Savings Time began and ended. Finally I scanned the instructions and put a copy on my hard drive and another on my web site, and I've never had a problem resetting it since.

To improve long-term memory, all of the above techniques will be useful, since all memories begin as short-term. In addition:

• Repetition is the key.

  Have you ever noticed that there are things like pop songs or commercial jingles which you discover you've memorized by accident, just from hearing them over and over? Your brain can't help it. When I was in school plays, I memorized by lines by recording all of my scenes on audio tape, with my lines on one track and the other actors' lines on the other track. I listened to the tape again and again, speaking my lines along with my recording. Then I played the tape with my track silenced, and practiced responding to my cues without help. It worked like a charm.

  Having a tune is also helpful. Science fiction author Isaac Asimov told the story of how, as a chemistry student, he easily memorized the name of a common chemical indicator (used in litmus paper), para dimethyl amino benzaldahyde, when an older student taught him to sing it to the tune of "The Irish Washer Woman," a familiar Irish jig in 6/8 time:

  "PA-ra di-METH-yl a-MIN-o ben-ZAL-da-hyde"

  ^     ^     ^     ^    
  B D D G D D B D B G F E

  (See sheet music for The Irish Washerwoman [LINK_2-45].) I first read this over forty years ago, and I still remember it. In fact, sometimes I can't get it out of my head.

• Learn and use mnemonic techniques.

  The best guide to mnemonic techniques is The Memory Book: The Classic Guide to Improving Your Memory at Work, at School, and at Play (1974) [ISBN/ASIN: 0345410025] by Harry Lorayne and Jerry Lucas. In the second chapter, as an exercise, they have you memorize this list of unrelated words: "airplane, tree, envelope, earring, sing, baseball, salami, star, nose." In short, the techniques is: form a ridiculous picture in your mind's eye — an association between two things. A giant tree is flying instead of an airplane, or an airplane is growing instead of a tree. Continue with this process until you get through the entire list.

  By the tenth chapter they have you memorizing a twenty-digit number. They do it by having you associate a consonant with each digit, for example, T=1, L=5, F=8, and B=9, so "beautiful" becomes "9185." Continuing this method, they end up having you associate the sentence, "A beautiful naked blonde jumps up and down," with the 20-digit number. Believe me, once you've been through the process you will never forget the number.

  Which brings me to the next tip...

• The power of vulgarity.
  "WARNING: the best mnemonics deal with sex or other bodily functions, and there are a couple of them in here!"
  — Amanda's Mnemonics Page [LINK_2-47]

  Can we talk? O gentle readers, I feel I owe you the truth. When I described my technique for playing the game with the items on a tray, I fibbed. I do not associate the items with innocuous words like the names of vegetables. I use the most obscene and taboo words I can think of that start with the sequential letters of the alphabet. I'm embarrassed to repeat any of them here. I do this because I like to win. The mind fixates on the vulgar, the rude, the forbidden, and the pornographic, in ways that it does not with blander fare. In section 3.3.5 "Your Presentation" I will talk about the importance of not discussing the traditional business taboos with associates: sex, politics, and religion. But within the confines of your own brain, this is one of the vital keys to good memory. Even the mnemonic for the resistor colors at the beginning of this section is crude and politically incorrect, though it (barely) passes muster in polite conversation — probably because it is well over 85 years old.

• Build a "memory palace."

  Our best memory is often spatial. It's part of being a mammal. Even a rat can find its way home. The Chinese have long utilized this fact to help them memorize large amounts of information.

  The Chinese pictogram system of language suffers from being nearly un-indexable. It lacks even alphabetical order. This has made the categorization efforts of Chinese scholars extremely difficult. The 16th Century Italian Jesuit Matteo Ricci journeyed to China and taught them the technique he developed called "The Memory Palace," in which knowledge is stored in a real or imaginary building, utilizing humans' natural ability to remember spatially. This is described in the book The Memory Palace of Matteo Ricci (1994) by Jonathan D. Spence [ISBN/ASIN: 0140080988].

  Ricci's work has been rediscovered in the 1980s by cognitive scientists and Virtual Reality (VR) researchers. Artificial spaces, or "cyberspaces," can be used as memory palaces.

  But you can also do it all in your head, like the Chinese often did. Imagine your own private palace of knowledge; design it with the floors and rooms you need to hold all the things you need to remember, and store your memories in it. Visit it in your imagination whenever you need it.

• Associate names with faces, bodies and voices, not clothes.

  Often in business, and especially in business travel, you meet new people whose names you will be expected to remember. I've found that when you're introduced to someone, you've got about fifteen seconds to think of a mnemonic for their name before it slips beneath the waves. Make sure you don't base it on their clothing, or anything else that might change next time you see them. Does this guy remind you of Mickey Rooney? Is it because he's wearing a sweater-vest, or because he's short? Imagine the person dressed very differently. The most reliable associations are based on face, body or voice. But make sure you do it right away!

  If you forget someone's name right after you meet them, just ask them again. Don't be shy. It is better to look a little foolish right then, than to wait hours, days, weeks, or more, and look like a complete jackass.

• Refresh old memories.

  To keep memories from fading you need to refresh them. Singing a song refreshes your memory of the tune and lyrics. Riding a bicycle refreshes your memory of that skill. But with some memories you need to be a little more proactive.

  Back when I was in school I had a habit before tests. Of course I would study, all during the semester as well as the night before. But right before the test, in the room if I was allowed to, I would take out the textbook, open to a random page, and read it thoroughly. It was amazing how often something on that page was on the test. If there was an essay question I had a detailed memory of some topic to draw upon. But also, and perhaps most importantly, I was holding the book, feeling the thickness of the pages, seeing the font of the text, seeing the color of the inks used in illustrations, and even smelling the paper and ink. All of these contributed to bringing back my memories of the class.

  One special category of memories you should refresh is names. Before you go to a company-wide meeting, read the phone list. Do you know everyone on it? Remember each face. If you are visiting a customer site, review your notes and the business cards you've carefully saved. (You do have them well-organized don't you? I like to use plastic business card holder sheets that fit in a three-ring binder.) This one tip can save you a lot of stumbling and embarrassment, especially preventing those situations where you think you remember someone's name but you're afraid to use it because you're not sure.

Six of Disks An array of disks is often all that stands between your precious code and oblivion. Why do you curse them so? Archival memory. Reversed: forgetfulness, recklessness. Silicon Valley Tarot © 1998, Thomas Scoville.

The previous sections have given you tips on how to learn quickly. An equally important question is what to learn. The following sections will delve into how to decide what's sticking in your brain.

{2.6} SEEK HIGH-QUALITY INFORMATION SOURCES

[Tech reps] are intelligent. Most of them quit education before acquiring their college degrees, but they are better educated than the average college graduate. And they continue their education throughout their lives. If Lockheed discovers a better way to do something, the tech rep in Burma will study the report in his jungle hut until he knows every nuance of the innovation, knows it perhaps better than the man who dreamed it up. Or if Lockheed overlooks something it should have been attending to, some tech rep in Bermuda or Pakistan will invent a device that will do the trick. Their knowledge is pragmatic, but profound.
— James A. Michener, 1971
      The Drifters [ISBN/ASIN: 0449213536]

These days tech reps are more likely to have degrees, mostly because colleges have evolved more technically relevant curricula, but otherwise this description is "spot on," as they say in the U.K. A good techie recognizes that information has varying value; some information has high value, some is worthless, and some even has negative value.

{2.6.1} Who needs to know?

Example: if you wanted to know a Navy ship's top cruising speed, who should you ask? The captain? He'll tell you what's in the technical specs. But if you ask the "chief," (i.e., the Chief Petty Officer), he'll tell you what the ship can really do. The key is to find not the person who should know, but the person who needs to know. When science fiction writer Ray Bradbury wanted to name a novel after the temperature at which paper book burned, he called a PhD in combustion chemistry at U.C.L.A. The man had no idea, and couldn't refer him to someone who knew. Finally, at his wife's suggestion, he called his neighborhood fire department. They had a book handy which listed it, and there was his title: Fahrenheit 451 (1953) [ISBN/ASIN: 0345342968].

Another example: author and technologist J. D. Smith needed to know how cold a roll of freezer tape could get and still hold. He called the manufacturer, 3M, and they had a design goal, but no testing data. In a flash of inspiration he asked who their biggest customer was and then called them. They'd done their own testing and knew the answer.

{2.6.2} Factory vs. field.

Another way to slice this dichotomy is factory vs. field, or engineering vs. operations. I also like to call it upstream versus downstream. The original designers can teach a lot about a technology, but the customers (or other technical end users) can often teach you more. I'm going to give two analogies to illustrate this.

• Analogy #1 — THE FISHING EXPERT

  In the romantic comedy movie Man's Favorite Sport? (1964) [ASIN: B00009IB1F] actor Rock Hudson plays Roger Willoughby, a renowned fishing expert working for the upscale New York City sporting goods store Abercrombie and Fitch. All day his customers call or visit the and talk with him, asking questions and sharing experiences of their fishing expeditions. Roger is able to relay tips from one fisherman to another. A man calls from a lake, where he is catching the limit on the north end, using a dry fly. Minutes later Roger tells another customer which lake to go to (the same one as the caller), where on the shore to fish (the north end), and what lure to use (a dry fly). Everyone hails Roger as a genius until the store enters him into a fishing competition, and it comes to light that he has never actually caught a fish in his life. He ends up in hip waders, holding a rod and reel in one hand and his own book in the other hand, attempting to master the sport in which he is an "expert." (Later a romantic entanglement completely eclipses the fishing story, but that's Hollywood.)

  This movie serves as both a cautionary tale about too much theory and not enough practice, and also a vivid illustration of the importance of information from the field.

• Analogy #2 — CANTOR'S HIERARCHY OF INFINITIES

  It's probably silly of me to attempt this analogy, because I've never met anyone who is familiar with both the obscure hypernumber mathematics of the analogy, and the practical experience of troubleshooting machinery which the analogy applies to. But I'm going to try it anyway, since I think it fits so well.

  Mathematician Gregor Cantor argued convincingly that there is more than one level of infinity. Having a bent for Jewish mysticism, he named the lowest level, the number of integers, "aleph-sub-zero" or "aleph-sub-null," using the first letter of the Hebrew alphabet and a zero subscript:

  

  This is the infinity we usually mean when we write a sideways eight. It is the answer to the question, "Given no limits on time and resources, how many lines will the following code fragment print out?"

  while (TRUE) {
  
  printline('*'); /* prints a character on a line by itself */
  }

  Aleph-sub-one, the next highest level of infinity, is the number of points in a line, or for that matter the number of points in any interval of line segment, or the number of real numbers, or, putting it yet another way, the number of different sequences of infinite (aleph-sub-zero) digits. It is the answer to the question, "Given no limits on time and resources, how many different sets of output can the following code fragment print out?"

  while (TRUE) {
  
  c = randomdigit(); /* generates a random digit from 0 to 9 */
  printline(c);
  }

  How do you compare infinities? With one-to-one correspondence. This is how you you can prove, for example, that the number of even positive integers is the same as the number of positive integers both even and odd. You can line up a list of one with a list of the other in a one-to-one correspondence. Cantor's famous Diagonal Proof shows that no list of length aleph-sub-zero can contain all possible sequences of digits of length aleph-sub-zero. For an explanation aimed at the adult lay reader with a mathematical bent, see Infinity and the Mind (1995, book) by Rudy Rucker [ISBN/ASIN: 0691001723]; for an explanation a twelve-year-old kid can understand (I know because I first read and understood it at age twelve) see One Two Three . . . Infinity: Facts and Speculations of Science (1961, book) by George Gamow [ISBN/ASIN: 0486256642].

  Okay, having dispensed with that torturous background information, here is my analogy. When engineers design and build a machine, or a software program, all of the in-house testing done either by the engineers or by a Quality Assurance (QA) department — what is usually called "alpha testing" — is of order aleph-sub-zero. Of course in reality all the testing is finite, but even if you imagine that the factory had a magical way to do an infinite amount of testing in a finite amount of time, it would still test only aleph-sub-zero cases.

  However, the testing done by users, whether in a formal "beta test" or after First Customer Ship (FCS) — which I sometimes cynically call "gamma test" — is of order aleph-sub-1. Imagine an infinite number of machines out there in the field, each exposed to an infinite sequence of inputs, demands and environmental conditions, and you may begin to see what I mean. No infinity of testing in the factory can duplicate the larger infinity of things happening in the field. This is why data from the field is so valuable. (This is what is meant by the old aphorism, "It's difficult to make something foolproof because fools are so ingenious.")

In my first tech support job (job D), I fielded phone calls from customers with our line printer controllers. I learned to keep a file of 3x5 cards with a unique symptom written at the top of each one. When I solved a problem I'd write the solution on the corresponding symptom card. It was sometimes a "many to many" mapping but it did reduce the list of things for the customer to try.

More recently when using beta software with lots of bugs and quirks, I have printed out every error message (using "print screen") and then written the solution on the page, and kept them in a handy file.

{2.6.3} Downstream data sources.

Seek out, cultivate, and refer often to downstream data sources. Some that I have found useful are:

• Working trade shows.

  Setting up and doing demos at trade shows is invaluable experience, and you should volunteer to do as much as makes sense given your job responsibilities. You learn about setting up your products away from the corporate umbilical cord. You learn about failure modes, especially after equipment has been shipped. And after talking to prospects and doing demos all day long for a week, you definitely (1) learn the demo inside and out, and (2) learn a lot more about what customers need and want, what problems they have, how much of your marketing message they "get" and how much and which parts they respond to.

  This is how I learned in 1998 that "the market" (i.e., the people spending the money) wasn't ready yet for wireless e-Commerce order tracking, no matter how cool engineering and marketing thought it was.

• Getting involved with writing specs for Consulting Engineering (CE) work.

  Whether you are technical sales, technical marketing or engineering, you can occasionally get involved in writing specs for product installation, customization and extension. This is another invaluable experience, because you will learn in detail about your customer's problems. Most of the features they are asking for will be failures or inadequacies of their old system. This work also strengthens and enhances your understanding of your company's technology, if you do it right (i.e., do the proper research and not just take "flights of fancy").

  This is how I learned that in a call center program every menu choice must also be available as a key press or sequence, for the power users who operate "keyboard only" at blinding speeds.

  Of course, if you're the one doing the Consulting Engineering work, you'll be learning even more.

• Using your company's products to get real work done.

  There's nothing like doing it yourself. This is why it's so important to create a robust demo now and then, or participate in a deployment effort. The first thing you learn is whether the product works at all. Amazingly often it doesn't.

  The secret of good demos is a lot of real-world input, and a completely plausible and interesting scenario of how the product is used.

  This is how I learned that when you are trying to visualize geological data from core samples taken from oil wells, one of the biggest problems is that the data points are miles (or kilometers) apart on the map (latitude and longitude) but inches (or centimeters) apart in elevation. Scaling the data in the vertical direction is an important first step in creating meaningful pictures of it.

• Working in Customer Support (CS).

  If your company is small enough, it may make sense for you to volunteer to work in customer support, say for an hour a day for a week. Be careful with this, because you can get stuck to the "fly paper." Make sure everyone involved — your boss, the CS manager, fellow CS employees — know it's only temporary "so you can learn." And don't spend all your time on the phone. Tracking down the answers is also an educational portion of the job.

  This is how I learned that in a 3D computer graphics system used as a military flight simulator, there are subtle and potentially tricky problems with clipping long thin polygons — like in a runway — that, in the virtual 3D space of the simulation, pass through or near the eye-point and terminate behind the eye point.

• Papers and talks on actual experiences.

  When you attend conferences, or get a chance to read conference proceedings and other journals, look for practical subjects based on hands-on experiences by scanning for keywords and phrases like "problems" and "solutions", "field," "customer" and "lessons learned," among others — anything that indicates the author or presenter is going to share what went wrong and how they fixed it.

  This is how I learned that in the world of business-to-business (B2B) e-Procurement using XML, there is a problem that has been called "the extrinsic data problem," which is basically people putting information in the wrong fields because the right fields don't exist. It is done as a "quick and dirty" fix when bringing up a system for a single customer to buy from a single vendor, and then when the system begins to expand to be multi-customer and/or multi-vendor, there are unanticipated problems, often requiring expensive and unbudgeted database schema changes combined with "data cleansing."

• War stories and blogs.

  It used to puzzle me why any techie would want to go out to a bar with a bunch of sales people they didn't work with, until I finally accepted one of the invitations I got and learned to shut up and listen. What I learned is that even nontechnical folks can contribute to your technical education, if they trust you enough to tell you the truth about their experiences with customers.

  When an installation or deployment of a vendor's technology goes wrong and the customer is unhappy, the person they complain the most to is the the one that sold it to them. Salespeople get an ear full about what went wrong.

  This, for example, is how I learned that the tradeoff for extremely reliable database operation is extremely difficult database installation.

  Of course, some of the best "war stories" will be from other techies. This is the real benefit of beer — it loosens the tongue, and sometimes the truth about technical problems and solutions comes out.

  This is how I learned that, if you program, people on the USENET newsgroups will sometimes help you fix your bugs if you ask nicely, as well as give you lots of free working code. (Not so much these days, but there are other sources of free help on forums and such.)

  Tech Tip: Earn people's trust enough to be invited out for a beer, and then listen to the war stories.

  A recent trend is the "web log" or "blog." I have found that technical blogs in which people write down every little thing they did, especially while troubleshooting, are vastly useful.

  This is how I learned that it is not unusual to have to reinstall Linux a dozen or more times to get it working.

{2.6.4} Upstream data sources.

Of course, if you are only exposed to after-the-fact feedback from the field, and never to the feed-forward of engineering design concepts and "folklore" that grew up around the products, you will become very superstitious without a deeper understanding. Here are ways to capitalize on upstream data sources.

• Standards, protocols, and Requests for Comment (RFCs).
  "Give me your tires, your power,
  Your metal chassis turning to debris,
  and I'll bill you later."

  These words, sprayed on the base of Our Beloved Lady With a Torch, remain eternal, because no individual, all alone in a democracy, has the right to remove them.

  — Proctor & Bergman, 1973
        TV Or Not TV: A Video Vaudeville In Two Acts (audio comedy) [ASIN: B0000AAZY1]

  Most technology, to some degree or other, is based on standards. The width of standard gauge railroad tracks (4 feet 8.5 inches) dates back to the width of ruts in Roman roads, or maybe even a Greek stone cart road. (See section 3.5.2 "Study the Past.") These days the Internet makes possible the adoption of new standards in record time. In the early days of the Internet — when it began as ARPANET — most new standards and protocols were advanced through the Request for Comment (RFC). Interestingly, these had no official status, and sites were free implement them or not, but in fact they served as powerful tools for building consensus and gave us our current email protocols, such as Send Mail Transfer Protocol (SMTP) and Post Office Protocol 3 (POP3), our current Web and its protocols (HTTP and HTML among others), and much more. They remain because no individual (or company) can overcome the inertia of millions of satisfied users.

  All of these standards and protocol RFCs are archived on the Web. But you have to look for them. Since they are not proprietary, nobody is going to email you "spam" or buy ads during the Superbowl to tell you about them. If you study them, you can program your own applications that conform to them, as well as propose new ones.

  This is how I learned that the original FORTAN spec included complex and imaginary numbers, but almost no vendors implemented them. Also, HTML originally had better support for mathematical notation which, again, almost no vendors implemented.

• Helping to engineer the product.

  In rare cases (for most traveling techies) you will be part of the engineering team that develops a product. This is the best learning experience available on the upstream side. The rationale behind design decisions goes hand in hand with an understanding of how to optimize performance.

  This is how I learned that the printed documentation is often wrong, and only by reading the corrections in the latest release notes can you get some products to work.

• Documentation, public and secret.

  Of course you should read all product documentation. (I cover how to do this effectively above, in section 2.5.2 "Develop Your Technical Reading Skills.") But there are other documents you also need to ferret out. Read the marketing literature, so you'll know what customers think they are getting. Dig out any information you can on the product's history. Things that make no sense in today's context can suddenly seem obvious when you know how they got that way. Something I said earlier in this chapter bears repeating: "Older versions of product documentation, or even versions for older, but related, products, often have better overviews and tutorials. Ask around and seek them out."

  You should also be on the lookout for the newest documentation, too new to release. One way to get a look at it is to approach the writers and volunteer to proofread any documentation. Unlike Customer Support and RFP work, this is a job you should be willing to do with every release. Of course, you have to actually do the proofreading, and report back what you find. You will make new friends, and always see the latest docs early.

  Also, to figure out what's really going on with a product — especially installation issues — you need to find the last thing written. (It is ironic that installation — what the customer sees first — is the last thing the engineers think about.) If you are dealing with software, or something that comes with software, look for a "READ_ME" file. Look in the box for a thin sheaf of "release notes." Ask the people who received the package, and ask your Information Technology (IT) department. Sometimes they grab release notes and squirrel them away for no good reason. Look on the Web for updates. Think about it this way: during beta test, somebody discovered that a VITAL piece of information was left out of the docs. They were in a hurry. What would be the easiest thing for them to do? What's the last thing they wrote for customers to see? Find that. There you will find your best shot at getting things to work.

• Examples that work.

  One of the best reasons to take training classes is to get working examples to study. (Another advantage is being able to ask questions, especially during labs.) If you can't take the training class, see if you can get ahold of the class notes, especially the examples and lab instructions.

  Nowhere is this more important than in programming. There is no substitute for working code. If you assemble a program from scratch based only on the reference manual, and it doesn't work, a million things could be wrong. If you take a working program and incrementally change it, testing all along, to convert it to do what you want, only the last thing you changed is suspect if it stops working.

• Working with Quality Assurance (QA).

  If you are fortunate to work at headquarters, or visit there frequently, volunteer to do a few shifts assisting in QA. There will typically be three benefits: you will win friends (with both workers and management), you will find bugs no one else does (because they all tend to get in a "groove" and you will bring a fresh approach), and you will become much more familiar with the product and its failure modes, making you more proficient and better at helping others.

• Responding to RFPs and Qs

  If you work in a technical capacity for or anywhere near a sales force, sooner or later you will be asked to work on a response to a Request for Price, (RFP) or Request for Quote (RFQ). Sometimes there will also be a Request for Information (RFI), but these have gotten rarer recently. Make no mistake, these projects can involve a huge amount of work and lots of opportunities for blame after the fact, but they are worth doing anyway, especially if you are fairly new. (Again, be wary of getting "stuck to the fly paper." Always have a reason to not keep doing them.) The main benefit of working on RFPs and similar projects is that it gives you a powerful "need to know," and an excuse to aggressively ask questions you might not otherwise.

  This is how I learned that, for a long period of time, anything that worked with Ada programs was bound to get bought by the Department of Defense (DOD).

• Serving on committees.

  Again, if you have the luxury of sitting at headquarters, volunteer to serve on any committee that deals with design or user interface issues. This gives you a mandate to seek out customer feedback as well as insight into why certain features are put into the product; you get better at both using the product and training others. In job N I served on a committee at first called the "User Interface Committee" and later changed to the "Usability Committee," and the experience was invaluable. One of the things I learned a lot about was how important it is for users to able to be interrupted — perhaps for hours or days — and then get back to what they were doing without disruption of the process.

{2.6.5} Other research tips.

There are vast amounts of information on the World Wide Web. Whole libraries have put there, as well as archives of old "question and answer" and "how to" columns from various technical periodicals. The trick is finding what you're looking for.

The three most powerful principles for web searching I have found are:

1. Pick a good search engine, and learn its advanced features.

   I like google.com [LINK_2-39] for depth and dogpile.com [LINK_2-54] for breadth.

   Google has a lot of advanced features (some undocumented) that people will teach you on various web sites. Search for the "site:" and "inurl:" and "allintitle:" operators for example, and you'll be able to do stuff like this:

   www.google.com/search?oe=utf-8&aq=t&q=site:www.cnn.com+%22Ivar+Giaever%22 [LINK_2-55]

   which searches for every mention of physicist Ivar Giaever at the www.cnn.com web site. Also, read Google's help files [LINK_2-56].

   Dogpile is a "metacrawler" that throws its searches to other search engines, so there's not much use getting into advanced stuff with it.

2. Sometimes you have to search to get an idea what to search for, and then search for that. This is especially true if you are learning about something outside of your field. For example, if you are interested in how embryos develop stuff on their "belly side," a few searches may be required before you hit the biological term "ventral," which you can then use to do more focused searching.

3. I have found that is easier to find something by example than by description. For instance, if you are looking for a list of Personal Computer (PC) vendors, it is best to look for:
   dell gateway compaq toshiba sony

   i.e., any PC vendors you can remember, which will get you links like:

   "Compare Prices and Read Reviews on Pentium 4 Laptops at Epinions ... "

   This gets you to epinions.com [LINK_2-57], which has numerous lists of all types of PC vendors. A search for a descriptive phrase like:

   "PC vendors"

   is more likely to get you links like:

   "PC vendors face technology lull - Tech Trends - CNET.com"

   The article at CNET [LINK_2-58] refers to "PC vendors" as a group but doesn't list very many of them individually; this is probably not what you want.

{2.6.6} Beware of snob appeal and "dreamspeak."

BOY CAN SEE WITH HIS EARS

SCIENTISTS ON THE VERGE OF CREATING PLANT PEOPLE


— Headlines from the National Enquirer

Naturally, one's first reaction is to chuckle and dismiss such stories as silly. But how do you know they are silly? Do you also think that is a silly question? What do you think about articles printed in Scientific American? Do you trust them? What is the difference? Is it simply a difference in publishing style?

...I must admit too that I, too, rely constantly on quick assessments of style in my attempt to sift the true from the false, the believable from the unbelievable... Were I to write the definitive guide (How to Tell the True From the False by its Style of Publication), it would have to be published to do any good; and its title, not to mention the style it was published in, would probably attract a few readers, but undoubtedly repel many more. There is something disturbing about that thought.

— Douglas Hofstadter, 1982
      "World Views in Collision" in the "Metamagical Themas" column
      of Scientific American [LINK_2-59]; reprinted in the book
      Metamagical Themas: Questing for the Essence of Mind and Pattern (1985) [ISBN/ASIN: 0465045669]
      (Copyright 1985 by Basic Books, Inc. Quoted by permission.)

It is a sad fact that people do rely on stylistic cues to evaluate the credibility of information, and for non-techies it often backfires on them. For example, earlier in this chapter I refer to Request For Comment (RFC) 1945 [LINK_2-5], which is any early version of the HTTP specification. Like most older Internet documents, it is a "raw" text file, not formatted "rich text" such as HTML (after all, it was part of the process of defining HTML). Web browsers typically display such file in a non-proportional-spaced font (like Courier), which looks like a typewriter. Here is an excerpt:

1.2 Terminology This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication. connection A transport layer virtual circuit established between two application programs for the purpose of communication. message The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in Section 4 and transmitted via the connection.

To many non-techies, this looks amateurish, like the person writing it had only a typewriter (i.e., they are poor), and didn't know how to create a document with attractive formatting (i.e., they are clueless). In contrast, a non-techie is often more likely to trust this text, which comes from the slick, arty web site of DeepBlue.com [LINK_2-60]:

DeepBlue provides strategy, technology implementation and design ranging from strategic analysis to back-end technology integration. We implement the creation of a strategic partner-based entity in order to create a full-service business solution for our clients and to help them survive and excel in the fast moving world of e-Business. We assist our clients in creating a platform to mirror its capabilities through a Website or to provide its employees, customers, suppliers, and partners with a portal to access information and to increase business efficiency.

To get the full effect, with beautiful sea creature animations and crisp, clean rollovers on the navigation bar (done in Javascript), you really have to visit the web site. The only way I could see this presentation being any more slick would be if it was in PowerPoint, and we were seeing it in a darkened wood-paneled boardroom after a big lunch with a few martinis.

But what's under the hood here? The RFC has all the information you need to understand HTTP — in theory you could use it to write your own simple web browser or server. The DeepBlue marketing prose isn't designed to teach you anything, just to sell you their (expensive) web site design services. They'd probably prefer you never found out how simple HTTP is.

Now, to be marginally fair to DeepBlue, they do add a lot of value on the aesthetic side — their web site is beautiful and compelling, and that's probably what a lot of their clients want. But the text is what I call "dreamspeak," a mixture of the legitimate terminology of business problems with feel-good, meaningless phrases and "trance inductions," designed to lull your conscious mind asleep. Even the name, "DeepBlue," seems to be tugging you deeper into your unconscious, just like a hypnotist would. (And again, to be fair to DeepBlue, virtually all high-tech marketing material is the same way.)

Wake up! Learn to evaluate the credibility of information by using it and seeing how well it works, not by the attractiveness of the fonts and color scheme.

{2.6.7} Beware of shills and covert agendas.

"Caveat emptor."
— Latin cliche

A friend of mine who shall remain nameless was once considering buying some bonds from a commissioned salesman. Her brother-in-law had questions about whether it was the best investment for her. "Well," she said, "he seemed like a nice guy. I don't think he would lie to me." I did a double-take. I wanted to grab her and shake her, and say, "Never get buying advice from the person selling!" This is especially, especially, true of bonds. Go read the book Liar's Poker: Rising Through the Wreckage on Wall Street (1990) by Michael Lewis [ISBN/ASIN: 0140143459] and learn how bond brokers count on profiting from people stupid enough to believe their bald-faced lies. And if you're still taking your stock broker's advice, do a Web search for "Eliot Spitzer" and read how stock "buy" recommendations from supposedly objective analysts were in effect for sale to publicly traded companies.

It is important to remember that some information has negative value. Otherwise, why would people pay so much to have delivered to you? Always question the agenda of your information sources.

If you read a glowing product review in a magazine sent to you for free, think about who pays the bills over there. If an industry group slams a company, check who funds them. If one person in a forum has a wildly different view than the majority, consider the possibility that they are a "plant."

A dozen or so years back I bought web service for my (non-smart) cell phone to see what that was like. On a lark I tried to use some of the default bookmarks. I thought I'd check out entertainment. I couldn't find my own city, San Diego, listed, so I followed menus that said "Entertainment," then a choice between "Places/Events," "Food/Dining" and "Music/Books." I chose "Places/Events," then "Citysearch," then "Browse Cities," then "Los Angeles," then "Music," and got one listing for a small club in L.A. featuring a band I never heard of appearing a month in the past.

"Aha!" I thought. "They are trying to get the promoters to pay for this, and nobody's signed up." A season later I did find a listing for the Dixie Chicks appearing five months in the future at the Staples Center, so I guess some of the promoters started to pay up. But how much credibility do you think I will give this service?

(More recently I've gotten an iPhone and I get the whole wild internet, not someone's walled garden path.)

And even if a source seems reliable, remember that con artists are experts in building trust, prior to exploiting it. Remember that the classic "carny" (carnival) hustle is a "bait and switch," promise them one thing but give them another. ("The only red bats in captivity" turn out to be wooden baseball bats painted red, in a cage.) A classic high-tech gambit is for the founders to build up a brand by selling quality goods at a fair price, then sell the company to scumbags who dilute and ultimately pollute the brand by overcharging for shoddy goods.

{2.7} YOUR NETWORK OF EXPERTS

Tortoise: "You admire Euclid?"

Achilles: "Passionately! So far, at least, as one can admire a treatise that wo'n't be published for some centuries to come!"

Tortoise: "Well, now, let's take a little bit of the argument in that First Proposition — just two steps, and the conclusion drawn from them. Kindly entered them in your note-book. And, in order to refer to them conveniently, let's call them A, B, and Z:

(A) Things that are equal to the same thing are equal to each other.
(B) The two sides of this Triangle are things that are equal to the same.
(Z) The two sides of this Triangle are equal to each other.

"Readers of Euclid will grant, I suppose, that Z follows logically from A and B, so that any one who accepts A and B as true, must accept Z as true?"

Achilles: "Undoubtedly! The youngest child in a High School — as soon as High Schools are invented, which will not be till some two thousand years later — will grant that."

Tortoise: "And if some reader had not yet accepted A and B as true, he might still accept the Sequence as a valid one, I suppose?"

Achilles: "No doubt such a reader might exist. He might say 'I accept as true the Hypothetical Proposition that, if A and B be true, Z must be true; but I don't accept A and B as true'. Such a reader would do wisely in abandoning Euclid, and taking to football."

— Lewis Carroll, 1895
      "What the Tortoise Said to Achilles" Mind 4, No. 14 (April 1895) [LINK_2-62]

As the reverend Dodgson (writing as Lewis Carroll) points out, the truth or falsity of theorems in mathematical logic is determined by experts who — since they were students — have correctly identified the truth or falsity of those theorems. Those without this skill are advised to take up football (soccer) instead.

As crazy as this sounds, the alternative — letting the football players vote on the math — is even worse. This is how, in 1897, the legislature of the state of Indiana nearly declared Pi equal to 3.2, halted only by the late intervention of a mathematics professor from Purdue. We need experts to save us from a democracy of ignorance.

You need your own network of experts to save you from the general ignorance that hovers like a toxic cloud around high-tech. Actually, as Will Rogers explained, it isn't so much that people are ignorant, it's that they know so much that isn't so.

• The expert paradox.

  Let's say you need a monorail mechanic. You don't know anything about how to fix monorails. How do you pick a mechanic? You can't tell one from another without your own expertise. You need a monorail mechanic selection expert. But how do you find one of those? If you knew enough to pick one, you probably wouldn't need one. You need a monorail mechanic selection expert selection expert. And so on.

  This is the problem you encounter when you learn first aid. By definition, first aid involves deciding if and how urgently medical attention is required. But don't you have to be a doctor to make such determinations?

  This is more than just a word game. Puppeteer Jim Henson died of what he thought was a flu, because he didn't think he needed to visit a hospital.

  The solution to this conundrum is to have a network of experts to draw upon. A middle-level expert can identify a great one. If Jim Henson had called up a nurse or a pharmacist for advice it might have saved his life. You need to develop a network of people who know things, as well as people who know people who know things.

• Cultivate relationships with experts.

  You need to do what it takes to get a list of people with expertise that you can call on who are willing to help you. The two qualities you are looking for are:

  1. They are an expert in something you expect to need help with.

  2. They are helpful to you.

  I have found #2 to be the hard part. Often there are people who pretend to be helpful but in the final analysis are not. If you encounter these type of people, move on. Typically, these are braggarts. Either they don't really know what they are talking about, or they do but are unwilling to share their information — they just want to establish that they have the knowledge and you don't. The warning signs are the use of the phrases: "You have to be careful," and "You have to know what you're doing." I have almost always found that if someone says either of these, and doesn't immediately follow it up with details, they probably aren't going to really help you.

  Instead you need to focus on getting help from those who give you the best help. When I was in job H, I often needed answers to technical questions in a big hurry. Sitting in a sales office in Orange County, California, calling in to headquarters in suburban Boston, Massachusetts — three time zones away — it sometimes seemed like nobody was at their phone. Although I had a good list of who in engineering was responsible for what areas, often I would settle for anybody. Either they could tell me the answer, or tell me who knows (if I didn't already know), or at least tell me if the person I was looking for was in the building. I usually called the engineering list, in alphabetical order by last name, from the top down. But a few times, to vary the routine, I called from the bottom up. The last guy on the list was a programmer named Jeff V. It seemed he was always at his desk, and always willing to help me. After a while I just starting calling him first in most cases. He never stopped helping me, and later I got some opportunities to help him as well. We ended up co-authoring a paper for a conference, and over time we became good friends. (It helped that our wives got along.) In fact, though this happened about 25 years ago, I had breakfast with him just last month on a visit to Silicon Valley.

  Admittedly this represents a best-case scenario, but things like this won't happen if you don't make the effort.

  Tech Tip: Get help from people who can and will help you.

• Your tech buddies.

  Do you have tech buddies? You should. These are friends who share your passion for tech and have overlapping skills with yours (and each other). I'm talking about friends with whom you socialize, but also engage in occasional technical projects, to learn, or to make some money, or to help out a good cause, or even for no good reason at all. This provides you with a trusted network of experts, which can be very valuable when you otherwise don't know who to trust. They can help you make sense of vendors' contradictory counter-claims, help you select other experts, and help you with problems you want to keep quiet for whatever reason. They can also help make it more fun to learn new stuff.

  One group that I am amazed to still be in contact with is a collection of buddies I've had since high school, all of whom have some kind of tech connection. Bob S. is an expert in Personal Computers (PCs), especially hardware. Wayne H. is an expert in Macintosh computers, the Java programming language and Digital Video (DV). Eric L. is an expert in embedded computing devices (chips in gizmos) and wireless communications. Thaddeus S. is an expert in digital audio and CD production. Bruce W. is an expert in computer forensics. John Z. is an Emergency Room (ER) physician and an amateur pilot. Trish S. is an expert in the use of language in animals. And so on.

  Since high school I have acquired buddies in college and in my career, in places as diverse as southern and northern California, the Route 128 "Brain Belt" in Massachusetts, the Houston/Dallas corridor in Texas, suburban Washington DC in Maryland and Virginia, Washington State, and Florida. I've found mutual interests in high-tech, aerospace, 3D graphics, supercomputing, chaos theory, virtual reality (worlds and actors), and World Wide Web (WWW) technology.

  Some of these friends I see much more than others, mostly for geographical reasons. But all have an enjoyment of challenging mental games ranging from charades to war games. With some of these friends I am fond of attending computer swap meets for cheap and hard-to-find hardware, going to learning labs for the Linux operating system to pick up software tips, shopping at electronics stores and technical bookstores, and attempting various ad hoc projects such as networking very different types of computers together, building custom digital electronic circuits out of logic chips, mounting expeditions to visit and document historical events such as the first space shuttle launch (Columbia, so sadly lost in tragedy) and the "Us Festival" (Apple computer inventor Steve Wozniak's high-tech pop music concert and fair), or even (once) building a water wheel in a creek in the woods using only material we found. (We used a Coke can for the turbine; the bearing was the hardest part.)

  With a rowdy band of rocket scientists in Los Angeles I helped produce several annual events called "The Electrobash," in which we violently destroyed nonfunctioning or obsolete electronic equipment, at first for our own benefit and mental health, later for newspaper and TV reporters, and finally in the famous "Doodah Parade" which tweaks the Rose Parade with parody in Pasadena. My proudest moment was when a television monitored its own destruction, falling three stories as it displayed an image of itself falling three stories, and finished with its own impact with the concrete pavement.

  These activities result in tech buddy bonding, ongoing reappraisal of each others' skills, and subtle competition which spurs us all on to better levels of technical proficiency.

  The news media often feature stories on tech buddy events such as egg drops (design a package to protect an egg from a multistory drop), trebuchet competitions (build a device like a catapult that hurls a projectile), and similar science and engineering stunts. The reality television shows Junkyard Wars [ISBN/ASIN: B00004WZY9] and Battlebots [ISBN/ASIN: B0002KRGAA] have capitalized on the popularity of tech buddy activities. These kind of events can be a great place to meet people with similar interests, as well as a place where you and your buddies can go and have educational fun. Also consider creating your own events.

• The headquarters visit.

  If you work in a field office of a high-tech company, the headquarters (HQ) visit is a very important event. Everyone sitting at HQ picks up information constantly through general association and "osmosis" that you have to get in bursts if you are a field employee. It is traditional that you get summoned to HQ for product training shortly after you are hired, and again for more product training every time there is a major product update, in addition to any other meetings you have to attend. It has been my experience that the training usually isn't enough. Bless them for giving it to you, every bit helps, but you usually haven't gotten the point where you can do your job by the end. Be prepared to stay at HQ. Talk to your boss about it in advance. Make sure when you book flights to HQ they are on a changeable fare, and talk to your loved ones in advance about how you may stay longer. Don't leave your car parked at your home airport so the daily charges aren't adding up. You want to able to extend your stay as necessary. The best approach is to have a high-priority project to complete that requires assistance from engineers or others at HQ. Make sure it's similar to projects you will be working on in the future, and that it really is important. If you get pressure applied by upper management on HQ employees to help you, all the better, but be aware this will also put a lot of visibility on you — you must succeed in the project. Follow this approach and you will get the crucial product training you need.

  The HQ visit is a great time to get to know engineers and other technical experts who can help you, and to get to know them better. Don't be pushy, but act interested in socializing. If you're invited somewhere — to a bar for beers, to a celebratory meal of some kind, to watch a sporting event, or better to participate in one, to visit someone's home — always accept. Use the opportunity to get to know people better. Later, when you call them for help, you will be more than a voice on the phone.

  If you know someone from a previous job, cultivate that relationship. Some of the tightest bonds I've formed have been with folks I knew in several jobs. I met an software engineer — a compiler-writer actually, and they are magicians — in job A in 1979, attending a number of parties at his house in suburban Massachusetts. Then in job H in 1988 I met him again on an HQ visit to Massachusetts, and he was the most helpful person in engineering when I got in a jam.

• Getting to step zero.

  In any instructions with a list of steps to accomplish, there is always the unwritten step zero: getting all of the prerequisite conditions ready for step one. For example, earlier in this chapter I showed how you can use the telnet program to connect with a web server. if you were to attempt this yourself, step one would probably be:

  1. In a shell, type: telnet travelingtechie.com 80

  In this case getting to step zero means having a computer which is connected to the internet, is running a shell and has a telnet program. For that matter, the keyboard needs to be connected and the display working. There are probably an infinite number of parts to "step zero," which add up to being ready to take step one.

  I bring this up now because this phase of learning any technology is when you might need an expert the most. Sometimes everything goes fine, but when it doesn't you, the newbie, are the person least able to figure it out. If you must pick and choose when you get expert help (and usually you will), this is a crucial time to have help available.

  If you are sent to a software training class and they provide computers for classroom use, bring your own laptop (if you have one — and if not, why not?) and get the software running on it as well. If you are summoned to headquarters, bring your laptop there for the same reason.

  If you are learning a programming language, the most important program is what's sometimes called the "hello world" program. I'm pretty sure this term dates from Kernighan and Ritchie's The C Programming Language (2nd Edition) (1988, book) [ISBN/ASIN: 0131103628] and this simple program:

  #include <stdio.h> main() { printf("hello, world\n"); }

  Of course it's a trivial program, just printing a message and exiting, but the point is to get it working. Compiling and linking it, finding all the files and libraries it needs, creating an executable program — these can all have problems. An expert can be well-used to help you get a "hello world" program working.

  (A collection of 133 "hello world" programs in different programming languages [LINK_2-66] is available on-line.)

• Establish yourself as an expert.

  It is remarkably easy to become both a perceived and an actual expert in a certain area over time. Simply let people know you are interested in learning more about a subject. People will send information your way. They will send you web links and forward you emails on the subject, give you stacks of old magazines on your topic they were going to toss out, and otherwise inundate you with ways to increase your expertise. Be sure to study them all carefully. Then they will send people to you with questions and problems. Work diligently to answer and solve them, for this will teach you the most. The next thing you know, everyone will be saying you are an expert on the subject, and they will be right. When you meet someone who knows more than you (or claims to), ask them to critique your advice, and to teach what nuances they know. This is how your expertise grows.

  When I was in job G, working for an aerospace company building some parts of the space shuttles and space station, I had a number of older coworkers who had been around since before the beginning of the manned space program. I expressed an interest in the history of aviation and space flight, and the next thing you know people were bringing me information. One of the most valuable things I was given was a self-published, small run book of local aviation history. If you are ever given a self-published book, cherish it. It will contain information not found anywhere else. Even though it may be hard to read, it will be well worth it. (For more on such generational differences in the workplace, see section 3.2.3 "Categories of People.")

  Of course, the whole point of becoming an expert is not to stockpile information like a miser, but to aggregate it, analyze it, improve upon it, and pass it on.

• Don't abuse your experts.

  Don't be a pest. Don't take all the time without giving back something. Don't be lazy and make it hard work for other people to help you. A good approach is to recognize when you think you're going to need a lot of help, and ask people's permission in advance to ask lots of questions over a certain interval of time. Do it only occasionally. The rest of the time don't bug them much. I've mentioned earlier the idea of collecting your questions in a queue and asking them all at once. If there's any legwork or tedium involved in your task, do it yourself first before you ask for help. Make it as easy as possible for people to help you.

  See also section 2.19 "GIVE SOMETHING BACK" later in this chapter.

{2.8} IMPROVE YOUR UNDERSTANDING OF 'META'

"recursive - see recursive"
— Stan Kelley-Bootle, 1981
The Devil's DP Dictionary [ISBN/ASIN: 0070340226]

In the particular type of high-tech that I'm involved with — computer software — I'm often amazed how really simple almost all of the concepts are, except one: what is sometimes called "logical levels," or "levels of logical type," or "map/territory distinctions," or just "meta relationships."

A lot of mental exertion went into trying to unscramble a family of conundrums involving these concepts not long after the turn of the last century, and with little in the way of clear results. Bertrand Russell and Alfred North Whitehead set out to rationalize all of logic and arithmetic with the encyclopedic Principia Mathematica [ISBN/ASIN: 0521626064] (the first volume released in 1911), which tackled a group of logical paradoxes that all have pretty much the same structure:

• Epiminides the Cretan proclaimed that "All Cretans are liars." Was he telling the truth?

• Berry's Paradox: What is the smallest number that cannot be described in English in one hundred characters or fewer? Whatever it is, is it not described by the phrase "the smallest number that cannot be described in English in one hundred characters or fewer"?

• Russell's Paradox: The barber in a town shaves all the residents except those who shave themselves. Who shaves the barber?

• Let N denote the set of all sets which do not contain themselves. Does N contain itself?

Russell and Whitehead attempted to resolve these paradoxes by forbidding them from occurring. But in 1931 Kurt Godel proved that they had failed. These type of paradoxes are built into our logic and our arithmetic, and they cannot be banned. Godel's Theorem led directly to the work of Turing and Church, which defined the idea of "computability" and lead directly to the modern programmable computer.

I come by this knowledge honestly. Russell was a mentor to neurology pioneer Warren McCulloch, who was a mentor to anthropologist and cofounder of the science of cybernetics Gregory Bateson, who was a mentor to me.

Bateson went on to use this knowledge in several ways. He was the first to describe "levels of learning," in the paper "Social Planning and the Concept of Deutero-Learning" (1942), which has resulted in the somewhat corrupted idea of "the learning curve" entering popular language. He described the role of a type of paradoxical command he called a "double bind" in triggering schizophrenia in some people, in the paper "Epidemiology of a Schizophrenia" (1955) — which gave us concepts similar to the idea of Catch-22 (1961) [ISBN/ASIN: 0684833395] from Joseph Heller's novel of the same name. Both these essays are collected in Bateson's Steps to an Ecology of Mind: Collected Essays in Anthropology, Psychiatry, Evolution, and Epistemology (1972) [ISBN/ASIN: 0226039056].

Meanwhile, cybernetics pioneer Heinz von Foerster whimsically commanded to his students: "Thou shalt not contemplate paradox," in Cybernetics of Cybernetics (1974) [ISBN/ASIN: 0964704404].

Another big fan of these kinds of paradoxes is Douglas Hofstader, who discusses them at length in Godel, Escher, Bach: An Eternal Golden Braid (1979) [ISBN/ASIN: 0465026567] and Metamagical Themas: Questing for the Essence of Mind and Pattern (1985) [ISBN/ASIN: 0465045669]. (Copyright 1985 by Basic Books, Inc. Quoted by permission.) He is fond of saying things like: "This sentence no verb." Clearly, if you fix the grammar by inserting the missing "has," the sentence becomes false. But how can it really be said to be "true" in its incomplete state?

What about, "This sentence contains exactly threee erors."

As I have mentioned earlier, the ancient (possibly 6000-year-old) stories of the Sufis seek out these types of paradoxes. For example, in one Sufi story:

The master was at the height of his harangue:

"And if I were to tell you anything of what I really, deeply know, you would not believe me. If I were even to hint at the truths which are understood by those who have attained to Truth, you would scoff; if I were to give you any statement of the amazing realities behind what you imagine to be reality, you would not credit it..."

A member of the audience held up his hand: "Surely you cannot expect anyone to believe that?"

— quoted by Idries Shah, 1977
      Special Illumination -- The Sufi Use of Humour [ISBN/ASIN: 090086057X]       (Reprinted by permission of Octagon Press, Ltd., London.)

I recommend you study these types of paradoxes from time to time, to keep you facile in the pitfalls of rigorous thought. You may ask, what use is all of this to a technologist? Let me give an example from programming. Consider this at-first-baffling exchange from one of the books mathematician Charles Dodgson wrote (under the pen name Lewis Carol). In Alice Through the Looking Glass (1872) [ISBN/ASIN: 0451527747] the White Knight is telling Alice about a song he wrote:

The name of the song is called 'Haddocks' Eyes.'"

"Oh, that's the name of the song, is it?" Alice said, trying to feel interested.

"No, you don't understand," the Knight said, looking a little vexed. "That's what the name is called. The name really is 'The Aged, Aged Man.'"

"Then I ought to have said 'That's what the song is called'?" Alice corrected herself.

"No you oughtn't: that's another thing. The song is called 'Ways and Means' but that's only what it's called, you know!"

"Well, what is the song then?" said Alice, who was by this time completely bewildered.

"I was coming to that," the Knight said. "The song really is 'A-sitting On a Gate': and the tune's my own invention."

(See also Alice Through the Looking Glass online [LINK_2-74].)

Several writers have noted the relationship between this passage and the structure of variables in computer languages. In Expert C Programming (1994) [ISBN/ASIN: 0131774298] (Copyright 1994 by Prentice Hall PTR. Reprinted by permission of Pearson Education Inc., Upper Saddle River, NJ.) Peter van der Linden wrote:

Dodgson would have been right at home with computer science. And he would have especially appreciated type models in programming languages. For example, given the C declarations:

typedef char * string;
string punchline = "I'm a frayed knot";

We can see how the Knight's paradigm can be applied to it:

type of the variable is called string
is char *
the variable is called punchline
is "I'm a frayed knot"

Programmers seem to especially love Sufi-like teasing about logical levels. There is a program in the UNIX tool set called yacc, which stands for "Yet Another Compiler Compiler." Earlier I introduced Backus-Naur Form (BNF), a language-definition language. One of its definitions of meta-syntax is:

   rule1 | rule2

       Elements separated by a bar ("|") are alternatives,
       e.g., "yes | no" will accept yes or no.

That seems pretty clear, doesn't it? When you're defining a language, you use the vertical bar to separate alternatives. But consider all the ways there are to misunderstand that meta-definition:

• not recognizing that "I" and "vertical bar" mean the same thing,

• failing to read "|" as equivalent to "or" in definitions,

• thinking that "rule1" and "rule2" are literals (also known as keywords and reserve words), and they must appear literally in a definition,

• misunderstanding the idea of a "language definition language,"

• getting confused about the quotation marks, and whether they are literals or meta-characters,

• getting confused about the "typewriter" font used for the example.

• getting confused about the fact that the example is indented, and then within the example the definition is further indented,

• noticing that the way BNF is defined is with an unnamed "language definition language definition language," and getting so boggled by the realization that you lose track of BNF...

Come to think of it, there are an infinite number of ways to misunderstand this, and I'm not sure which level of infinity that is.

In my experiences as a corporate trainer, and in talking to others in companies and universities who teach, I've learned about many of the ways concepts are misunderstood. Confusions of the meta are high on the list. Like the bones of oxen left on the trails taken by the American pioneers moving west, the failed programs of students in computer classes illustrate the problems very well.

One example seems to show a common pattern of confusion. In the standard Input/Output (I/O) library in the C programming environment, there are functions called open(), read(), write() and close(), which have the simplest names because they were coded first by the creators of the libraries. But soon they (being both the creators and first users of the libraries) discovered that these functions were cumbersome to use when accessing disk files, and that the same convenience features were needed every time they were used this way, so functions were "wrapped around" them for file I/O, called fopen(), fread(), fwrite() and fclose(), in which the f stands for "file." These functions are stuck with the cryptic names because the simplest ones were already taken. And yet they are the most often used. It is a common mistake of new C programmers to use open() instead of fopen(). When you get to object-oriented (OO) languages and object libraries, these kind of nomenclature confusions involved with levels of abstraction increase dramatically. Don't get me going about the "is a" versus "has a" distinction in C++, Java, and some other OO languages.

{2.9} DEVELOP YOUR INTUITION

Development is programmable;
Discovery is not programmable.
Since the behaviors to be sought
Are unknown,
Computers cannot be instructed
To watch out for them.
Computers can "keep track"
Of a complex behavior,
But only human mind can discern
The heretofore unknown
Unique interrelationships
Which exist between and not of
The separate bodies.
— R. Buckminster Fuller, 1973
      Intuition [ISBN/ASIN: 0385012446]

A structural engineer will know how to analyze a bridge design, how to do an engineering analysis of the stresses and vibratory modes, and will know what tools to use to help, which finite element software, as well as how to set up a grid and validate a model, and then let a computer crunch the numbers. But the engineer won't need to do all that if you ask them if you can build a suspension bridge out of tissue paper. They will "just know" the answer is "not unless it's less than a foot long." That's because the engineer will have developed an intuition for bridge design. Any expert needs such an intuition, to guide them in the use of their tools.

You get an intuition by pumping a lot of data through your brain. Make sure it's good data if you want a good intuition. If you guess at the answer to something, make sure you go back later and find out if you were right.

Cognitive scientists since Robert Ornstein (The Right Mind: Making Sense of the Hemispheres, 1997 [ISBN/ASIN: 0156006278]) have studied how the two hemispheres of the brain perform different functions. An oversimplified but useful model is that the dominant (usually left) hemisphere is involved in symbolic processing: language, logic, and analysis. The non-dominant (usually right) brain is more global in its operations, dealing with rhythms, patterns over time, and capable of simulating large, dynamic systems. Recent research suggests that this hemisphere is concerned especially with "worst case scenarios" and is constantly, mostly unconsciously, running them. This is why you can ask yourself questions about what's going to happen and often get pretty good answers, seemingly "out of nowhere."

Gregory Bateson taught me that with the awesome power of our technology our biggest danger is scientific arrogance, and the antidote is what he called "natural history." In the narrowest sense, this means the record of living things: botany, zoology, paleontology, ethology. But it in a broader sense it also concerns what humans and their machines have done: it is fair to talk about the natural history of machine failures, or of weapons technology, or of building construction and use. The development of Operations Research and Strategic Choice Theory and the rise of anthropologists and ethnographers seriously studying corporate culture, all reflect promising trends as well as sources for human industrial natural history. Something as simple as plotting the spread of computer viruses through a network or just sitting and watching users of a technology can be useful.

I'm also a big fan of models and simulations. If you get a chance to play with them, do it. Be on the lookout, at museums, in research labs, and in the guise of interactive Java applets on web sites. Educational toy stores can sometimes have a bonanza of analog models. In Mindstorms: Children, Computers, and Powerful Ideas (1980) [ISBN/ASIN: 0465046746] Seymour A. Papert, creator of the Logo computer language for teaching children, said he was inspired by a set of gears he was given as a boy, which taught him an intuition for multiplication, division and ratios. I once found a beautiful centrifugal pump with clear sides, totally visually self-explaining when you used it, at a water park in a kids play area.

Playing with simulations of complex or invisible phenomena can be invaluable. My intuition tells me that if you show chemistry students visual simulations of molecules — like this picture of water molecules aligning in a six-sided crystal structure:

(from "Water & Diffusion" by David Webb, University of Hawaii [LINK_2-79])

— or better yet let them play with an interactive computer-simulation, then later when they see the formula

H₂0

they will imagine the computer models instead. However, if you give them four years of chemistry using only the textbook formulas and then expose them to the simulation, results will not be as good.

I hope you see the common thread here: in every case I am encouraging activities to increase your intuition.

{2.10} THE ART OF TROUBLE SHOOTING AND DEBUGGING

A high-tech salesperson, a hardware support engineer, and a software Systems Engineer (SE) were riding down the road in a car when a tire blew. They got out and looked at it.

"Well," said the salesperson, "time to get a new car."

"No," said the hardware support engineer, "we have a spare in the trunk, we can start swapping around tires until we fix it."

The SE said, "Maybe if we just sit here for a while, it will fix itself."

— tech joke

Today this dead moth and attached log book page are in the Smithsonian Institute in Washington; see The First Bug [LINK_2-80].

The lesson history teaches us here is that people haven't tended to expect in advance that "debugging" would be a time-consuming process, and have been surprised after the fact how much time it ended up consuming. That's why a word had to be invented after the phenomenon was causing delays.

Before the word "debugging" was coined, this activity was often summed up by the not-very-evocative word "pitfalls." Maurice Wilkes of Cambridge was the original programmer of the Electronic Delay Storage Automatic Calculator (EDSAC), the world's first operational stored-program digital computer. In his Memoirs of a Computer Pioneer (1985) he recalls:

By June 1949 people had begun to realize that it was not so easy to get the program right as had at one time appeared. I well remember when this realization came to me with full force. The EDSAC was located on the top floor of the building and the tape- punching and editing equipment one floor below... I was trying to get working my first nontrivial program... It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angle of the stairs" the realization came over me with full force that a good part of the remainder of my life was going to be spent finding errors in my own programs.

Computer historian Martin Cambell-Kelly goes so far as to assert that "no evidence has yet emerged that anyone had conceived of the debugging problem until programs were tried on real computers." (See "The Airy Tape: An Early Chapter in the History of Debugging" in IEEE Annals of the History of Computing [LINK_2-81] 14(4), 1992.)

Therefore, all debugging "theory" is based on after-the-fact generalizations of hard lessons learned. Here is my list:

• Be precise.

  Once my three sisters and I started driving the family car, we soon learned that it was a mistake to call our father from a pay phone (this was before cell phones) and say, "The car won't start."

  (He was trained as a jet mechanic by the Air Force during the Korean War, and has a lifelong passion for auto mechanics.)

  "What do you mean, 'Won't start?'" he'd demand. "Does it turn over, go 'rowww, rowww, rowww,' or does it catch and then stall, like "Rowww, rowww, grrrRRRR- uck uck ffpt,' or does it just not turn over, 'click click.'"

  And woe be to the one who answered, "I don't remember."

  Be precise in your description of symptoms: context, messages, what happens, what doesn't happen, what's different, in both your thinking and your communication. Avoid pronouns and vague nouns (it, them, thing); find out the names of components and use them. If time is involved, time events with a stopwatch (a feature on most modern watches and smart phones).

• Be systematic.

  I remember an odd cartoon, "Idyl" by Jeff Jones, which appeared in the "Funnies" section of "National Lampoon," for years. In one 3-framer, the heroine sees two barrels. "I wonder what's in those barrels," she says. She takes the lid off of one, says "Nothing in that one," and walks on leaving the other unopened.

  My reaction to this was, she should have either opened both of them or none of them. There's an economy of information issue here: it is easier to store the knowledge "nothing is in any of those barrels," or "I don't know what is any of those barrels," than "I only know one of those barrels is empty," (which one?), and you can draw fewer useful conclusions from the latter knowledge.

  In troubleshooting of all types, it is important to be systematic, and to try all combinations necessary to eliminate possible causes. Don't just "fiddle" with things.

• Write down what you do.

  If you aren't able to solve a technical problem quickly, start writing down what you do. Otherwise, your mind will play tricks on you!

  There is a psychological experiment in which subjects must repeatedly press buttons in response to patterns of lights, and then a special "right or wrong" display lights up green if they did it right or red if they did it wrong. The trick is that the red/green light is random at first, but over time it displays green more often until at last it is green all the time. Subjects swear they have "figured out the rule" for setting switches based on the pattern of lights, when in reality they are fooling themselves based on random encouragement. The hope and yearning for a quick solution can blind a person. If they had written down each step, they would realize this more easily.

  Some of the hardest bugs to find are intermittent problems, and two unrelated causes for the same symptom. Both these maddening cases can be more easily detected if you are keeping good notes.

• Only change one thing at a time, if possible.

  Sometimes this is impossible, especially in the life sciences, or in field work of various kinds. Sometimes lots of variables are beyond your control and changing all the time, and you're lucky if you can just measure them. Sometimes the length of time required to do a single test is so long (or the deadline so short) that you have to try a couple of things at once. In these cases good notes may save you. But if you don't face these constraints, then by all means change just one thing at a time. You can often end up with "superstitious" behavior — thinking that something is important when it isn't — when you change several things at once and a problem goes away. If this happens while you're in a crisis mode, make time later when things are calmer to systematically try all combinations, and figure out what the real answer was.

• When changing something doesn't work, change it back.

  This is important if you are fixing something that used to work and stopped working. If you go forth changing things one at a time, testing in between, but not changing them back afterwards, chances are you will disable what you are troubleshooting in one or more new ways before you stumble on the fix, and by then the test will fail due to the new problems. It's a recipe for disaster. The solution is to always change each thing back before you move onto the next one.

  If you are working on something that has never worked before, you are going to have to try a whole lot more combinations. Try to find a working example to compare and copy if you can.

• Create the simplest example with the bug.

  Early in my career I was charged with "porting" FORTRAN benchmark programs to a new computer, and I was routinely given 100,000-line programs to work on. If I hit a bug in the FORTRAN compiler, I found that sending the complete program to software engineering with a note, "this broke your compiler" just got the bug report thrown back at me. It was my job to find the simplest program that reproduced the bug — and often just a few dozen lines would do it, though it might take considerable effort on my part to find them. But this is your job, as finder of the bug. Reduce the situation to the simplest possible while preserving the symptom. if you solve the problem yourself, this will make it easier. If you get help, the people helping you will appreciate it.

• Check the last thing you touched.

  People working phone support have users lie to them all the time: "It stopped working."

  "What changed since the last time it worked."

  "Nothing!"

  The "nothing" in question sometimes turns out to include reinstalling the computer's operating system and moving the software to a new piece of hardware entirely.

  Don't lie to yourself about this. Honestly ask yourself what's changed since before the symptom appeared, and look into each possibility.

• Think like a "devil's advocate."

  When a symptom seems baffling, ask yourself, if it was my job to play an elaborate prank on someone and cause this symptom to appear in an otherwise seemingly OK system, how many different ways could I think of to do it? Check them all out, even the ridiculous.

  Since the days of DOS Microsoft has provided what are called "environment variables" in their operating systems. In the old days you set them in a text file with AUTOEXEC.BAT as its name. Since the days of Windows NT there has been a Graphical User Interface (GUI) for setting the variables. Come the year 2000, in WindowsME (Millennium Edition) they went back to the AUTOEXEC.BAT file. (Hacker joke: If Lee Iacocca was bitten by a vampire, he'd be... what?) So one day I found a variable in my system that wasn't set in the AUTOEXEC.BAT file, but still showed up set after a reboot. Weird. I used the Devil's Advocate technique: if it was my job to cause this symptom, I'd have a second, secret AUTOEXEC.BAT file somewhere. So I searched, and sure enough there was another, and that's where the variable was set.

• Break things on purpose.

  Sometimes you can work backwards to a solution if you have an identical system that works, and you can experiment with "breaking" it in various ways to see what the symptoms are. This can be a good way to rule out theories, but it doesn't usually prove a cause conclusively. Still, it improves your database of symptoms and causes. Look for opportunities. If, for example, six servers are sitting in a staging area waiting to be shipped to a trade show, it might be a good time to try breaking the demos, with both hardware and software changes, seeing exactly what the symptoms are, and writing it all down. Who knows; it could save your job at the trade show later on.

• If the bug isn't where you're looking, it must be somewhere else.

  Okay, this is a truism, but it has helped me. First of all, sometimes the bug is where you're looking, and you're staring right at it but you don't see it. That's where "get another pair of eyes" comes in. I guess technically it's a mild form of temporary insanity, but it happens to the best of us. The rest of the time, we're staring right where the bug isn't and we don't see it, because it isn't there! We need to be looking somewhere else, working towards testing all of our assumptions.

• Get another pair of eyes.
  THE LAW OF THE TOO SOLID GOOF

  In any collection of data, the figures that are obviously correct beyond all need of checking contain the errors.

  Corollary 1: No one you ask for help will see the error either.

  Corollary 2: Any nagging intruder, who stops by with unsought advice, will spot it immediately.

  — quoted in innumerable places on the web [LINK_2-82]

  One time I was tutoring a new-hire in the programming of an object-oriented web development system. It started with an HTML template file, which contained an OBJECT tag, pointing to an object, which executed a script file, which fetched data from a database and populated variables in the script, which returned an HTML fragment which was plugged into the template file. But in the example I was showing him, nothing worked. We checked the object name, the script, the database fetch, the data in the database, and then in despair went to another programmer. He immediately noted the word "OBJECT" misspelled as "OJBECT" in the tag in the template file, the first place we'd looked.

  If you can't find someone who knows more than you do about the subject at hand, settle for someone with an eye for detail. They often find the blatant errors because they don't have the skill set to look for -- and aren't distracted by -- the subtle ones. In job G , I was part of a team that was bidding on a portion of the United States space station construction contract. We literally had to deliver several boxcars full of documents for our response to NASA. A few days before it was due management asked all 300 of us in the division to work in shifts, around the clock, proofreading the final documents. At least half of that number were aerospace engineers and rocket scientists, but it was an administrator (what used to be called a "secretary") who found the simple arithmetic error on page six.

  Sometimes, just attempting to explain the problem to someone else will cause you to realize the error. If you are stuck, get whatever help you can. Which brings us to the techie's secret weapon...

• Call the support number.

  This seems like one of the great secret weapons of the techie. Not that's it's a secret, but people act like it is. There's a hard part and an easy part:

  • The hard part: gather all the information.

    The most vital information is who to call, and any serial number, product number, warranty number, or other information to prove they have to help you. Sometimes this means you have to back trace the product as it entered the company, and end up with the first person who touched it, and then find out where they put the packing materials, and if they haven't been thrown out yet fish around among the foam peanuts and find the missing manual, or warranty card, or packing slip. Possibly the toll-free number is on the box itself. But if you are willing to dig into this mess and get the right number, you've passed a test that many have failed.

    You also need to have a clear description of the symptoms and any configuration information you have about the product.

  • The easy part: dial the phone.

    (If they haven't already, young people will soon begin asking why anybody would say "dial the phone.")

    Be sure to call from the place where you are troubleshooting the product, from the lab or computer or machine where you will be fixing the problem. Running back and forth to a phone and "batching" information makes things very difficult. Use a cell phone if you can.

    Make them stay on the phone until your problem is resolved, or at last diagnosed and a plan given for the solution. Don't let them give you a theory and hang up, so you end up having to call back if it doesn't work.

  Early in my job at job H, I was still proving myself as the only techie in a fairly new sales office. One day my boss brought in a Microsoft mouse for his 1988 IBM Personal Computer (PC), running Microsoft's Disk Operating System (DOS). After hassling for half a day, he asked me for help. I found the toll-free number on the back of the pamphlet of documentation, called Microsoft, and found out that Microsoft mouse didn't work with that Microsoft DOS. "How can a Microsoft mouse not work with Microsoft's DOS?" he asked.

  How can you answer a question like that? Saying "Because they're idiots, and you're one too for thinking they're infallible," is not very good office politics. I ordered him an upgrade to the DOS, which — once it arrived on a diskette in the mail — solved the problem.

  My wife once used this same trick and got her salary almost doubled as a result. She was working as an Animal Health Technician (AHT) at an animal hospital, assisting in surgeries. The state of California licenses AHTs, but doesn't require veterinarians and animal hospitals to use licensed staff, and a lot of young, unlicensed people love working with animals, so the pay is not so great. One day the folks in the front office asked if anyone knew how to get a printer working with a PC. My wife volunteered to give it a try, shook them down for the installation booklet, called the toll-free number and got the problem resolved. They offered her an office position at nearly twice the pay, and she's never looked back. (She's done zoo volunteer work whenever she misses animals.)

  Of course the post-cyberspace equivalent of this is looking on the web, though the phone has not gone away; you can still work wonders on the phone. But for completeness look on the web at:

  1. the vendor site; try to find searchable customer support notes, or else use Google advanced search to search the vendor site
  2. standard search engines looking for local customer support pages, class notes, etc.
  3. forums

  Be sure to search for your hardware model, software environment (if applicable), and if you get a text error message, search for it exactly. You may have to use the search strategy I described earlier of searching for what to search for. The exact name of a device driver file, for example, may be the best thing to search for.

• Don't try to implement a complex system from scratch and then debug it when it has never worked.

  As I have explained elsewhere, when you start with something that works and modify it to do what you want, you know which step breaks it, and can look at only what you just changed. If you try to assemble a system from scratch, you must look at everything to debug it.

  When relationships between parts are important, complexity rises as approximately a square of the number of parts. You can never beat those odds. Start with a demo, anything that works, make small modifications incrementally.

  Of course, sometimes you're struck with a mess, but that doesn't change the fact that starting small is the only sane way to proceed.

  Tech Tip: Start with something that works and carefully turn it into what you need, testing constantly.

• Design in testing.

  This is the first thing you want to do, but I list it last because it's perhaps the hardest, and takes a lot of advance effort. But it pays off in stability and bug-free operation. As Gregory Bateson once pointed out, a machine when working properly keeps a number of logical propositions true. "The shaft spins at a rate within the range set on this lever." Or, "The customer's address is now loaded into the contact database." Build in ways to test these propositions. Assume anything can go wrong. Assume someone else is going to come along later and botch your great creation, so give it some survival skills of its own. Let it ask for help when errors occur.

Bugs Unwanted visitors crawl across your precious code, causing abrupt, graceless terminations and other unintended consequences. Perhaps your system just hangs; reboot and fire up the debugger. Can you crush them all? Not in a million years. Trouble, unforeseen complications. Reversed: Poor quality, shoddy workmanship, lack of attention to detail, overworked Q/A division. Silicon Valley Tarot © 1998, Thomas Scoville.

{2.11} KNOWING WHAT'S EASY AND WHAT'S HARD

Making things easy is hard.
— Theodor H. Nelson, 1974
      Computer Lib/Dream Machines [ISBN/ASIN: 0893470023]

One of the most valuable things you can contribute as a traveling techie, especially if your role includes advising non-techies, is your intuition for what is easy and what is hard. You can help both with the identification of opportunities and the avoidance of fiascos.

Here are some examples from my own experience of what's easy and what's hard, with an emphasis on things that non-techies seem often to confuse.

{2.11.1} What's easy:

• Accumulating data over time.

  It's pretty clear to me here in 2014 that the "hard drive" disk as we know it is going to quickly become obsolete, replaced by all-chip "memory sticks" of some kind with no moving parts. Whether it's measurement data, mouse clicks, emails, digitized songs and video, or results of calculations, it is cheap and easy to accumulate data, and it will get cheaper and easier. Yet there are people in corporate America who hear nothing but "no can do" when they ask for special reports from their Information Technology (IT) staff.

• Communicating data between systems.

  Vendors for fifty years have tried to make it impossible to get your data out of their system and into somebody else's, but pressure from the users has triumphed. There is always a way to get data out of one system and into another. and once it is found the transfer can be automatic. Usually there are many, many ways, with organizational political reasons for choosing one over another.

• Applying mathematical formulas to numbers.

  The history of Information Science reveals, among other things, a huge pile of operations once thought to be doable only by thinking humans, but which have been converted to algorithms and made computable. Sorting, searching, optimizing, identifying simple trends, computing particle paths through environments, handwriting and face recognition, winning at chess, and proving historic mathematical theorems have all fallen to the level of robotic behavior over time. You don't have to be a rocket scientist to study the equations of spacecraft motion and take them right out of a textbook into a rocket simulation program. A widening net of human knowledge is being codified, literally, and is available globally to empower humans, and most of these activities are not hard. O brave new world, that has such wonders in it!

• Parsing syntax.

  Information scientists and engineers have gotten very sophisticated at defining, using, parsing and decoding syntax, the part of communication that is structural. The pinnacle of this effort is represented in the XML family of languages. In XML you can define type FRUIT as accepting value APPLE, BANANA, GRAPE, ORANGE, PEACH and PEAR. Free tools exists to validate data, for example to reject FRUIT=CARROT as invalid.

• Applying accurate meta-data to clarifying the context of data.

  If meta-data is well-defined and accurately collected, it help a computer to help humans interpret the data. This type of data about data includes:

  • date and time
  • data source
  • identities of persons involved in data collection or alteration
  • position and angle of measurements
  • environmental conditions
  • resolution and frequency ranges of images
  • space/time scale
  • intervals between events
  • labels, comments and annotations

  Clever software and accurate meta-data can be combined to create presentations that can seem almost magical in their ability to assist data interpretation.

• Creating glitzy 2D and 3D animation effects.

  In 1988 a graphics pioneer named Robert Abel bought a military-grade flight simulation graphics system and began using it to do planning of live-action commercials with elaborate optical effects. He predicted that one day computer graphics would be used to actually do the effects. Five years later Steven Spielberg's Jurassic Park (1993, movie) [ASIN: B00003CXAT] with dinosaurs from Industrial Light and Magic (ILM), proved him right. Now, another two decades later, the same Hollywood (well, Marin County really) computer effects are available on Personal Computers (PCs) for hundreds, not millions of dollars. A whole generation has grown up playing games on PCs and game boxes, and many of them have gone on to become amateur or professional computer animators, so this skill is easy to find. Every TV station in America is able to offer glitzy graphics to local advertisers. News shows make special graphics for almost every story. Even mid-term elections have their own elaborate 3D flying logos. Comedy shows parody them. You know this power has been entirely democratized when you frequently see glitzy effects with misspelled words.

{2.11.2} What's hard:

• Semantics.
  Let us make a new convention: that anything enclosed in triple quotes — for example, '''No, I have decided to change my mind; when triple quotes close, just skip directly to the period and ignore everything up to it''' — is not even to be read (much less paid attention to or obeyed).
  — Douglas Hofstadter, 1985
        On Self-Referential Sentences (essay), in
      Metamagical Themas: Questing for the Essence
      of Mind and Pattern [ISBN/ASIN: 0465045669]
        (Copyright 1985 by Basic Books, Inc. Quoted by permission.)

  Semantics is a simple word to identify the incredibly complex process of assigning meaning to communication. It is a controversial open question in the study of natural and artificial intelligences whether there are additional capabilities of the human mind not possible for a computing machine to have. The biggest clues are in areas of language, symbolic logic and self-reference.

  In the above-quoted Metamagical Themas, Hofstadter complains about advertising he saw for a book of sample business letters called Director's and Officer's Complete Letter Book, which, it is claimed, contains letters and rules for generating letters that cover virtually all situations in business. He asks:

  I wonder if it contains letters that apologize for the mechanically written tone of recent letters, or letters that apologize for the incorrectly selected letter sent last time — and so on.

  This reminds me of a scenario I've imagined, in which the following email is sent to an auto-responder which scans for keywords and then sends sales letters:

  Date: Thu, 13 Mar 2013 17:28:37
  From: Achmed Nojumi <anojumi@aulos.gov.af>
  To: info@bestretailexperienceonthewebinthewholeworld.com
  Subject: please stop sending the letters
  

  Dear Sir or Madame,
  

  Our village of Aulos has only recently acquired a satellite dish and the computer for our sending of e-mails and also receiving them. I as elected village leader have been chosen to write for our village. Since I do not speak or write English a friend in the Red Cross is translating and typing the messages.

  I write to you because now that we have freedom in our country we are trying to sell the world our fine goat-hair jackets. After we wrote to you and asked if you would like to buy them, you began sending us the letters in e-mail to sell to us your own sheepskin jackets, which are much inferior to our fine goat-hair jackets. Also we do not need them as we are making extra jackets and want to sell them to you.

  We are trying to be polite as we ask you to look at our fine quality jackets, but we find the many letters you must keep sending to be an insult to our whole village and the fine jackets we make. Please do not send them any more.

  Sincerely,

  Achmed Nojumi, village elder, Aulos

  Of course the auto-responder is almost certain to make the same mistake again and send another pitch for sheepskin jackets, further infuriating the villagers.

  It is because of these rare but important communications that do not fit the formula that the problem of semantics is so hard.

• Frags.

  We humans are really good at filling in gaps in data. Earlier I gave an example of one of Hofstadter's paradoxes: "This sentence no verb." In addition he offers these self-referential fragments and scrambles that are fairly easily resolved by humans (up to a point) but baffling to computers:

  because I didn't think of a good beginning for it.

  This sentence was in the past tense.

  This sentence has contains two verbs.

  This sentence contains one numeral 2 many.

• Data integrity problems.

  In addition to being missing, data can be accidentally wrong, deliberately wrong because "bad guys" got to it, and deliberately wrong because users decided to modify the meaning of a field or fields. This last is called the extrinsic data problem, which I mentioned earlier.

• Validating or filling in missing meta-data.

  If filling in missing data is hard, then filling in missing meta-data is extra hard. Even more challenging is fixing bad meta-data. If you knew what it was already, you wouldn't need it.

• Database locking.

  When many people are simultaneously capable of modifying data in a database, be it for a retail call center or a missile base security system, there arises the problem of data-base locking. In the most extreme case, Sgt. Joe Schmoe calls up the security office and gets operator Able just as Mrs. Schmoe calls and gets operator Baker. Both give the new phone number, but one of them has written it down wrong. Each operator uses their keyboard to enter the number into a computer program, which attempts to update the database.

  The scenario is altered only slightly whether Able or Baker attempts to save the data first. There are a number of locking schemes to try and prevent this problem, but none of them addresses the fundamental problem, which is that nobody in this scenario, neither the Schmoes nor the operators, know what the right number is.

• Mind reading.

  People don't usually walk right in to this mistake; they take a roundabout route and lose track of what the system knows and doesn't know at any point. But the result is the same: they are asking a machine to act on data from people that the people have not provided.

  An example is the following specification:

  The InputDate object will take a text string and set the target object with the indicated date, whether it is provided in American (mm/dd/yy) or European (dd/mm/yy) format.

  This is a great goal, but unfortunately it is impossible when given a date prior to the 13th day of any month on which day and month don't match, for example 3/4/05 — is it March fourth or April third? There is no way to know without additional information.

  A few years back I found a satire of a Request for Comment (RFC) on the web — alas now gone — called the Mind Reading Transaction Protocol (MRTP). It described a set of extensions to Hyper Text Markup Language (HTML) which would fill in fields in a form with data taken directly from the user's brain. I thought it was very funny.

• Precision and accuracy.

  This problem is not fundamentally, theoretically difficult, but it often works out to be in practice because there seems to be a blind spot among the makers of computer hardware and software math libraries. Simply stated the problem is that floating point arithmetic is fundamentally inaccurate, and the inaccuracy builds up over repeated calculations. For example, if you measure the length of a wall with a tape measure there is an expected error, probably of about 1/4 of an inch. If you are measuring a fifty foot wall, this is an accuracy of 0.25 inches and a precision of 0.25 inches divided by 50 feet, or one part in 2400 (12 inches per feet inches times 50 feet times 4 quarters per inch). If you similarly measure a building's interior length, width and height, and they are all fifty feet with the same accuracy, then the volume of the building is 50 times 50 times 50, or 125,000 cubic feet, or 216,000,000 cubic inches. But with the inaccuracies multiplying, the volume could actually be as little as 215,730,112 or as much as 216,270,112 — a difference of over half a million cubic feet, which brings the precision to about one part in 400, six times worse.

  The problem doesn't completely go away if your measurements are precise, either. Floating point math is not associative, and it isn't always invertible. When dealing with pure mathematics, you can count on the associative property:

  (a * b) * c = a * (b * c)

  and on the idea that every number besides zero has a multiplicative inverse:

  a/x = a * (1/x)

  But neither of these is generally true in a computer.

  For example, let's say our building has exactly 216,000,000 cubic inches, within an arbitrarily tiny margin of error. Now we want to know what a third of that is. If we divide by 3 we get exactly 72,000,000 with no decimal part. But if we invert three, we get a repeating infinite decimal that must be rounded off to fit in a computer:

  0.333333

  That looks pretty good, accurate to six decimal places. We multiply that number by 216,000,000 and we get 71,999,928 — off by 72, which is not by coincidence a millionth of the correct answer.

  I have seen problems from these effects show up in both commercial and scientific computing environments. In the commercial world, something as simple as applying a discount to a credit card order and then later refunding part of the discounted price for a partial return can result in an error in pennies creeping in, making the bankers and accountants quite nervous. The scientific world makes extensive use of what are called iterative solvers, which calculate things like the turbulence on a jet wing by applying the same mathematical operations over and over again. They are especially vulnerable to accuracy problems, and most of the subtlety involved in using these tools relates to preventing the accumulation of errors. A somewhat related category of tools — the use of many Central Processing Units (CPUs) in massively parallel computers — has its own set of accuracy problems.

  The theoretically elegant solution to these problems is to keep a record of the computations performed, and factor them as necessary to reduce associative errors, then use as much precision as necessary to do the remaining calculations; this is the approach used by symbolic math processing programs such as Mathematica [LINK_2-84], but often this approach is impractical. I believe that one day these problems will be well-addressed in the hardware of computers, and supported in the math libraries, but until then the engineers are left to figure it all out on a case-by-case basis.

• Predicting chaotic systems.

  This is the domain of problems that are truly hard; at the beginning of this chapter I identified five classes of difficulty of technology, and this is right around the boundary of class one: "stuff nobody knows how to do ," and class two: "stuff only a few people know how to do, but it's hard for them." The aforementioned predicting the cracks in rocket nozzles falls into this category, as do weather prediction and other churnings of turbulent fluids. Oddly enough, though, techies are actually seldom asked to solve these kinds of problems in my experience.

• Systematically improving usability.

  Judging by the lessons of high-tech history, one of the hardest things for companies to do is to systematically improve the usability of their high-tech products. It requires engineers to learn too much about marketing, and marketing to learn too much about engineering, and both to listen very long and closely to customers talking about their problems. It requires collaboration from departments often at odds, and it requires open-mindedness and flexibility and a lack of arrogance, which is usually present to excess among both high-tech engineers and marketers. It is much easier to launch new initiatives, re-architect the product, redefine the market space, chase other customers with more money and fewer complaints (yet), and generally believe one's own hype.

  One of my all-time favorite Dilbert [ISBN/ASIN: 0740721941] cartoons has engineer Dilbert getting a visit from a bug-eyed marketer, who tells him about the new "Q Initiative. The Q stands for 'quality.' Our first product is this keyboard."

  Looking at the keyboard, Dilbert replies, "Speaking of Q, there's no Q key on this keyboard."

  The marketer sullenly responds, "You sound just like our whiny customers."

  Being an engineer, cartoonist Scott Adams likes to lampoon the marketing department, but my experience is that almost nobody wants to hear what the "whiny customers" have to say, and whole organizations often mobilize to keep this annoying information away. But, of course, this is the path to doom.

One of the things that can mask the difficulty of some technical problems is that the human being is the most adaptive component in any system. Over time we tend to cancel out usability and efficiency problems through our own adaptive strategies. By and large this adaptation occurs unconsciously, so that things just sort of seem to get easier, or at least less annoying, over time.

In the early 1980s a friend of mine was developing CD-ROM content for Macintosh computers at a time when most Personal Computers (PCs) had neither a mouse nor a CD drive. At the time my friend was living on the wild northern coast of California north of San Francisco, about three hours from Silicon Valley. I was visiting him and wanted to see his latest work. Also present was a neighbor of his who was not involved in high-tech at all — I think he was a cement contractor. My friend demonstrated feature after feature of his new CD-ROM for about 45 minutes, clicking his way through screen after screen, when finally his neighbor piped up: "You know, I just noticed, when you move that little handle around there with your hand [the mouse], that arrow on the screen [the mouse cursor] moves the same way!" I relate this story not to show how clueless people can be in rural areas, but to remind us all that every nuance of high-tech interfaces has to be learned. Now days we teach children how to use a mouse at an early age, but until the 1980s few adults knew how to use them, and it wasn't until the 1990s that the knowledge became near-universal. Even the simple act of turning a crank had to be invented, in the 13th century, and then learned by each user. This process by which a user base becomes sophisticated over time is mostly invisible, and obscures many design issues.

This has only been a small sampling of the things I find to be easy and hard. Hopefully this list will stimulate your memory and your powers of observation, and get you working on ways to improve your intuition in this vital area.

{2.12} USING PRO TOOLS

One of the signs of a pro is that they use pro tools. Carpenters have squares, levels and chalk lines, and these days lasers as well. Auto mechanics used to have timing lights and feeler gauges; today they're more likely to have diagnostic computers. Electronics engineers have seen the volt-ohm-milliamp (VOM) meter, the oscilloscope and the logic analyzer each have their day (though they all still have uses). Programmers have debuggers, memory leak detectors and packet sniffers. The point is that in any field there are professional tools which provide vital guidance and diagnostic information which the amateurs lack.

Often when the first pro is called in to a group of struggling newbies, they are surprised and frustrated by how much time the pro seems to be "wasting" getting a particular tool working, and then they are equally surprised how quickly the problem is resolved once the tool is available.

In my foolish youth I took a try at farming before choosing the high-tech path. I was in a gang of twentysomething tree-hugging organic gardeners trying to make a go at small-scale dairy farming within the city limits of Santa Cruz, California without too much success. At point a real "Aggie" (agriculture) major from University of California at Davis (UCD) came to visit. Pooh-poohing our organic ways he pointed out our drooping peach trees (gray, drying leaves looked ready to fall off), did a soil test, said "not enough zinc," and then ran to the hardware store for a few galvanized (zinc-plated) nails. Upon his return he hammered one into each tree. The next day the leaves were green and the peaches were glowing in the sun like bright orange lanterns.

{2.13} SOLVING THE RIGHT PROBLEM

One thing that has become clear to me in my thirty five years of experience as a traveling techie is that often what are perceived as technical problems are really other kinds of problems. This situation is wonderfully addressed by Jon Bentley in his essay, Cutting the Gordian Knot, one of his columns on "Programming Pearls" in Communications of the ACM (volume 29, number 2, February 1986, pp. 92 - 96). Normally in his column he suggests ways to improve programming efficiency, but in this one he looked at what appeared to be programming problems (or other technology problems) that could be more easily solved in other ways. Bentley explains the title of his column in this way:

Gordius tied the knot. To the person who could untie it, Asia was the prize. For centuries the knot resisted all efforts, until Alexander the Great approached it in 333 B.C. Instead of repeating the vain efforts of his predecessors, he drew his sword and slashed through the knot; Asia was soon his. Since that time, "cutting the Gordian knot" has meant finding a simple solution to a complex problem.

(This column and many others are available on-line to members of the The Association for Computing Machinery (ACM) [LINK_2-86] .)

Bentley reminds me of many situations and reasons why a supposedly technical problem may be solved in other ways. Here are some ways I have found to sometimes "cut the Gordian knot" in high-tech:

• Recognize political problems.

  From a technical standpoint some problems don't have a "right answer." Most of these are what I would call political problems involving issues of fairness and power between people. For example:

  • Who should make coffee for a group of engineers and administrators sharing a break area: the administrators because they are support personnel, or everyone because they all benefit equally?

  • The president of a high tech company comes back from a trip to Peru with seven handmade Andean jackets and gives them to an engineering team of eight people. Who doesn't get a jacket?

  • A copier company has field sales people and call center representatives, both on commission with overlapping territories. One of a sales person's customers can't reach him or her on the phone and so uses the call center to reorder toner and paper. Who gets the commission? If the call center rep gets it does that mean they can now call in to the field sales accounts looking for toner and paper business?

  When you encounter a political problem, you have the following options in decreasing order of wisdom:

  1. Stay out of it.

     Is it any of your business? Must it be resolved for you to do your job? If not, let it be.

  2. Facilitate a fair and win-win solution.

     If a political problem must be solved for a technology project to proceed, work on forging a compromise acceptable to all. Warning: it is possible that somebody will still not be happy, and you may have made an enemy.

  3. Facilitate a politically acceptable solution.

     If compromise is impossible, someone in authority may have to force a decision, and you may have to call upon them to do so. In this case it is highly likely that someone will not be happy, and you are even more likely to make an enemy.

  4. Pick a side and attempt to sway the outcome.

     So you want to play kingmaker, eh? Go ahead, get half of the people mad at you in one move.

  The tendency of techies is often to seek technical solutions prematurely. In the case of the coffee making chores, it would be handy (and quite inexpensive with today's technology) to have a sensor detect when coffee is low and send email to the next person on a rotating list. But whose name goes on the list?

  In the case of the commission question, it can hold up the works if it's your job to implement a sales force automation system that will make it easier for the call center "inside sales" reps to "poach" by calling into the field sales force's accounts. You may build it and find the field sales force endlessly "procrastinating" on entering their contact data. No clever database design or Graphical User Interface (GUI) layout will solve this problem. You may have to be the one to walk into the Vice President of Sales' office and say, "You're going to have trouble getting the users to accept this system until you clarify your commission rules."

  In the case of the Andean jackets, a techie is likely to approach the problem as if it were a problem from a book of math puzzles. In this context a "reverse auction" seems sensible. Start the bidding at some absurdly high amount like $10,000 and then each bidder bids a lower amount which they would accept instead of a jacket. The low bid wins, and all other team members split this cost. Fair though this seems, you are still left with the fact that whenever the team goes out to pizza and beer (or whatever) in their snazzy Andean jackets, one person may feel left out. It could be the beginning of a schism, especially if others join the team later and also don't get jackets. Perhaps a more empowering solution is to stuff the jackets in a closet and give out one every other month or so for the engineer who most goes beyond the call of duty. The point is that not all problems can or should be solved with clever technology.

• Recognize and circumvent obfuscation.

  Sometimes things are hard to figure not because they are complicated or chaotic but because someone is feeding you disinformation. Broadly, these situations will involve deception by either an individual or an organization.

  Most of the time when I've encountered obfuscation by an individual it has been because they were hiding a bad job they'd done — or most frequently a job they hadn't done at all. Once, in job C, I was working as a consultant "computerizing" a small company that delivered medical oxygen daily to both state aided (Medicaid) and private patients. Previously their secretary had typed all bills on a typewriter, which was both prone to error and hard to redo as needed. I put together a billing system for them that took the state-supplied Medicaid forms, on perforated fan-fold computer printout paper, and with an impact printer filled in each of the fields on the forms. The owner was very concerned that I fill in the forms correctly, or else he wouldn't get paid, but he was unable to provide me with examples of bills that they'd correctly filled out and gotten paid for. Every time I asked about what forms to print the bills for private patients on I was told we'd get to that later. It was obvious that the business was running low on cash because vendors weren't being paid. I was there when the bottled water people repossessed the water cooler. I finally left to take another more permanent job, passing my role onto another consultant. But I always felt a little badly about that client, like I hadn't helped them enough. Finally I came back to see how they were doing. The new consultant told me that it turned out the company had been buying oxygen, delivering it to Medicaid and private patients and sending out bills for over a year and had never been paid for any of the oxygen. Some of the bills to the state hadn't been paid because the forms were filled out wrong, but most hadn't paid because they hadn't been done at all and the secretary had lied. None of the private bills had been paid because none of them had been done; the secretary had lied about that too. The good news was that the system I'd put in place had made it very easy for them to crank out the missing bills as well as re-bill when necessary. But I felt kind of dumb having been sitting right there with the real problem under my nose and not detecting it.

  In the case of obfuscation by institutions, it is usually to protect proprietary information and trade secrets in some way, shape or form. I've mentioned before companies that do a deliberately bad job of documenting their technology so they can sell more consulting and training. This kind of encryption through incompetence goes on too much. In addition, some companies are completely secretive about the "innards" of their technology. This type of situation seems to require reverse engineering, the deriving of a detailed design specification through the study of a system. It's sort of like life during wartime, analyzing captured enemy technology. But be warned: this type of effort is always harder — more time consuming and expensive — than you expect; you are never completely sure you've done it right; you may be on shaky legal ground using what you figure out. I recommend that you first attempt to solve the problem in other ways:

  • Use another technology, one which is more open.

  • Invent your own technology — it may be no harder than reverse engineering.

  • If there's a way to pay a fee and get a license, join a consortium or in some other way gain legal access to the technology, consider doing it.

• Look for business solutions to difficult technical problems.

  Sometimes as a techie you will focus on the technical problem at hand, and not see that in business every technical problem will be in the context of a business problem. Sometimes the business problem can be solved directly in another way.

  Very early in my career, in job D, I did technical phone support for a company making peripheral controllers for minicomputers. We sold low and high-end controllers for low and high-end minicomputers. We'd always believed and told our customers that the low end controller would work in a high-end minicomputer, but we'd never had a way to test it. (We didn't own one of the high-end minicomputers, and did only component test, not system test, on the high-end controllers.) Finally the money-strapped Georgia Institute of Technology, good old "Georgia Tech," bought one of the low-end controllers for their donated high-end minicomputer. They called me because it didn't work. We couldn't figure out the problem. I was taking a driving vacation soon afterwards and passing through Georgia, so I volunteered to make my first onsite visit while on vacation. I stopped in Atlanta and spent a day trying to determine the problem, with no success. Upon my return I told the president of the company I didn't know how to proceed. He took two steps:

  1. He gave Georgia Tech the high-end controller for the low-end price, thereby creating a happy customer and absorbing a small financial loss.

  2. He had the technical specifications changed so that only the high-end controller was supported on the high-end minicomputer, so the problem wouldn't happen again.

  I noted with admiration that these two steps solved the business problem without having to solve the technical problem of why the low-end controller wasn't working on the high-end minicomputer. And in fact the problem would never need to be solved, and so remains a mystery to this day. But the business continued to earn a profit, which was ultimately the real business problem to be solved.

• Avoid over-solving.

  I remember working with an administrator in the late 1980s who had a PC running DOS and asked me if she could use it to keep track of sales force schedules with a calendar program. I considered the following factors: (1) She used the PC to do form letter mail/merge printing operations, and it couldn't be interrupted while doing this. (2) Everyone called her and only her to report or find out schedule information. (3) Her current way of doing it was to use a blank calendar desk pad and write on it in pencil. I reasoned that if someone called while she was printing she couldn't give them schedule information if it was on the computer. I even if she wasn't printing she'd possibly have to wait for the computer to boot and the program to start and then find the right date. I advised that she could get a calendar program but it would offer no advantages over the current system and many disadvantages. (Of course things have changed. Today a bunch of employees on an intranet can used a web-based scheduling program with great benefit.)

• Apply pressure to get additional help.

  On a number of occasions in my career I've been asked to do something that seemed nearly impossible, given the level of knowledge I had at the time and the level of technical support I was being given by those more knowledgeable than me. I found that at this point the problem shifted from the technical challenge of doing what I didn't know how to do, to the psychological challenge of getting the experts to help me. I found that the three main tools I could use were sympathy, greed and fear.

  In job H, when I had the task of getting FORTRAN benchmarks running ("ported") on a new supercomputer and was encountering compiler bugs, I was sent to HQ to resolve some problems and, once there, discovered that the Vice President of Software Engineering had ordered his team not to help me because they were behind schedule on other work. This is when I first discovered the value of sympathy. I had been sitting in a different part of the building and I arranged to be moved to the same area as the software group. They were working a late shift, coming in around ten AM but staying until at least midnight. I matched schedules with them. Fourteen hours a day, day after day, they were slogging away on getting their software done and I was slogging away at my FORTRAN benchmarks, pretty much getting nowhere but hanging in there. I felt like I was throwing myself against a wall over and over again, getting more and more bloodied. Of course, only the programmers stayed so late every night; the managers were gone by 8 PM. And finally some guys in the compiler group took pity upon me, and worked with me until they'd fixed all the compiler bugs and I could get my benchmarks to run. The character I emulated in this exercise is Henery Hawk [LINK_2-87] the chicken hawk, in the Warner Brothers cartoons such as "Walky Talky Hawky" (1946) [LINK_2-88]

  The problem with sympathy is that works best up close. But greed and fear can be used at a distance.

  In another job K , the software developers on a new "object oriented" mapping project had come to a screeching halt because a tool they used was failing. It was a commercial object database, and a programmer on the project had called the vendor to report a problem, and was told it would be fixed in the next release, a few months away. Now what? I was a sales engineer at the time, visiting HQ, and it wasn't really my problem, but I decided to get involved. I pointed out to the lead of the development group that the object database vendor had been eager to partner with us. Their sales force was all fired up to use our mapping application to sell their database. I suggested she call up their VP of sales and ask for some pressure on their engineers to fix our problem. She did and it worked. It was the vendor's greed that made them willing to allocate resources to our problems, beyond what a typical customer would get.

All of these examples show when it pays to step back and ask a few fundamental questions, and make sure you are solving the right problem.

Six of Hosts The developer's fingers pound the keyboard, grinding out lines and lines of new code... or not. Perhaps he has reinvented the wheel. Isn't there already a function in the standard library to do that? Naive, unexamined effort. Reversed: time to stop and reconsider. n. Silicon Valley Tarot © 1998, Thomas Scoville.

{2.14} TIME MANAGEMENT

"The will is infinite
and the execution confined,
the desire is boundless
and the act a slave to limit."
— Cesaro, 1905

Even if you work in a "cube farm" in an office full of people, you still are not closely and directly supervised. Sure, coworkers will notice if you spend all day playing Minesweeper [LINK_2-89], or bidding on action figures on eBay [LINK_2-90], or using using Google image search to check out Oscar gowns [LINK_2-91]. (Or reading magazines for that matter — you don't need a computer to goof off.) But even so you still must manage your own time. Nobody's watching to make sure you do productive work, or "work smart." You can do a poor job and get very little done while managing to look quite busy and productive. Ultimately the responsibility for managing your time and getting things done falls to you. If you work in a small company or a field office, or telecommute or work from a home office, the need for you to have good time management skills increases.

Here are my tips on developing these skills.

{2.14.1} Motivation

He conquers who will.
— motto of the New Hope School, circa 1905

In a tale I have told previously, I resigned from job N because I was burned out and had lost my zest for the work (in addition to not adapting well to the corporate culture of the Fortune 500 company that bought the start-up I worked for). Shortly before that happened I asked my boss for advice on how to learn the company's technology faster. I expected him to refer me to a book or a class. Instead he told me this story:

A man who goes to a teacher asking, "Please teach me all you know." The teacher takes him to a river and holds him under. As the man is about to drown, the teacher lets him up and says, "When you want knowledge as badly as you wanted air, you will be ready to learn."

At the time this advice helped me in my decision to resign. Later the same advice helped me in my pursuit of Java technology. I found I had to build my faith in the technology and how useful the knowledge would be in the future in order to build high enthusiasm for learning about it, which in turn made the learning easier.

I shared all of the above with another friend, who has a very mellow, "on day at a time" philosophy. He reminded me:

In every job that must be done there is an element of fun. Find the fun, and "snap!" — the job's a game.

He likes to find the fun in any task and use that as leverage to motivate himself. I realized that there have been many times I've done the same thing.

Whether with positive motivators: teamwork, pride, striving for goals, curiosity, helping others; or negative motivators: fear of failure, guilt, melancholy, desperation, anger, or compulsion; you have to find what works for you to get and stay motivated. You must truly want to produce results.

If you just can't do it, if you find there's no way you can get yourself to want to do the work, then you have to quit your job. Find another one first, but get out of a situation that will destroy your work ethic and your reputation.

{2.14.2} Distractions

If you can dream — and not make dreams your master
If you can think — and not make thoughts your aim
If you can meet with Triumph and Disaster
And treat those two impostors just the same

— Rudyard Kipling, If—
      from Complete Verse (1907) [ISBN/ASIN: 038526089X]

Electronics hobby writer Don Lancaster (www.tinaja.com [LINK_2-92]) author of The TV Typewriter Cookbook, The CMOS Cookbook, etc. wrote an amazingly useful guide for the small entrepreneur, The Incredible Secret Money Machine (1978) [ISBN/ASIN: 0672215624] . In it he offers some very useful advice on time management: cut your television power cord in two places (he has a diagram showing where), then throw away all three pieces and the television.

I confess I have not been willing to take this drastic a step. But there is no doubt that TV watching is the biggest time sink in many people's lives. If you work at home and have a television, you have to partition your time. What I have found works for me is to tape the shows I like (currently about 3 hours/week), and watch them mostly on the weekends with my wife and daughter. During my work week I don't watch TV, though I sometimes have it on.

Maybe I'm unusual, but I find that I have trouble concentrating in the absence of a little distraction. Sometimes when I'm working in my home office I like to have on recorded music (no audio commercials), alone or combined with the Weather Channel on the television (sound down), or else a DVD of music videos and/or concert footage of a favorite band. Right now I have U2's Elevation Tour 2001 - Live from Boston (2001, concert movie) [ASIN: B00005RD3W] on, as I write these words. The key I have found is that it must be non-engaging, something you can enjoy as background that won't clamor for your attention. Commercials are attention-getting, especially in the audio, and that is a concentration-killer.

It is important to have a work environment in which you can "get into a groove" and do work in long uninterrupted blocks of several hours. You should permit nothing to intrude when you're in this groove, if at all possible. (See section 2.14.6 "Interruptions" below for strategies when you can't "shut out the world.")

If you work in an office, music on headphones (again without commercials) can help you get into a groove and filter out distractions. I like to mix my own CDs; here is a "work mix" I did recently:

1. Eyeballs In the Sky / Firesign Theatre / Give Me Immortality Or Give Me Death (1998, audio comedy) [ASIN: B00000AG7T]
2. Part One / Mike Oldfield / Tubular Bells (1973) [ASIN: B000000WG4]
3. Two To Tango / Vanessa Daou / Slow To Burn (1996) [ASIN: B000050YO8]
4. Weightless / Mike Oldfield / Tubular Bells II (1992) [ASIN: B000002MFQ]
5. Behind the Wheel (Shep Pettibone Remix) / Depeche Mode / Behind the Wheel (1992) [ASIN: B000002M2O]
6. The Bell / Mike Oldfield / Tubular Bells II
7. Leaving Port / James Horner et. al. / Music From the Motion Picture Titanic (1997) [ASIN: B0000029YC]
8. Clear Light / Mike Oldfield / Tubular Bells II
9. Rose / James Horner et. al. / Music From the Motion Picture Titanic
10. Sentinel / Mike Oldfield / Tubular Bells II
11. I.G.Y. / Donald Fagen / The Nightfly (1982) [ASIN: B000002KXV]
12. Sentinel-Restructure (Global Lust Mix) / Mike Oldfield / Sentinel: Restructure / Bell (1993) [ASIN: B00000DE83]
13. In Your Eyes / Peter Gabriel / So (1986) [ASIN: B000065VA1]
14. Maya Gold / Mike Oldfield / Tubular Bells II
15. This Blue Hour / Vanessa Daou / Slow To Burn
16. The Bell (Edit) / Mike Oldfield / Sentinel: Restructure / Bell
17. Route 66 (Casualty Mix) / Depeche Mode / Behind the Wheel
18. Sentinel-Restructure (Trance Mix) / Mike Oldfield / Sentinel: Restructure / Bell

You may notice that — leaving the comedy bit at the beginning aside — these 17 songs come from just eight albums. About half the songs are versions or remixes of one song: Tubular Bells by Mike Oldfield, a long synthesizer piece from the 1970s that presaged more recent "trance" style "techno" music. Techno-pop band Depeche Mode's version of Route 66 and Behind the Wheel share some melodies. Several songs from the Titanic soundtrack share melodies as well. What I was after here was a feeling of losing track of the passage of time. I find this helps me when I'm in a "groove" to just keep working.

Others have told me that recorded nature sounds, like sea surf or a forest creek, are very good sounds to listen to on headphones while working, to mask distracting noises.

If you work while traveling, it's handy to have a laptop or other device that plays audio, and to bring small speakers, so you can listen to music while working in your hotel room. Otherwise you might be tempted to turn on the clock radio. (At some point on your trip I do recommend you listen to local radio, especially talk radio, to get general information about regional concerns, but not while you're working!)

Of course there are people who get into their best "grooves" with silence. More power to them. Just know what works for you.

I also recommend that you delete the solitaire game Free Cell off of any PCs you have. I'm not the only person who has reported the game is highly addictive. I'm not sure why — perhaps it is the challenging realization that after the initial deal there is no luck involved, only intelligence. It takes brains to win, but you don't win anything of value, so I guess it can be said you have to be smart enough to win but dumb enough to want to play in the first place.

There may be other games or pastimes on a computer that you find similarly addictive. If you can't bear to part with them, I recommend you move them to another computer, one that isn't in your work area. If you work in an office play at home. (Or, if they let you, play after hours in the boardroom using the projector!) If you work at home have a game machine that's separate from your work machine, in another room. At least you'll notice when you're goofing off!

Five of Cubicles Five cubicles oversee a phrenological analysis of the Silicon Valley cubicle dweller's inner life. Distraction, lack of concentration, over-stimulation. Reversed: mid-life crisis, career burnout. Silicon Valley Tarot © 1998, Thomas Scoville.

{2.14.3} The Power of Goals

Its hard to remember that your goal is to drain the swamp when you're up to your ass in alligators.
— old American saying

Another fabulous book by Don Lancaster was called Enhancing Your Apple II, Vol. 1 (1984) [ISBN/ASIN: 0672218224], long both out of print and obsolete. But it had some advice on how to disassemble 6502 machine language code that contained some powerful insights into the functioning of goals in the technical process.

He starts out by listing a bunch of tools you will need, including an older (lower-security) version of the boot ROM to make code cracking easier, any documentation you have on the software from the manufacturer or other parties, reference books, reference cards, a whole lot of stiff, high-bond fan-fold tractor-feed printer paper, and a whole lot of highlighter felt tip pens. He also lists a quiet workspace and the right attitude as essential tools.

User Friendly cartoon about marking up code printouts [LINK_2-105]

Next he talks about the importance of having a limited goal: not totally understanding the program, nothing ambitious, not even something trivial or something any idiot could do. Something smaller than that.

He suggesting a goal of finding the scrolling hooks (entry points for scrolling subroutines) in a program from Apple called "High-Res Character Generator" (HRCG), for doing higher-resolution multi-font characters within the constraints of the chunky Apple II graphics. He reflects that it might be possible to improve the scrolling, then retreats — no, let's just find the hooks.

Next follows detailed step-by-step directions on how to get the program, and only the program you want to disassemble into the Apple's memory, stopped, with control transferred to a monitor program which can disassemble sections of memory for you and print them out. After some preliminary separations of the memory into code and data, you go through the code with the color felt tip highlighters and mark with all "subroutine return" instructions green, all "jump to subroutine" instructions orange, short subroutine descriptions in fine-point brown, absolute jumps in pink, branches in blue, entry points in red, and implied addressing and stack operations in yellow. By studying the structure of memory, and how the code interacts with data sections in memory as well as disk files, you come to understand what it is doing. Only after mapping out its structure this way do you begin hand-disassasembling code to determine its exact function.

About now is when it seem like you're "up to your ass in alligators," and that's when it is important to remember your goal: to drain the swamp (or in this case, to find the scrolling hooks in HRCG). Abandoning the chase for "total knowledge" of the program, he retreats to the original goal which is easily accomplished. But then he does insist you write down everything you learned along the way, not just the answer to your original question. Such excursions (I like to call them "treasure hunts") increase your store of knowledge vastly, more than either more casual quests on the one hand or more thorough and exhaustive learning exercises on the other hand.

Notice the attitude towards the goal as the project moves through its phases. Early on he says you need to not obsess on the goal. Be prepared to take side trips. The whole point is to gradually separate what you know from what you don't know.

Later as the structure of the program begins to become clear, and the temptation is to keep on exploring until you get lost in the caves, he reminds us to return to the goal. With most of the structure of the program mapped, you will probably be able to find those scroll hooks.

This diverge/converge cycle, often built into a work session of a few hours, is a very efficient method of self-guided technical discovery.

{2.14.4} Organization

It's later than it's ever been.
— Flip Wilson

• Triage.

  You remember triage don't you? In wartime or disasters medical personnel are trained to separate patients into three categories:

  1. Will probably survive in any case.

  2. Will survive or die based on medical care.

  3. Will probably die in any case.

  What you need to do is to sort your tasks into four categories (would that be "quadrage" perhaps?) according to this matrix:

  	important	not important
  urgent	A	B
  not urgent	C	D

  It is obvious that on the question of how to prioritize these categories, box A comes first and box D comes last. The tricky part is managing B and C. The natural tendency would be to favor items in box B because of their urgency. But the mastery of time management comes in making time for the box C items. This is where various kinds of planning activities and strategic thinking tend to end up. No one is going to call you up and complain that you didn't think about the "big picture" today. You have to make it a priority on your own.

  In the next section I'll talk about making "to do" lists. But as far as the box D stuff goes, my approach is not to even write it down. The simplest test for box D is: nothing bad will happen if you don't do it. If the task has a physical thing associated with it: a letter, a printed-out email, a survey, a catalog, a magazine, etc., I just toss these in a folder. If not I create a 3x5 card or something like it to record the task, and toss that in the folder. Right now the folder would say "Q4 2013 LOW-PRIORITY" since it is the first fiscal quarter of 2013. Every quarter I start a new folder, and about once a year I throw stuff away. Honestly, almost none of this stuff is going to get done. The only time I'll go into one of these folders is if a task gets elevated in priority. For example, if I have a bad experience with a car rental company I may fish out their survey to fill out and send in.

  If other people have assigned you tasks that exceed your ability to accomplish with the time and resources you have, that's the time to go to your boss and ask for priority setting. If the people you have to end up saying "no" want to lobby for their cause, send them to your boss and get back to work on the other stuff.

• Manage tasks with "to do" lists.

  Over many years of tweaking and conferring with many associates I have found the following system for managing tasks works well:

  For my personal tasks I keep a master list in a word processor file (actually as HTML for maximum portability) of tasks I want to remember. I add to the printout and cross things off in pencil, and about every eight weeks I reedit the file and print it out again. I sort the tasks into reading, things to do at my desk, things to on a computer, things to do elsewhere at home, calls to make, shopping, and errands. For calls I put the person's number(s) on the list.

  Usually every Friday I plan my week, weekend first. I work from my master list and decide which items on it get put onto my weekly plan, which I do on a graph paper pad on a clipboard. I keep in mind my daily schedule and at what time of day certain tasks must be done. Again I for calls write the person's phone numbers on the plan. I like to put a box next to each task, use single slashes (like a "spare" in bowling) to indicate progress, and then when the task is complete mark the box with an "X" (like a "strike") and cross out the words. What the heck. It's a little reward.

  It's okay if everything on master list doesn't get done; that's expected. (Eventually some of those tasks become "moot" and I cross them off with a wiggly line as "no longer need doing.") The items in my weekly plan are what I concentrate on completing.

  When I've had paycheck jobs I always endeavored to use my company's bug tracking system or other task management tools (in order to facilitate communication and collaboration), supplemented as needed by yellow sticky notes that get transferred to a text document.

  During self-employment, I basically "clone" my personal system for business use, sometimes with the addition of hand-drawn PERT charts.

• Complete a chunk of a known size and time it.
  You can't manage what you can't measure.
  — American business proverb
  

  When you are tackling a large task, refine your time estimates by breaking the task into equal-sized chunks (as much as you can) and timing them. For example, if you have to mow and edge trim a lawn, mow one row and then edge trim a fixed length of edge, timing each activity. Say the lawn is 30 by 30 feet and the mower cuts a swath 2 feet wide. You mow one row 2 by 30 feet in 3 minutes, and edge trim 10 feet in 15 seconds. Do the math and see how long the whole task will take. 15 swaths at 3 minutes each is 45 minutes, 120 feet of edge at 40 feet a minute is 3 minutes, making a total of 48 minutes. But wait! You've already done 3 minutes 15 seconds worth of work! Subtract that out, to get 44:45.

• Give yourself small rewards for chunks.
  Somehow people get the idea I think we should be given gumdrops whenever we do anything of value.
  — B. F. Skinner, 1972
  interview in Saturday Review

  Okay, so now you're going to mow that lawn. Make a glass of ice cold lemonade. Mow one row over and one row back, then take a sip of lemonade. Repeat until the mowing is done, then edge the lawn and finish off the glass.

  This may sound silly, but the mind thrives on small rewards. There is also a subjective effect of time compression, because being so reward-focused keeps the effort from seeming like endless drudgery.

  Of course — as I'm fond of pointing out — if you are managing someone mowing a lawn or digging a ditch, you can look and see what per cent done they are. But if you are managing someone designing a spacecraft or programming a cell phone game it is very difficult to tell what per cent done they are. This problem persists when the person you are managing is yourself. I will have advice on dealing with this in the upcoming section 2.15 "RISK MANAGEMENT." But to whatever degree a task does have same-sized chunks, utilize this small rewards technique.

• Start early.
  It's the job that's never started as takes longest to finish.
  — J. R. R. Tolkien, 1954
        The Fellowship of the Ring [ISBN/ASIN: 0618002227], Chapter 7

  How many times have you started to do something and found that it was a whole different deal than you thought? I have. If you don't have time to do something important, or you don't know if you have time, just start it. Get everything together you'll need, break it into chunks, and do a chunk (timing it of course). If part of it must be done at a certain time (like a phone call during business hours in another time zone), schedule it. Then put it away for later, knowing better what's involved. This is a fantastic sanity check, catching obvious miscommunications and errors, and refining your understanding of the task dramatically.

  This also is a great point to cancel or re-prioritize a task, after you understand the effort required.

• Stay out of "free loops" (FlooPs).

  In chapter one of this book, in section 1.6.1 "Theory of Delays," I talk about the simplified computer languages BlooP and FlooP described by Douglas Hofstadter in the book Godel, Escher, Bach: An Eternal Golden Braid (1979) [ISBN/ASIN: 0465026567]. The distinction is applicable not only to avoiding travel delays but to avoiding task delays. I won't repeat myself here so if you skipped that section or your recall is hazy, go back and check it out.

  Back? Okay. Consider the following choice: you have an old version of a computer program you wrote that requires you perform a manual step that takes 30 seconds for each record it processes. You have 120 records to process. You have a new version of the program that automates the manual step, but it has a bug. You think you can fix the bug in about half an hour. What do you do?

  If you said, "fix the bug," then consider this scenario. It is an hour later and you are still debugging, but you are "really close." What do you do? Keep debugging? Okay, now another hour has passed and you feel strongly that you are "really, really close" to fixing the bug. Now what? This is how a 60 minute task can turn into a 6 hour task. (It is also sometimes how my supper gets cold.)

  The solution is to decide before you start debugging how much time you will devote to it. It doesn't even matter too much what the time limit is, as long as you stick to it. For psychological reasons I would tend to favor a 60 minute time limit, the same as the time to do the semi-automated task, so that the time to completion will range from one to two hours. Note that this decision up front changes the free loop (FlooP) into a bounded loop (BlooP) and permits a maximum time to completion to be established.

• Be pessimistic when it matters — when guessing how many iterations something will take.
  This time, for sure!     excl.     Ritual affirmation frequently uttered during protracted debugging sessions involving numerous small obstacles (e.g., attempts to bring up a UUCP connection). For the proper effect, this must be uttered in a fruity imitation of Bullwinkle J. Moose. Also heard: "Hey, Rocky! Watch me pull a rabbit out of my hat!" The canonical [LINK_2-106] response is, of course, "But that trick never works!" See hacker humor [LINK_2-107].
  — "This time for sure!" [LINK_2-108] in The Jargon File [LINK_2-109]

  This is related to the FlooP/BlooP stuff above, but it applies to a specific kind of situation. I think two examples will explain it best:

  1. You are about to print a document from a program such as a web browser that does a bad job of page fitting and pagination on printouts. You think it will probably work okay this time. Do you use Print Preview to see how it's going to look, or go ahead and just print, which takes less time if you get it right the first time, but more time if you don't?

  2. You are using a computer program invoked from a shell command line which takes a number of tricky options as command flags. Do you type the command directly to the shell or do you create a shell script to do it? Again one choice takes less time if you get it right on the first try and more time if you must use the command repeatedly, trial and error, whereas the other choice has the opposite time trade-off.

  My rule of thumb on this issue, after years of experiences (some of them mule-headed), is to give myself one chance. If I get it on the first try, fine, otherwise start using the Print Preview or make a shell script or whatever the strategy is that makes repetitions less risky. It reduces your plaintive cries of "This time for sure!"

• Make sure tasks converge.
  The Hydra was difficult to kill, because when one head was cut off, two more heads grew back out of the stump of the old one.

  Hercules was able to slay the monster with the aid of his charioteer Iolaus, who burned the stumps with a torch as Hercules cut off the heads of the monster. It was said that one of the heads of the monster was immortal. So after cutting off that head, Hercules buried it under a large rock.

  — Hydra page [LINK_2-110] from The Dome of the Sky,
      Saint Cloud State University, St. Cloud, MN.

  Have you ever seen the "progress bar" on a program move backwards, right to left, as if time remaining was increasing? I have. I've seen it with tasks and projects as well — if there'd been a progress bar, it would have moved backwards at least once in the process.

  This even happened to me while working on this book. I measure my progress in the writing of this book by counting words, which is usually an accurate metric. But yesterday I reorganized by eliminating a section and combining two others. This meant there was less work remaining, so I really was making forward progress, but according to my progress-measuring tools I'd written minus fourteen words. And this wasn't the worst case. If I'd actually accidentally deleted a big block of text and had to rewrite it (for no other reason than my own stupidity), that would be a negative word count that was really bad news. It seems like every nontrivial task goes through a phase where it's making backwards progress, and bringing the task to a successful conclusion requires "slaying the hydra" and getting all the tasks to converge on a finished result.

  If you've ever programmed in a computer language with a stack, (either built-in or in standard libraries) such as Java, FORTH, some assembly languages, and calculators that use Reverse Polish Notation (RPN), then you are familiar with the discipline that requires that, whenever you "push" something on the stack, you have to know how and when it is going to be "popped" from the stack, and have the "push" and "pop" operations balance out. Too many "pop" operations and you end up executing garbage ("crash"); too many "push" operations and you get stuck in an infinite loop ("hang"). Another way to think about these operations is opening and closing parentheses. You always have to close as many as you open or else you'll never get to the end of a statement. In all of these cases the quality being sought is convergence. If you are familiar with this term from the mathematics of infinite series, you know exactly what I mean. Or, if you've read The Cat in the Hat Comes Back (1958) [ISBN/ASIN: 0394800028] by Dr. Seuss, and remember the little cats that tried to help him clean the pink ring out of the tub but instead ended up getting pink on everything in the house, you have an idea of a task that didn't converge.

  The textbook example of this problem is in coming up with a strategy for searching a maze. When you begin a maze every choice seems to lead to more choices, and it can seem like you'll never get them all sorted out. But if the maze isn't infinite, near the end of the task only a few short steps will remain. The popular "right hand rule" which directs you to keep your right hand on a wall at all time, reduces the maze search task to a linear sequence. Interestingly, it does not guarantee success (if the exit to the maze is in an "island" of walls, you will miss it) but it does guarantee that you will either succeed or fail in a finite number of steps.

  The most common modern analog to maze searching is web searching. Quite a few years back my daughter reached that point in the fourth grade when — in the state of California — all school children are required to write reports about and build a models of California missions. I helped her collect some information off the World Wide Web to use. The search engine we used, google.com, returned several pages of links relevant to her chosen mission, Mission Santa Cruz. Each page had on average five or six links to other pages for more information. Trying to follow them all, like trying to explore all maze choices, was a divergent task. So we looked for high-content high-credibility sites, and we found three: the mission site run by the Catholic Church, which owns the mission property and had the best concise history of the buildings, the web site of a California State Park with a historic adobe and museum nearby, which had the best information on everyday life in mission times, and the web site of the tribe of native Americans that once lived at the mission, which had the best information about the native culture, clothes, dwellings and tools. We printed out pages from these three sites and declared victory in the research phase of the project.

  I could go on and on forever about the importance of convergence, but I'll get to the bottom line here: whether a task converges depends less on the task itself than on your strategy for solving it. (This has been found to be true for infinite series as well.) So think carefully about your strategies, and fine-tune them until they converge quickly enough for the task schedules you face.

• Filing theory according to "the Flash."

  I've found that usually when people talk about getting organized they mean getting their filing in order. I actually think this is the least important component of organization, as the above sections show, but I do need to cover the topic briefly.

  The comic book character of "the Flash" had remarkable superpowers: not only could he perform tasks at arbitrarily fast super-speeds, but he never seemed to get bored while doing them, immense though they might be. I think to myself sometimes that if I were "the Flash," filing would be trivially easy. Just put everything you might ever want to find again in a barrel. When you need to find anything, dump out the barrel and put things back in one at a time until you find what you're looking for.

  This system isn't as bad as it sounds in terms of effectiveness; any search is guaranteed to take a finite time and to always succeed (unless you don't have the thing searched for). It also isn't as easy as it sounds in terms of filing effort. It takes great discipline to put everything important in the barrel, and not end up with a few things in your wallet or purse or in a hidden flap of your laptop bag, in the glove compartment of your car, on the bedside table or in a pocket of your coat.

  Of course no sane non-superhero would attempt to use this system literally, but the way to make it practical is to adopt strategies to reduce search times. If you file alphabetically you may still have to look in "P" for "POOLTABLE," look in "T" for "TABLE, POOL," and look in "B" for "BILLIARDS," but that's still only 3 out 26 possible letters. Anything that reduces search time helps.

  Just remember that goal is not to have "a place for everything and everything in its place." Maybe in Edwardian England people could work that way, but in high-tech the tool inventory changes too fast, not to mention the task inventory. The goal is find what you're looking for quickly enough to make it worth the effort.

  A friend of mine once suggested, only half in jest, that you could take a string of lights sort of like those little Christmas lights except with an alligator clip on each one and with a way to light each lamp independently under computer control, and clip one of the lights to each of your possessions: socks, remotes, mail, highlighter pens, keys, etc. After a tedious session of typing in the names of each items, you could forever after use a computer program to search for an item by name and its light would blink! Of course, this is crazy. You don't want wires all over your home or office, but there is a germ of a great idea there. I mulled over it for a long time, and came up with a principle that works for me: I call it "Computerize Only the Index."

  The basic idea is to store data in its old, analog form but to index it on a computer. Some examples will make this clear.

  Example #1: Videotapes

  I used to record shows off the television and usually save them. Each tape holds 6 hours, 12 half-hour shows or 120 music videos, so there isn't enough room on the label to describe the contents. So I did't even try. I gave each tape a unique name, often a phrase spoken early in the dialog, and the date I first recorded on it. Then I cataloged the video by typing information into a word processor about what's where on the video. Here is some sample data:

  Videotape: WHAT A DAY 15-Jan-2003 ============================================================== 0:00:00 The Daily Show: Wed. Jan. 15, 2003 (Dave Chappelle) 0:32:18 The Larry Sanders Show: Larry in Montana 1:01:10 The Daily Show: Thu. Jan. 16, 2003 (Joe Leiberman) _:__:__ Saturday Night Live: Ray Liotta & The Donnas 2:54:27 The Daily Show: Mon. Jan. 20, 2003 (Merv Griffin) _:__:__ The Daily Show: Tue. Jan. 21, 2003 (no guest) 3:54:57 The Daily Show: Wed. Jan. 22, 2003 (John C. Reilly) 4:25:00 The Daily Show: Thu. Jan. 23, 2003 (Jimmy Kimmel) 4:55:54 Mad TV 6:09:16 end of signal ============================================================== Last update 18-Mar-2003

  I'd write the title and date, in this case "WHAT A DAY 15-Jan-2003," on the tape label, and store the tapes in boxes in chronological order. I no longer record these but I still on occasion play them back. (Someday I'd ;like to digitize many of them and put them on a humongous hard drive, but that takes time, so I put it off. Besides, if you can find one, VCRs are really cheap these days.) When looking for material, I search in the folder (directory) where I keep the files and determine which tape to retrieve. (I don't worry too much about missing information, like the "Saturday Night Live" listing above. I can always interpolate the times.) This whole process takes the search time down to a few dozen seconds for finding most of my video material.

  Example #2: The HTML Index

  When I'm managing a collection of digital data, some on my hard drive and some on the web, I find it useful to manually create and update a master document index. For example once I was working on an article that referenced a Java program I wrote, and I had a folder for the article for the text, a sub-folder for the graphics, a totally different folder for the program source, and some web sites with pertinent documentation. I also posted the article while in progress on my web site for my collaborators and reviewers to use. So I created a master index in the article text folder, that looked something like this:

  Project Index for "Experiments in Visualizing Social Networks" text: file:///Users/abs/Writing/Nonfiction/Articles/ExperimentsWithNetworkViz/Experiments.html graphics: file:///Users/abs/Writing/Nonfiction/Articles/ExperimentsWithNetwork/Graphics source code: file:///Users/abs/swdev/Java/Apps/NetworkBlobs/ online: http://aero.mindtel.com/~mindtel/Alan1/2004_NetworkViz/Experiments.html docs: http://docs.oracle.com/javase/7/docs/api/ conference: http://www.casos.cs.cmu.edu/ Last update 11-Jun-2004

  I am sometimes inconsistent with my folder and file naming, and this kind of guide makes it easier to set a project aside for a while and come back and find everything.

  Example #3: The Project Notebook

  The video indexing above turned out to be so successful that I've envisioned a more ambitious approach, which I've not yet tried. The idea is to manage all paper documents for a project by giving them sequential numbers as they are logged, putting them in notebooks sequentially, and do all indexing in the computer. Don't try to organize the numbers chronologically or any other way — the number just represents logging order. Every document is findable by number. All titles, content summaries, keywords are entered into a computer, with the number to refer you back to the document in its notebook.

  The idea is that this is a stepping stone to an all-digital system, but you may never get there. You'll probably always have things like marketing literature and phone directories that need to be attached to a project file but aren't worth scanning.

  Like I said, I haven't done this experiment yet but my bet is that it will be surprisingly efficient.

  If you review the above techniques I've outlined for improving on "the Flash" method of filing, they all have to do with reducing search time. None of them reduce the amount of self-discipline you must have to make the system work. Any video I haven't cataloged is unavailable for my computer search, just like "the Flash" can't find anything not in his barrel. But I did realize upon reflection that having a computer do your searching for you is sort of like being "the Flash."

With the techniques outlined here, I get and stay "organized." Then I focus on improving my efficiency and effectiveness.

{2.14.5} Multitasking

May God us keep From single Vision and Newton's sleep!
— William Blake, 1802

(A related machine instruction, "count zero interrupt -- on receiving an interrupt, decrement the counter to zero" was the inspiration for the title and main character of the 1986 science-fiction novel Count Zero [ISBN/ASIN: 0441117732] , the second book in William Gibson's classic cyberpunk Neuromancer trilogy [ISBN/ASIN: 0441569595]. I find this fascinating trivia; your mileage may vary.)

The other important thing is to not wait just because some person or — more usually, a sign or some "bot" — told you to. If you've prepared all your tasks as I described, started each one so you know what's involved, and have everything together ready to work on, you can pick up a task when a gap occurs in another task. For example, when you install software you will often see a message that says "PLEASE WAIT WHILE..." some operation is performed, or, if the program doesn't deign to provide any information, just "PLEASE WAIT." Rebel, don't do it! Instead, pick up another task. Don't you need to read the release notes and the list of fixed and not-fixed bugs in this software anyway? If not, is there some other software you need to read the documentation for? Find something you can do in small chunks while waiting for those "progress bars" (the blue rectangles) to grow from left to right. (But do stay alert — you may have to answer some obscure but critical question at any point in order to continue the installation, to "prove you are worthy.")

This is why I always bring a book to the bank, if I have to wait in line. I refuse to wait and do nothing. At least I can be improving my mind.

{2.14.6} Interruptions

In psychology, a pattern interrupt is an action that changes a dynamic in a personal situation or relationship by making an unexpected change, resulting in a new, and hopefully more effective and beneficial, behavior. This was identified by Milton H. Erickson who called it the confusion technique, as well as others.
— Wikipedia "pattern interrupt" [LINK_2-114]

The previous section dealt with multitasking and the management of interrupts that are responses to actions you initiated originally. But in addition, your job will doubtless bombard you with interrupts that other people originated. On the one hand, you have to deal with them; this is one reason why you're there. But on the other hand, being bombarded with interruptions can impair your efficiency as well as drive you batty. (The above quote is meant to illustrate how strategically-timed interruptions are part of a strategy of hypnotizing a person. Yes, interruptions can put you in a trance. At the count of three you will wake up feeling calm and refreshed. One, two three.) So how do you resolve this paradox between the need to handle interrupts and the disruption they cause?

The answer is you become good at deferring interruptions. It isn't really the interrupt that drags you down, it's the overhead of saving and restoring your task state. So if you can avoid saving state, and "bat away" an interruption briefly, it can buy you a lot of cycles. Then service the interrupt at a natural halting point.

So how does this work? Let's say you're working along, "in the groove," but you have to be available to field phone calls. If possible, set your phone to a "soft ring," and let voice mail pick up. But then check messages and call back within ten or fifteen minutes. If technology or job requires prohibit you from letting the voicemail pick up, then you must master the art of the short interrupt call. The goal is to acknowledge the request, get enough information to call back, and to schedule a callback, all without losing your focus on the task you are working on. This trick works best with people who have come to expect it. Whenever someone new is added to the list of folks who can call on you for help, explain how you work. Loan them a copy of this book if it helps, or cut and paste this passage into an email. Make sure they really believe that you will call right back, and ultimately solve their problem in time for it to be of use to them, but make sure they also know they shouldn't try to engage you in any conversation during that initial call if you've promised to call right back.

This approach only works if you acquire a reputation for quick callbacks, and if you are willing to "drop everything" when someone has an urgent need. (They get to define what urgent is.) The payoff is when you don't feel like you're in overwhelm 20 minutes after you show up on Monday morning and field 15 phone calls asking for help.

This works whether you are working in a small field office, your home office, or at a headquarters. But larger offices will sometimes have the additional problem of people who interrupt you by coming to see you. I have found one useful tactic is to have office hours just like college faculty, which is a set of times during the week when you encourage people to bring you problems and questions, like Mon. Wed. Fri. 4:00 to 5:00 PM. When people come at other times, you can ask if it can wait until your office hours. Another useful tool is to wear headphones when you are not having office hours, to blot out sounds as well as look uninviting,

One TV comedy show Saturday Night Live did a sketch about an unwelcome guest as horror movie, entitled "The Thing That Wouldn't Leave." If you encounter the problem of the visitor who "dawdles" too long repeatedly, start saying, "Hey, I'm right in the middle of this, can I come see you in 5 minutes?" Then, when you go see them, you can leave after you think the business is done.

{2.14.7} Resting

"On the plains of hesitation bleach the countless bones of millions who, on the dawn of success, sat down to rest, and resting, died."
— found written in the inside cover
of an engineering textbook at the
University of Florida at Gainesville, 1953

I've found it to be true for me. Currently I do volunteer project management and web site design and maintenance for the San Diego Professional Chapter of ACM SIGGRAPH, and its SIGKIDS project [LINK_2-115], and it helps refresh me from my work. This type of activity is also a good antidote to the belief creeping in that resting is the goal.

{2.14.8} Procrastination

"Anyone can do any amount of work, provided it isn't the work they are supposed to be doing."
— Robert Benchley

If the task is the problem, you have a very different but equally significant struggle. Your procrastination is trying to tell you that you are making a mistake in your work. I've discovered this on my own and also had it confirmed by others. Pulitzer prize-winning author Annie Dillard talks about the very similar problem of writer's block in her essay on the creative process, The Writing Life (1989, book) [ISBN/ASIN: 0060919884]:

When you are stuck in a book; when you are well into writing it, and know what comes next, and yet cannot go on; when every morning for a week or a month you enter its room and turn your back on it; then the trouble is either of two things. Either the structure has forked, so the narrative, or the logic, has developed a hairline fracture that will shortly split it up the middle,— or you are approaching a fatal mistake. What you had planned will not do. If you pursue your present course, the book will explode or collapse, and you do not know about it quite yet.

I find that this goes not only for writing, but for any kind of design work and for coding software programs. If you have made a mistake or are about to make a mistake, sometimes the only way your creative unconscious knows to alert you is to balk.

Here are four techniques I have found to uncover structural problems: review, walk, talk, and draw.

• First, review the requirements again. Go back to the communications from the client, customer, end user, reader, or other recipient of your work. Pull out the file and look at all your notes again. Reread all the emails. Did you miss something important, perhaps something crucial?

• With your mind full of the requirements, take a walk and get out of the office or home you work in. Or, if you do a daily exercise regime (and if not, why not?), now would be a good time to do it. Get blood flowing to your brain. This often brings preconscious notions to the surface.

• If you still feel stuck after your walk, talk to someone about your problem. Call or visit a friend or coworker and lay out your structure. Even if they don't have an answer for you, going through the exercise of explaining it to someone else can be vital to uncovering flaws in your plan.

• Lastly, try to draw your structure. Make a diagram or flow chart of your task. One of my favorite ways to diagram a task is the good old classic "PERT chart."

  According to the web site History of Booz Allen 1950s [LINK_2-117], the company started by Edwin G. Booz in 1919 went on in the mid 1950s to develop the Critical Path Method (CPM) using Program Evaluation and Review Technique (PERT) charts to manage the enormous complexity of the U.S. Navy's Polaris nuclear submarine project. Today the technique is so widespread that there are dozens of software packages that use it, and it is even built into the ubiquitous "Microsoft Project."

  I find that you don't have to get very fancy to get a lot of value out of the method. Just a simple flow chart of task dependencies can work wonders for your clarity of thought. For example, here is a simple PERT chart for baking a cake:

  

  A refinement would be to to fill in task times, and then find the "Critical Path," the longest time path through the chart. This is the sequence of tasks that are most likely to delay the project. In this case it is probably the path that leads through "heat oven" that is on the critical path.

  If you'd like more training in this technique, do a web search for "PERT tutorial" and dive in!

By way of example, I must report that I suffered briefly from "writer's block" in my writing of this section on "TIME MANAGEMENT." I'm happy to say that I solved the problem using my own techniques. I had originally began the "TIME MANAGEMENT" section with the discussion of "Distractions." But after a few days of struggling to make progress I stopped and thought, and I found that it didn't "ring true." When I'm highly motivated to produce, nothing can stop me. I once wrote a science fiction story on about 15 airline barf bags. I had people all around me on a plane handing them to me. The muse was with me that day and I was unstoppable. To start out talking about minimizing distractions when I hadn't talked about motivation yet just wasn't working. Once I added the "Motivation" section I was able to get back into a writing groove.

If it seems odd that I would have time management problems while writing about time management, it isn't. Things like this happen all the time. Medical students get psychosomatic symptoms of the diseases they study. Abnormal psychology students think they are going crazy. In the fabulous book How to Write a Movie in 21 Days: The Inner Movie Method (1988) [ISBN/ASIN: 0062730665], writing coach Viki King describes how every story has a cycle of yearning, struggle and triumph, and goes on to predict that during the writing of the "second act," the author will struggle to tell the story of the hero's struggle. As Mary Catherine Bateson once said: "Each of us is our own central metaphor." When I coded line printer tests, I dreamed of ASCII test patterns:

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHI
"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJ
#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJK
$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKL
%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLM
&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMN
'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNO
()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOP
)*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQ
*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQR
+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRS
,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRST
-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTU
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUV
/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW
0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWX
123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXY
23456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ
3456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[
456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\
56789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]
6789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^
789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
89:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`
9:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`ab
;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abc
<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcd
=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcde
>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdef
?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh
ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi
BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk
DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl
EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
FGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn
GHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno
HIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnop
IJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopq
JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
KLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
LMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst
MNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu
NOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw
PQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx
QRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy
RSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz
STUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{
TUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|
UVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}
VWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

Okay, so you've gotten this far and the techniques I've given you have solved some of your procrastination problems but not all of them, There are three final strategies left: give up, delegate, and get your head examined.

1. Why not just give up? What happens if you just abandon this task? Sometimes nothing bad happens. In any event, it's a useful mental exercise. And psychologically, it's far better to decide not to do it and move on, than to be paralyzed and feel guilt and despair.

2. Okay, so sometimes you can't give up — the task really must be done. Can you delegate it? This is also known as "giving away the problem." My wife and I have a deal. I find it easy to wire stuff (switch boxes, audio components, etc.) and nearly impossible to fill out medical insurance forms; she is the opposite. So she fills out all my forms and I do all her wiring. It pays to know what you can do very well very easily, and to be able to barter for the things you do poorly.

3. If you get to this point, you are hopelessly stuck procrastinating on a job that must be done and you can't (or won't) give away, it's probably time to have your head examined. I'm serious. You need to confront your self-destructive behavior, and you're better off getting professional help when you do it. I have seen ruinous procrastination destroy more careers than any other neurosis, including addictions, depressions and phobias. It can be caused by over-perfectionism, or a feeling of unworthiness, or hidden hostility, or fear of criticism, or a number of other things; in any case you have to beat it to succeed in high-tech.

Seven of Disks There comes a time in every programmer's life when, after months of design, development, and debugging, he may come to discover an architectural oversight, flaw in basic reasoning, or mistaken key assumption. In a rush it dawns on him that the whole project must be scrapped and rethought. Desolation reigns. Despair, disaster, calamity, setbacks. Reversed: time to question sacred assumptions. Silicon Valley Tarot © 1998, Thomas Scoville.

{2.14.9} Anticipation

This is the ultimate time management skill, because when it succeeds, it looks like you have a time machine.

In the last chapter, talking about anticipation in travel, I gave this quote from the 2001 Robert Altman film Gosford Park [ASIN: B00005JKNF], but it bears repeating in a new context. The character of senior housekeeper Mrs. Wilson explains how she knew a murder was about to take place before the fact:

MRS WILSON:

What gift do you think a good servant has that separates them from the others? It's the gift of anticipation. And I'm a good servant. I'm better than good. I'm the best. I'm the perfect servant. I know when they'll be hungry and the food is ready. I know when they'll be tired and the bed is turned down. I know it before they know it themselves.

This same gift of anticipation makes a great traveling techie, or any kind of techie for that matter.

As impossible and exasperating as it may seem, you will be judged as great by your constituency — the non-techies who depend on you — only if you succeed most of the time at guessing what they want, working on it advance and having it ready, and pulling it out and giving it to them when they ask for it.

How can this be even be possible? Well you may ask. But impossible or not, it's what you've got to do. The two best strategies I have found are: think like them and watch for repeats. (A third, more advanced strategy is: look for higher order approximations.)

• Think like them.

  I know some of you are out there are saying to yourselves, "Do I have to think like them?" Set aside the fact that they are nontechnical. Chances are there's some technical specialty you're clueless about, too. Pretend this is that. Pretend that you are dealing with an unfamiliar technology. Think about what their job is, what they get recognition and compensation for, how they are evaluated, what their goals are. Think about their problems, their frustrations, especially with technology. Then think about what would really help them solve their problem, that you can provide. Then start work on it. Don't tell them about it until it's done; think of it as a learning exercise. Chances are the way it will actually play out is that they will come to you with a similar requirement, and you will be able to quickly modify what you have (or are working on) to meet their needs, therefore seeming like a wizard.

  I learned this lesson well in job G. I was working at an aerospace company bidding for a government contract to build a portion of the United States space station announced by President Reagan in 1983. I was brought into the company to work in a 3D graphics lab, programming equipment with an interface I'd helped to design in a previous job, making real-time three-dimensional computer animations that were way ahead of their time in 1986. If I remember correctly, the last task assignment my boss gave me was to program the 3D graphics system to show the articulated robot arm on the space shuttle seen from any of its cameras, including the ones on the robot arm's wrist and elbow. That was pretty tricky but I got it done. Then my boss left the huge aerospace company to work on his own high-tech startup (doing contract work for aerospace companies and graphics equipment vendors), and I don't recall ever getting another work assignment. We got a new boss every month for quite a while. I filled out my time card with a charge number for software maintenance. But I knew that we would be left alone for a while and then somebody would come to us in a panic and want something. There were four of us who worked in the lab; I was one of two programmers, and we had a spacecraft modeler, and an audio/video editor. So I suggested we guess what was going to be needed and then start work on it.

  We got the latest engineering drawings from NASA and our own engineers on how the space station parts were to be packed in the shuttle and then deployed. Sure enough, we soon discovered some unexpected problems. There were some new details in the latest plan we hadn't been aware of. In addition to the deployment of parts by the robot arm, which we were ready to show, there were two other new deployment modes. Astronauts with their boots mounted on tracks would slide up and down either side of the cargo hold and put together the "struts," 6 meter poles that worked like giant tinker toys to form the main truss of the space station. We had to model, program and animate the sliding boots on the tracks, and astronauts in space suits attached to those boots, with movable arms that could grasp struts. Also, some of the modules were self-deploying, with parts that popped out into place under machine control, and we had to model, program and animate those too. But we managed to get most of it done before the first panicky request came from upper management, and of course then we looked like wizards when we delivered it in short order.

• Watch for repeats.

  If you're old enough to have worked with an oscilloscope analyzing repeating waveforms from analog circuits, then you know this: when a signal repeats (i.e., is cyclic), you can seem to "go back in time" by going forward (waiting) the right amount of time. You can trigger an event before a waveform peaks by adding a delay until just before the next peak.

  I have found that work requirements in high-tech can be very cyclic. You may recall in the chapter on travel I gave a rule of thumb for driving: if another vehicle's driver endangers you by their actions, they will probably do it again. A similar rule of thumb applies to the people who depend on you: if they come to you in a panic at the last minute needing something, they will do it again. Especially if it worked the first time. And most of the time what they'll want is what they got the last time with a minor change. From your point of view they just didn't do a good enough job of telling you what they needed. You're right, but too bad. You still have to fix it. As a sales guy I once knew liked to say: "Get to know it." In other words, when you finish a project pretend someone said, "Now redo it," and act accordingly. Is there anything you can do to get started?

  In the above story of the space station assembly animations we did, the requirements for the videos we were asked for in a panic at the last minute were very cyclic. Some NASA bigwig would be visiting the company and they'd want to show him or her a video of the latest design of the space station being assembled. It took our team about two weeks to do a one video, and meanwhile the design from NASA changed almost daily. We quickly learned that the path to ruin was to start over with every change. No video would ever get done that way. What we had to do was freeze a design at some point, spend the two weeks making the video, and then start over. At any given point we had a complete video with a design two weeks old or newer. Sometimes we had a video that was up to date or just a few days out of date. Overall we did a great job of giving management what they needed, entirely by anticipating.

• Extra credit: Look for higher order approximations.

  If you've ever studied calculus enough to be exposed to the concept of the Taylor Series, it is pertinent to predicting your future work assignments.

  First a little theory: the Taylor Series allows you to approximate certain well-behaved functions with simple arithmetic. For a given function of x — called f(x) —you create a series of terms using x, x squared, x cubed, and so on, based on knowing the function's value for some single value of x (often called a) along with its derivatives at x = a. You need to able to find its first derivative, second derivative, third derivative, etc., or in other words: rate of change, rate of change of rate of change, rate of change of rate of change of rate of change, etc., or in still other words: slope of the graph, slope of the graph of the slope of the graph, slope of the graph of the slope of the graph of the slope of the graph, and so on. So when you go to predict the function, you use a potentially infinite expression, but you only add as many terms as you feel like doing the arithmetic for; if you add up N terms, we say the result is an Nth order approximation.

  Let's look at a simplified example that uses discrete data. Say we want the value of the function where x = a + 1. A zeroth order approximation of the function would be zero. No matter what the value of f(a) and its derivatives are, who cares, the result will be zero. And in some cases this is not a bad approximation. It's like assuming nothing will happen. Sometimes you're right. A first order approximation would be whatever the function was at x = a. It will just stay the same. This is true for all constant functions. It's like assuming the same thing will keep happening again. Sometime it does. A second order approximation involves looking at how the function's value has been changing, say over the interval from a - 1 to a. Call that difference delta (it's not really calculus without a Greek letter here and there) and say that the prediction at x = a + 1 is equal to the value at x = a with delta added. In other words, things are going to keep changing the way they have. This is like assuming that whatever change you've seen in your work assignment from one day to the next will keep happening.

  I have found that if you can achieve a second order approximation in your prediction of your future work assignments, you will be way ahead of the game. And you will continue to achieve a reputation as a wizard.

{2.15} RISK MANAGEMENT

"Progress always involves risk; you cannot steal second base and keep your foot on first."
— Frederick Wilcox

{2.15.1} Maximize Slack

The Moving Finger writes; and, having writ,
Moves on: nor all your Piety nor Wit
Shall lure it back to cancel half a Line,
Nor all your Tears wash out a Word of it.
— Omar Khayyam, 1151
      Rubaiyat [ISBN/ASIN: 0312695276]

I define "slack" as unused resources. Resources include: time (your time as well as "real time," i.e. clock time), your "energy" (attention, freshness, and mental resourcefulness, or what my friend Eric calls "gumption"), and access to people, equipment and information you need to do your job. The fastest way to squander slack, in my experience, is to assume everything is and will continue to be just the way you think it is, with no problems. If that's true, you can wait until 11:57 to cook a three minute egg and have it done by twelve. If it isn't, you'll be in trouble.

Make every decision while mindful of maximizing slack. Here are some specific tips.

• Start every task early.

  When you get a task assignment, do a sanity check on everything you've been given as soon as possible. If someone gives you a CD-ROM, mount it and look at the files immediately, if possible while the person it's from is still with you. Maybe they gave you the wrong one. If you were sent an email with an attachment, like a Word "doc" file with important details, open the attachment and make sure you can read the file. Make sure it's the right file. Maybe the person who sent you the email is going on vacation for three weeks starting tomorrow, and you need to get that file re-sent right away to avoid a delay. If they sent you a web address (URL), go there and make sure the address is right. If it's software, try to install it. If it's a report for you to read, flip through the pages. Is it the right report? Does it have all of the pages? In other words, do whatever you can to quickly verify you have everything you need to work.

• Do the hardest thing first.

  I recommended earlier that you break tasks into equal-sized chunks. Of course, this really only works with repetitive tasks, which are those best done by a machine. This doesn't work as well with tasks for humans. Writing ten software modules or designing ten avionics components can hardly be claimed to consist "equal sized" tasks — each will have its own unique problems and delays. The way to adjust for this is to prioritize your chunks by how risky they are, and do the highest risk tasks first. The way to tell a task is risky is by one of these warning signs:

  • you expect the task will be "hard"

  • you have no clear plan for proceeding

  • you've never done something like it before

  • you'll be using unproven technology

  • it seems incredibly boring

  • something about it scares you

  • others have warned you about it

  If any tasks have these warning signs, move them up the list. Tackle them first and make all your time estimates based on how long it takes to complete these higher-risk tasks. This will make your estimates very conservative when you apply them to the lower-risk tasks, and you will probably beat your schedule.

  Consider the calamity that results if you take the opposite approach, saving the riskiest and scariest tasks for last. You will tend to create and communicate false optimism early on, and then end up way behind schedule in the end, digging out from under a toxic pile of high-risk, perilous tasks.

• Build slack into your technical decisions.

  You need to take slack into account when you make decisions like:

  • What tools at your disposal to use in doing your job.

  • what file formats to use for information storage and distribution

  • what kind of hardware, computers, operating system, language, and tool sets to use to develop new products as well as other support tools

  • what vendors to trust and what partners to team with in bringing products to market,

  As a traveling techie you may or may not be involved in the enterprise-wide decisions. But in the areas you control — and are accountable for — factor in future flexibility and changing your mind in your design and technology decisions. Be aware of the technical tradeoffs, efficiencies, compatibilities, and likelihood of future support for each approach you consider.

  In medicine, blood types are broken into our main categories: A, B, AB and O. The relationships between donor and recipient is as follows:

  • A can donate to A.
  • A cannot donate to B.
  • A can donate to AB.
  • A cannot donate to O.

  • B cannot donate to A.
  • B can donate to B.
  • B can donate to AB.
  • A cannot donate to O.

  • AB cannot donate to A.
  • AB cannot donate to B.
  • AB can donate to AB.
  • AB cannot donate to O.

  • O can donate to A.
  • O can donate to B.
  • O can donate to AB.
  • O can donate to O.

  If you examine the above relationships, it will become clear that type O blood is a "universal donor," and can donate to any type, while type AB is a "universal recipient," and can receive blood from any type. If you were stockpiling blood, type O would be the best type to collect; if you are a patient, type AB is the best to be fortunate enough to have.

  There is an analogy to media types. The also have their universal donors and universal recipients. Usually an older version of hardware, density, format or file system type is likely to be a universal donor, while the latest and greatest will be a universal recipient.

  universal donor	universal recipient
  tar (tape archive) file format	zip file format
  Double Sided, Double Density (DS/DD) 720 KB 3.5" diskettes	Double Sided, High Density (DS/HD) 1.44 MB 3.5 " diskettes
  producing Quicktime media files on a Mac	playing Windows and Quicktime media files on a PC
  an older UNIX shell based email program (like 'mail')	a newer Graphical User Interface (GUI) based email program that parses MIME attachments and HTML (like Outlook or Mac Mail)

  When distributing data and/or software, it is better to use a universal donor; if you are receiving a lot of media from others, you'll need a universal recipient.

  You also need to consider the general issue of standards vs. proprietary technology. What will you do if your vendor abandons the technology, or goes out of business? How many options do you have? What if the target systems change? How portable will your solution be? These are the kinds of considerations to look at in choosing file formats as well as development tools.

  These kinds of considerations might lead you to favor creating data CDs in the vendor-neutral and operating system-neutral format ISO 9660 instead of in a PC or Mac format. It might also lead you to favor Java (runs on PC, Mac and UNIX) over C# (runs only on PC, controlled by Microsoft) in selecting a development language.

• Expect delays and have a plan.

  Once I was a consultant at a company that hired me to program a custom graphics system. The vendor was late with the hardware, but it was expected any day. I was surprised by the level of faith everyone had that the system would arrive immanently. I knew from previous jobs that something doesn't have to be timely just because you really need it. Things you're depending on can be unbelievably late, even if that would cause huge problems. I decided to "tweak" them all a little; after all, I was just the consultant. I would be gone in half a year after the project ended. (I don't think I would repeat this decision to be so deliberately annoying today.) I suggested an "office pool" to guess what day the system would arrive. I made a calendar and extended it way past when anyone thought the system would arrive — about two months. I let people buy a day for a quarter. Whoever got closest to the winning day got all the money. I had the group administrator hold the money. I bet on the last day of the calendar. It was like shooting fish in a barrel. The system had been promised in two more weeks, so most people bought days very soon after that. By the time the system arrived, about four months late, the office pool was long forgotten. When I collected my money they were all pretty sore that I was rubbing their noses in the fact that they were foolish to believe the vendor's promises, and that their faith had cost them a lot of stress and annoyance, as well as all the quarters I won.

  When you are counting on other people you can't control to deliver something, I have found that the prudent thing is to double the time estimate they give you and then convert to the next highest unit of time. For example: 10 minutes becomes 20 hours, 3 days becomes 6 weeks, and one month become two years. Don't tell the people you're depending on this is what you expect, just come up with a plan for dealing with a delay of that magnitude.

  In the above example of the late graphics system, this formula would have worked perfectly. A two week estimate turned into four months. The problems most people have with using this technique are:

  1. The result seems completely absurd.

  2. The results of such a delay would be a total disaster.

  But the fact that something would be terrible doesn't keep it from happening. Try this technique. See how often it's right. And see how often having a plan reduces the calamity.

  The Consultant You will know him by his natty wardrobe and excellent hair. His arms are crossed, as if to say he knows more than you do, and he might just help you out - if you're nice to him. The clock is his friend and familiar; he bills by the hour. He stands against a money-green background; he has other clients. Reversed: incompetence, waste, arrogance, expensive lunches. Silicon Valley Tarot © 1998, Thomas Scoville.

• Expect catastrophe and have a plan.

  There are things more destructive than a huge delay. You can actually lose work accomplished. Disks can fry and CDs can scratch. I've seen what happens when a printed circuit board is in a UPS truck that is hit by lightning. I've had documentation damaged by a flood. I've heard tales of malicious employees erasing all known backups. And of course I've had no end of equipment and other vital shipments not showing up. In general, things can not only fail to get better at the rate you expected, they can also get worse. Not that often, but often enough to require contingency planning.

  As I explained in more detail in chapter one, in section 1.3.2 "Allow Time For the Probable Bad Case Scenarios," The overall approach to handling these kind of low-probability but high-impact disaster scenarios is to have a set of fallback plans of decreasing ambition. For example, at a trade show, if you can't demo, can you show a PowerPoint presentation? If you can't do that, can you show a video? If you can't do that, do you have informative signage and literature to give out? For every level of calamity you should have a plan. Don't ever catch yourself saying, "I didn't bring the video because I thought we didn't need it — we had a computer with a demo on it!" You might as well be saying, "I think everything will go perfectly, and if it doesn't I'm completely unprepared!"

  One vital risk-mitigation strategy I have used since my early career days as a technical writer is an approach I call "start by finishing." It is based on the assumption that something is going to happen — a power failure, a jammed printer, an internet outage, or who knows what — when you least expect it, and keep you from finishing the job. You think you have plenty of time, and suddenly "blam!" and you can't go on. The only solution is to have a finished project available at all times. "Huh?" you may say. This may sound impossible but, surprisingly, it usually isn't. They key is work as fast as possible on something that is complete but inadequate. It suffers from abysmal quality and is almost useless, but doggone it, it does seem complete. From that point on the task becomes to incrementally improve the deliverable. If at any point the "plug is pulled," you can deliver what you have. It may not be perfect, but it's better than nothing, and it's also better than something half-done that's not in a deliverable form, like a document on the hard drive that's only half-written and isn't printed out yet.

  In my tech writing days I would be assigned a book to write and the first thing I would do is make a cover for the book and put it on a three-ring binder. Second I would write the tentative table of contents, print that out, and put it in the binder. Something like this:

  How To Make a Perfect Martini The Vermouth The Gin The Ice The Perfect Ratio Shaken or Stirred? The Garnish (Olive, Onion or ???) The Vodka Martini and Other Variations 101 Martini Recipes

  The I'd copy the table of contents, reformat it to have one line per page, and print it all out again and put it in the binder, like this:

  1. The Vermouth

  2. The Gin

  ... and so on. Now I had something that was starting to look like a book. I'd go back through the table of contents and "flesh out" the outline, like so:

  How To Make a Perfect Martini The Vermouth Vineyard Year Storing Serving The Gin Distillery Age Storing Serving The Ice Shape Size Temperature The Bucket and Tongs Dispensing the Ice ... and so on.

  Then, once again, I would copy the table of contents, reformat it to be one line per page, print it all out, and put it in the notebook. The book grows. Now I have something I can carry around, and write in if need be. I would keep iterating the process, filling in more detail each time, and printing out frequently. It comes in handy to have a copy of the book to refer to while writing it. Even if a section can't be written yet (key technical information is not yet available), the goal of the section can usually be spelled out: "This section will show you how to evaluate a distillery when deciding what brand of gin to buy." This will serve as a place holder until I get the information. At any time in this process someone may run in and says "Quick! We need a copy of the book to..." (fill in the blank). Maybe they need to show it to managers, or stockholders, or prospects, or marketing people, or the sales force. Give 'em what you've got. It's better than nothing. And it keeps getting better as you work on it.

  Though I developed this technique with writing manuals, I found it applied to writing software as well. The key is to get the program into a state where you can test it as soon as possible. Then you keep coding and testing iteratively. For example, if a "paint" program is supposed to let the user perform all of these functions:

  • create new file
  • paint on screen to "edit" file
  • save to file
  • read from file
  • display file

  I would do the last two steps first. Hand create a small test file, and get the program to read and display it. Now that's something I (or anyone else) can test. From there I would start adding features. If at any point someone runs in and wants to see how the paint program is coming, I have a picture on the screen to show them. Marketing can take some preliminary screen shots. We can see how the colors look on different monitors. We can see how long it takes a certain sized image to load. You get the idea.

  This approach is an antidote to perfectionism. Like the television commercial that brags, "We will sell no wine before it's time," the perfectionist will release no deliverable before it's perfect. Somehow the choice has been framed as perfection or nothing. In the business world, especially the high-tech world, this is a ticket to the nearest exit. But if you use my method, you already have a deliverable, it's just of unacceptably low quality (by your own standards — it may be just what marketing needs). Suddenly the pressure is on you to improve it, right now, any way you can, as fast as you can, so if somebody runs in and needs it it won't be be so bad. You see? The dynamic is that you will tend to work very quickly solving the biggest problems first, instead of laboring slowly and carefully over every detail as you would in the "perfectionist" context.

{2.15.2} Isolate Research From Production

Who put the overalls in Mrs. Murphy's chowder?
— American folk saying

{2.15.3} Simulate and Rehearse

"It turned out to be pretty much like the simulator."
— astronaut Donald Williams, 1985
describing being launched in a space shuttle

The best technical advice I ever got was from my boss in job L, who suggested that techies should emulate NASA and rehearse as much as possible. Every space mission is rehearsed in simulators, often for years, before it happens.

I was privileged to be able to travel to the Kennedy Space Center (KSC) on the east coast of Florida to see the first launch of the space shuttle Columbia in 1981, and a few days before the launch we took the KSC bus tour. A small plane was taking off and landing over and over on the runway that would be used by the shuttle in later flights (this first test flight would land at Edwards dry lake in California). The bus driver didn't tell us anything about it, but kept us well away from it, stopping and waiting as it landed and took off again. Some months later I found out that what we'd seen was (according to the NASA web site) "a modified Grumman Gulfstream II, known as the Shuttle Training Aircraft (STA), which is configured to simulate the handling characteristics of the orbiter. It is used extensively for landing practice ... at KSC's Shuttle Landing Facility." What we'd seen was astronaut John Young, scheduled to begin his mission the next day, rehearsing the most critical part —- the landing — over and over again. (The officials at KSC kept the training flights a secret from the tourists at the time as a security measure.)

I've often thought since about that discipline: to rehearse something again and again that you already know like the back of your hand. And yet, in high-tech, the norm is often the other extreme: zero rehearsal. In my first job that involved giving demos at trade show, I was astonished that marketing assembled us "demo pilots" for an hour meeting in the booth before the show started, and spent the whole time telling us what the new marketing message was. "When do we learn the demos?" I wondered. The answer was "never." The show started, and we were each stuck at a workstation unprepared. I would've felt inadequate if it was just me, but this was a start-up and nobody knew the demos. We quickly compared notes and worked a routine in whispers as prospects began to pour into the exhibit hall.

What I learned from this that the idea of "technical rehearsal" is a blind spot to some, and as a techie you may have to fight for it. The concept is well known in live theater. Any complex broadway show has numerous technical rehearsals independent of the actors, dancers and musicians, just to make sure the lights and automated set changes all work, and then they all get together and do it a bunch of times before the final dress rehearsal. Make sure you get the same chance to succeed.

At one point in my career I volunteered for an organization that gave self-improvement seminars; I thought the seminars were good for people and I wanted to improve my "people skills." (It worked. My interaction and phone skills improved dramatically.) In this organization, one of the things people said a lot was, "Let's mock it up." We'd be in a meeting, talking about how we were going to greet people and get a name tag onto them, and somebody'd say, "Lets mock it up," and the next thing you know we'd be acting out the process. It felt silly at first, but we got used to it and it turned out to be a very handy tool for communicating procedure as well as resolving miscommunications in verbal instructions.

The thing you don't ever want to do is find yourself giving an important demo, or doing important production work under a tight deadline, and thinking to yourself, "this should work." That means you don't know if it will work, which means it might not work. I've had people tell me that means it won't work. A coworker of mine, a Mr. Emmons, coined a "law" on this very subject, to wit:

Emmons' Law: If it isn't tested, it doesn't work.

I have seen this proved true countless times, usually to someone's surprise — but not mine. My lessons on this subject in the "school of hard knocks" have been brutal at times. A single maddening example should suffice.

• "It's just a missing push-button..."

  In job E, a very small start-up, I was the acting Quality Assurance (QA) department, because I managed customer support and any bad systems immediately became my problem when they were delivered. I did final test before the end-of-the-month shipments. Counterbalancing the pressure to deliver quality systems I had the operations manager leaning on me because he had to ship the systems to recognize the revenue for the month. One particular month we only had one system, going to an aerospace company in Los Angeles county (we were in San Diego, a few hours south). It was all set to go except a part had not come in: the red rectangular plastic "push to connect" spring-loaded switch, in other words a button, which served as the "reset button" for the system. He showed me how to reset it temporarily by touching the wires, and assured me a switch was being air expressed to us. He proposed shipping the system without it, and he promised that when the system arrived in LA in a day or two he'd drive the part to the customer site personally and install the button on the spot. I fell for it.

  A few days later the shipment arrived in LA and, true to his promise, the operations manager drove up with the part. I was there too, since I wanted to personally supervise this installation as customer support manager. We uncrated the system. With a few turns of a screwdriver he had the button installed. We powered up. The system was dead. It wouldn't even try to boot. Pressing the red reset button caused the console screen to flash for a moment, then nothing. We couldn't figure it out. After a day of fruitless experiments and phone consultations, the chief engineer joined us at the customer site. He hooked a scope to the main processor. "It looks like it's being reset over and over again," he said. To make a long story short: by mistake the supplier had provided a red rectangular plastic "push to disconnect" spring-loaded switch, in other words a button that was always on except when you pushed it. The system was being reset over and over again. And I learned an important lesson about Emmons' Law: it even applies to simple parts.

{2.15.4} Make Extra Copies

"[your] insecurity will be guaranteed by the Department of Redundancy Department..."
— The Firesign Theatre, 1970
      Don't Crush That Dwarf, Hand Me the Pliers (audio comedy) [ASIN: B00005T7IS]

I used to work in a large cube farm in suburban New England, where it was prone to thunder storms in the summer. Despite the fact that we were using "dumb" terminals hooked with serial cables to a time-sharing minicomputer, the setup had something in common with most of today's Local Area Networks (LANs) of desktop computers: when the power went out, we lost our unsaved files.

Sometimes I would feel the hairs rising all over my arms (due to static electricity in the air), and then there'd be a brilliant flash of light, just as the power went down all over the building, followed by by a deafening thunder crack, and sound of a hundred voices saying "Aw, [expletive]!" at once. This training ground taught me to save early and save often. If I feel a funny twitch, save my file. If the phone rings, save my file. If I experience a deja vu, save my file.

But, of course, this is only the first step. Your files, once saved, must be "backed up." What this means to me is lots of copies in different places and if possible in different forms. You never know how many will be enough. I remember a project for job H: I'd slaved over this benchmark for the Jet Propulsion Laboratory (JPL), during an 80-hour week spent mostly at a Silicon Valley engineering facility, concluding with a marathon weekend. But I succeeded. Before flying home to Los Angeles Sunday night, I made a tape copy of my results, and uploaded a copy to my server in the LA office, and uploaded another copy to a server in the corporate headquarters in Massachusetts. (And this was over 300 baud dial-up connections!) Boy was I glad. When I showed up in my office Monday morning — the day the results were due and had to be emailed to JPL — my office server was down, and wouldn't be fixed until the next day. The tape turned out to be bad. I pulled the third copy off the Massachusetts server, and emailed it in before the deadline.

It was educational for me to barely escape calamity on that occasion, but it has been far more educational when I did not escape calamity. I have had a few catastrophic data losses with insufficient backups in my time. I've never lost job-related data, but I've been more careless with personal data. Let's see: an Apple II 5.25 inch floppy with my checkbook record, in 1981 (no backup except a hardcopy); a Mac SE hard drive with my financial records and writing in progress in 1990 (no backup except a hard copy); files (mostly emails) on a server at my ISP which I accidentally deleted in 1996 (no backup); a Mac Performa hard drive with financial records and writing projects in 1998 (last backup one year old). Call me a slow learner in this area. I now use automatic backup tools as much as possible (Carbonite on PC, Time Machine on Mac).

There was a Chinese emperor who ordered all books burned, so that history would begin with him. When you've survived catastrophic data loss, you observe that certain histories begin right after the data loss. My oldest file at my ISP is dated Jan. 10, 1996, but I've had the account since 1989. I wish I could communicate to you youngsters out there the pangs of regret that come from working hard on something and then losing it unnecessarily due to stupidity. Save yourselves! Save your data!

It is also important to distribute your backups geographically, as I did with the JPL data. I have been around a number of natural disasters and had close friends survive many more, and they are all surprisingly localized. A few miles from the disaster things are fine. So a little geographical distribution goes a long way. Of course, with the internet, there is no limit to how diverse your backup locations can be.

But long before the internet, and even before the buzz-phrase Information Technology (IT) became popular, what we now call IT managers knew the importance of off-site backups. My dad used to manage a computer facility in the late 1970s and early 1980s. He'd been an airline pilot for many years when he was "drafted" by the company to manage its new flight simulator facility. (He eventually tired of the problems an administrator faces, and went back to flying until he retired.) He told me a story once of a guy he met at a computer conference, who also managed a computer facility, who'd had his disk data trashed along with all copies of the backup tapes, by a disgruntled employee. The computer and tapes were all inside a secure facility, but the employee was trusted so it didn't make any difference. After comparing notes on their facilities, these two — my dad and other facility manager — agreed to make an extra set of backup tapes every month, and send them to each other. No money changed hands, and nothing was announced, they just quietly exchanged off-site backups. Their thinking was that a disgruntled employee can't erase what they don't know about. (This was back when the laws about software were close to nonexistent — but the disgruntled employee and the IT manager might both be committing crimes given today's laws. Talk to your lawyer before you take any backups home.)

Growing up in brush fire territory, something I noticed in news reports of people whose homes burned up was the number of times people remarked that everything was replaceable except the photo albums. Hopefully with inexpensive scanners and digital cameras becoming more available and widely adopted, people will begin making backups of their family photos, perhaps by exchanging CDs with relatives, and prevent this tragedy in the future.

I am writing this book in San Diego county, California, and several times a day I save my writing to my ISP which is San Francisco, about 500 miles away. I just stick it on my web site in an unlinked web page (so the crawlers won't find it and index it for search engines), but since I know the web address I can get to it from anywhere in the world. I do the same with my phone list and so I can go into any FedEx Office and print out a fresh copy. I call this "backing up to the web."

One way to ease the burden of backing up is to make it easy, even thoughtless, to back things up. This can be done both formally and informally. To do it formally have automated systems that back up to tapes, to networked servers, to anywhere else you can copy data. Informally the best strategy I have found is to make sure you have numerous high-bandwidth pathways data can follow, what I call "big buckets" for data: Ethernet connections, a DVD burner, broadband internet access, high-volume external disks, USB memory sticks (which are the way of the future), etc. Make sure you are always dumping "snapshots" of your work out by these various means as a hedge against data loss. Two corollaries: the best backup is a complete clone of your system (which you can actually do sometimes with classroom systems, trade show systems, etc.) and the ideal form of any backup is a working, testable version of whatever it is, not some archive file or tape.

This implies that whenever anyone asks you for a copy of something you should give it to them. Think of this as backing up to your constituency. This works well when you have a deliverable and you are iterating it: put it where your constituency can make a copy and try it out in its partial state, be it a web page, a word processing document, a Computer-Aided Design (CAD) drawing, a software project, or whatever, as long as it's digital. This has the twin advantages of reducing the progress reports you have to make, and catching total misunderstandings as to the job requirement early in the process. Just upload a snapshot of your work (with the current date in the filename) a few times a day.

In addition to machine-readable backups, every now and then get a complete hardcopy output of your work. Maybe I'm old-fashioned, and fighting the "paperless office" trend (which is always on the way and never arrives), but deep down I believe "the only real backup is a hard copy." If it's human-readable, and can be keyed in — even if it's expensive, it will be possible. There are no obsolescence problems, unlike any other medium. Plus, you may be able to review it and decide you don't need to key it in. It is far better than losing a digital copy and having no way to review or inventory what you've lost, and being left wondering.

Of course, the concept of a backup applies to more than just computer files. There used to be a beautiful old 1930s vintage building in the "Miracle Mile" district of Los Angeles, called the Pan-Pacific Auditorium, which had enchanting futuristic art deco accents; it was used in the movie "Xanadu" for the exterior of the roller disco palace. It burned down one day in the 1980s; I remember remarking to a programmer friend that the design had been copied for the facade of the ticket booths and entrance turnstiles to a recent theme park: Disney Studios at Walt Disney World in Florida. "Well," my friend replied, "at least they made a backup."

Theoretically, mechanical prototypes, production facilities, expert teams, DNA sequences, ecosystems, and even biospheres can all be "backed up" somehow. And if I may offer an opinion, I think backing them all up is a good idea.

The Server The server stands on a raised floor, in an air-conditioned room, in a locked building. It's a bank-vault of precious corporate data. But there's a paradox: as its yellow crown attests, it is well-networked, and thus the vault is vulnerable. But if it were not networked, it would not be a server. The archetypal server's lemniscate indicates its 24x7 availability, ensuring its status as a totally abstract concept. Reversed: darkness, isolation, loneliness, dwindling MIS budget. Silicon Valley Tarot © 1998, Thomas Scoville.

{2.15.5} Slow Down For Hazards

Doh!
— Homer Simpson

• removing files

  You probably already know that when you are deleting files you are at risk. I grew up with UNIX and so know the horror of the irreversible rm (remove) command. I am loathe to admit this, but once I was helping a coworker debug some C code on a UNIX system, with a bunch of source files name things like:

  init.c
  load.c
  save.c
  

  etc. I was following this sequence: edit the source files with code fixes and changes, delete the object files (all ending in .o) using a "remove" command with wildcards, to force a complete recompile, compile with the make command, run the program with a test script (if compilations succeeded), and repeat. So it looked like this:

  1. vi *.c
  2. rm *.o
  3. make
  4. test

  But one time, instead of step two I accidentally typed:

  rm *.c

  which of course removed all of the source files. "Doh!" Luckily she had a copy of them stashed elsewhere. (What does this teach us?) Since then, I've evolved some disciplines when working with the dreaded rm (remove) command, and its cousins the trash can and recycle bin Macs and Windows:

  • Stop and think.

    The benefits of this should be obvious. Most accidental data destruction could be prevented by this step.

  • Back up before deleting.

    This may sound silly, but remember that blank CDs are under a buck now. If you need to reduce file usage to make room for something, back everything up first.

  • Use your hands.

    Sometimes, when deleting with a shell command, I will type the command without the enter key (I still call it a carriage return), and then stop and run my finger along the command line on the screen while I verify mentally what I am doing. It reminds me of the carpenter's saying, "measure twice, cut once."

  • Verify what you are deleting.

    If you're in a UNIX shell, use the ls (list) command first to verify your wildcards are resolving to the filename you think, or use filename completion if you have it. In a graphical user interface (GUI) like Windows or Mac, be careful what you lasso or otherwise select for deleting. If you're doing something tricky create a "to-delete" folder first and drag stuff into it, then check it before deleting the whole thing. Now, some of you are thinking "This is what the trash can or recycle bin is for — being able to undo a delete." I say, don't trust it. It doesn't always work the way you think it will.

    Also, see if you can quickly preview files before deleting them, to verify they are what you think. There are applications that can make this easier. For example, ACDSee [LINK_2-121] for images on Windows, which allows you to see image file thumbnails, rename files, copy or move files to other folders, auto-rename files when copying and encountering duplicate names, and delete files.

  • Don't delete if you can avoid it.

    If you're cleaning up after a project, take the latest versions of everything and put them in a folder, and then put all the rest of the junk in a "scrap" folder. That way you can still sort out the completed work from the fragmented pieces and works in progress, but you can still also go sifting through the scraps if you're looking for something later to use in another context.

    If you're writing code of any complexity, or over a long time, or with a team collaborating, be sure to use a source code control system such as CVS - Concurrent Versions System [LINK_2-122] to preserve your coding history and be able to rewind to working versions if somebody breaks something.

    If you're testing to see if a file is needed, try just renaming it. Learn to put date code in filenames, like testdata_090527.txt which encodes 09 (2009) 05 (May) 27. That way a normal text sort (ASCII order) will put files in date order as well. This makes it easier to put things back the way they were, since you can see from date codes when files were messed with. Again some of you are thinking, "Doesn't the operating system do this for you with file dates?" Again I say, don't trust it. If you have to copy everything somewhere, or restore from a CD backup or even a "zip" or "tar" archive, the operating system may lose date information.

    (Fun facts to know: In the above scenario in which I removed the source code files, using touch *.c in UNIX also forces a full compilation, but does not delete anything.)

• disassembling equipment

  When you are taking a piece of equipment apart, you are in a danger zone. The one time I rebuilt a Volkswagen engine, following the instructions in How To Keep Your Volkswagen Alive: A Manual of Step-by-Step Procedures for the Compleat Idiot (1969) by John Muir [ISBN/ASIN: 1566913101], I was saved from catastrophe by Muir's detailed instructions on how to take the nuts, bolts, washers, gaskets, brackets..., every little thing that came off that engine and put them into sorted and labeled Baggies^TM. That along with detailed instructions on how to actually put it all back together helped make a project that could've been a "train wreck" into a successfully rebuilt and operating VW engine.

  I have found that it is equally hazardous to disassemble a computer. When you unplug things in a hurry from a system you don't know well, you are in great peril. I have learned this lesson the hard way, with much suffering. There may be two identical jacks on the back of a computer and you just unplugged a connector from one of them. Will you remember which one when you try to plug it all back in? It only takes a handful of screw-ups like this combined and suddenly you have 32 combinations of connector configurations to try.

• when the road forks if you were going the other way

  Yogi Bera wrote a book called, When You Come to a Fork in the Road, Take It! This is not quite the same thing. As you see in this figure:

  

  whether you're driving on a road or walking on a trail, you will occasionally come to a fork in the road, as in case A. You have to make a choice before you continue. Upon your return, if you come back the same way as in case B, there is no choice for you to make; you simply "join" a path already in progress.

  The trouble comes when you encounter situation B first. If you fail to notice you are "joining a path," when you come back you won't know which fork to take. Of course this applies directly to navigation, but we're not in the "Travel" chapter here; we're in the "Tech" chapter. I'm asking you to think metaphorically. What situations do you encounter that are like "when the road forks if you were going the other way" in terms of structure of risk? The above mentioned "disassembling equipment" falls into this category. So does pulling out a bookmark, and shuffling a sorted deskfull of papers. Think of some others. This is when it pays to write things down or otherwise figure out how you're going to put things back the way they were.

• installations, upgrades and other maintenance

  Do I have to even mention this? Most of the horror stories I hear from newbies — as well as from the customer support people who newbies call when they get into trouble — concern loss of files and/or setting after a hardware or software upgrade or maintenance. Back up first. If you have stealth Information Technology (IT) staff who give you surprise upgrades in the dead of night, back up every day, even if it's just copying files changed in the last work day onto a floppy disk.

  Tech Tip: No one's files and settings are safe during any kind of maintenance or upgrade.

{2.15.6} Stay Cynical

When there's a bluebird singing on your window pane,
And the sun shines bright the whole day through,
Don't forget, boy, look over you shoulder,
'Cause you'll find that someone's coming after you.
— Alan Price, Look Over Your Shoulder, from
      O Lucky Man (1973, music album) [ASIN: B000002KEW]

In the postmodern play Rosencrantz & Guildenstern Are Dead (1967) [ISBN/ASIN: 0802132758] by Tom Stoppard, the two main characters observe a series of coin flips always favoring one player in a simple gambling game, way beyond the predictions of common sense or probability theory, and get mighty close to concluding that they are characters in a play. Now I don't advocate that level of paranoia, but healthy skepticism is vital to risk management. If I saw a coin come up heads a thousand times, I would not, as the textbooks suggest, be assured that the odds of tails are still 50%, nor would I think — as the public seems to — that the odds of tails are now much higher, because by the "law of averages" it is bound to come up tails soon. (By the way, there is no such mathematical law.) No, I would recall that I've seen two-headed coins for sale in joke and magic shops, and assume that I was dealing with one now, so the odds of heads is most likely 100% with this coin.

You see, in addition to the naiveté of the proletariat or "rube" who believes in the "law of averages," there is also the naiveté of the ivory tower academic who believes in fair coins. The realists believes in deliberate deception of humans by other humans.

Here are ways to protect yourself:

• Never underestimate the combined destructive power of bad luck, stupidity and fraud.

  Every now and then I hear someone say, "I can't imagine what could happen." I cringe at this. Hey, if you're imagination isn't so good, ask somebody older who's done the same job for many more years. "What could go wrong?" You'll get quite a list. There was even a comedy movie a few years back with a title that asked the rhetorical question, What's the Worst that Could Happen?.

  As I've said before, you need to think like a "devil's advocate." Think of ways to deliberately screw people up. Here's an example: someone is responsible for a trade show computer and its software demo. If you can get to the computer and create two boot partitions on the disk, put a good copy of the demo on the alternate partition, then put a broken copy of the demo on the main partition. Make sure it is broken in the way that is most difficult to diagnose and fix that you know of (like an putting in old version of a system DLL file that causes severe bugs). Now, at the office, boot to the alternate partition and show your victim the working demo. Power down and put it in a crate for shipment. When they get there, they will boot to the main partition and find a broken demo. They will waste a lot of time looking for a hardware cause, because they "know" the software is okay — they saw it working. Only the shipping has happened since, which can usually only break hardware.

  I know this sounds very mean, and I hope none of you out there in readerland ever have a heart so dark you would do this to someone, but here is the vital question: What would you do if you were the target of this action? How would you defend yourself?

  Also, remember that the worst that could happen is not just random bad fortune, like a hurricane, or stupidity, like hooking up an electric fence for extremely dangerous animals so it is controlled by an experimental prototype supercomputer, or even just larceny, like deliberate sabotage as a cover for industrial espionage, but that "perfect storm" which is the combination of bad fortune, stupidity, and attempted scam. Novelist Michael Crichton seems to have a special knack for thinking up and describing these scenarios; one of the best is in Jurassic Park (1990) [ISBN/ASIN: 0345370775], in which the three factors I just described combine to result in deadly carnivorous dinosaurs roaming the island where the owner's grandchildren are lost during gale force rains and wind. (The Andromeda Strain (1970) [ISBN/ASIN: 0060541814] is also very good; is is structured around a congressional investigation into all the things that went wrong in an attempt to find bacteria in space that could be used for germ warfare on earth.)

• Study the mathematics and psychology of gambling (and cheating).

  While going to college in California, I feel fortunate that I studied probability theory in some detail before I was 21 years old and could legally gamble in the nearby state of Nevada. In fact, I was in the middle of a probability theory class the first time I visited a casino; I was only 19 and couldn't play the games, but I figured out the odds for a few of them as an exercise. The one that amazed me was Keno. The player's odds are really bad. The game seems simple but the process of computing the odds can be complex and subtle. Out of of a pool of eighty ping pong balls numbered 1 through 80, the player predicts some numbers will come up, making from one to fifteen predictions by marking a Keno card with a crayon. Then the house draws twenty of the eighty balls out of a fishbowl. A payout table based on the number of predictions the player made, the number correctly guessed and the amount bet tells the player what they won. Sitting with a Keno payout table I worked out that the best bet on the board was one prediction. Betting a dollar each time, you expected value (in most casinos) is eighty cents, i.e., losing an average of 20 cents per game. Actually, to be complete, the best bet is not to bet, with an expected value of losing zero dollars every game. But from one prediction the expected value goes down with each additional prediction, with the abysmal odds being when you guess fifteen. I think the psychology at work here is that is seems to the casual observer that more guesses would make better odds, but with more guesses you haven to get more right to win, and those odds quickly approach the astronomically small. I calculated odds for the largest payouts, 15 out of 15 predictions right, which often paid many tens of thousands of dollars. The odds were so small that I didn't think the casino had ever needed to pay them out.

  Here's the math. For a more more complete discussion see the essay GAMBLING ODDS at mathpuzzle.com [LINK_2-125], from which I quote here:

  Keno ... can be analyzed by looking at the Urn problem.  An urn has 2 red balls, and 6 green balls.  Four balls are drawn at random.  What are the odds of drawing both red balls?  Let red = # of red balls, green = # of green balls, draws = # of balls drawn, and need = # of red balls needed.  The Factorial (!) is a product (7! = 1*2*3*4*5*6*7 = 5040).  Note that 0! = 1.  The urn problem uses the following formula:       red!     .  *           green!            .  *             draws!         .  * ((red + green) - draws)! (red - need)!   (green - (draws - need))!   (draws - need)! need!   (red + green)! # of red events   # of green events   # of combinations   1 / # of events For 2 red, 6 green, 4 draws, and 2 red balls needed, the odds are 3/14.  Pretty easy, once you know the formula.  Now we can analyze a few games. In Keno, you have a grid of 80 numbers.  You choose 20 of them.  Then, 20 numbers are picked at random.  If enough numbers match yours, you win a prize.  This is equivalent to 20 red balls, 60 green, 20 draws, and a variable need.  If you need to match 10 numbers, you'll win approximately once out of every 254 games.  You can see a list of Keno odds here [LINK_2-126], or you can use the formula to calculate them yourself.

  Setting red = 15, green = 65, draws = 20 and need to 15, I began to work out the arithmetic. However, there's a problem: the numbers explode. For example, the denominator in the last expression of the four, (red + green)! is eighty factorial, which is about 7.1596 times 10 to the 118th power, a number far larger than the number of atoms in the universe, and also much larger than a standard pocket calculator can compute. But by factoring and carefully choosing the order in which multiplication and division is done, you can tease an answer out of a calculator: odds of about one in 3,904,146,903,937.5 or about one in 3.9 trillion (American style). If you played a new Keno game once a second, 24/7, you'd expect to win this payout every 123,717 years. A casino open fifty years at this rate with an average of hundred players per game would still most likely have never paid the biggest prize.

  Something I've observed in Keno players is that if someone bets five and gets four of them right (with a typical payout of $15 for 4 out of 5 right, and $50 for 5 out of 5 right), they will often say "I almost won $50!" Yet the odds of getting 4 out of 5 are about 1 in 82, while the odds against getting 5 in 5 are about 1 in 1550, about nineteen times bigger (though you only win a little more than 3 times as much). If someone showed you a "wheel of fortune" divided into nineteen pie slices (which is more than the twelve numbers on a clock, so each slice would be thinner than an hour's share of the twelve) and you bet on a number but a totally different number came up, you would hardly say "I was so close!" But to the average Keno player the subjective impression in failing to beat the nineteen-to-one odds is that they "almost" won. (For most gamblers, if they had all the money they'd almost won, they could retire.)

  This is the crux of the gambling illusion. Winnings and "almost" won money combine to grow in the mind, while losses dwindle in memory. I have found most heavy gamblers "feel" like they're winning, and can't quite explain why their money has evaporated.

  The deadly emotional association to make is to feel like you're "good" or "smart" or "a winner" when you win (or almost win). I'm here to tell you right now that if you take stupid risks and it happens on a specific occasion to work out in your favor, you're still behaving stupidly. A lucky accident doesn't change that at all. (If you resist this notion, think of extreme examples. If you bet you life and your family against a million dollars on a coin toss, and won, would that prove you were smart?)

  Here is some suggested reading on probability and psychology:

  • Beyond Freedom and Dignity (1971) by B. F. Skinner [ISBN/ASIN: 0872206270]

    "The Pigeon Man" almost single-handedly invented Experimental Psychology, following in the footsteps of Pavlov ("The Dog Man") to look at voluntary instead of involuntary responses. Skinner once bragged in an interview in the Saturday Review (in 1972) that he knew how to make slot machines even more addictive, but he was too socially conscious to say how. I can't imagine what could be done; they already match his model of "random reinforcement" very closely.

  • Schaum's Outline of Probability and Statistics (2000) by Murray R. Spiegel [ISBN/ASIN: 0071350047]

    Learn the math itself, so you'll know what the odds are of drawing to an inside straight in poker.

    Interestingly, probability theory was invented by Laplace to help his friends figure out how to divide up the money when a gambling game was interrupted before it was finished.

  • Gambling and Gambling Devices (1912) by John Philip Quinn [ISBN/ASIN: 0870190172]

    This combination sermon against gambling and historical record of early gambling and cheating devices is a harsh reminder of how sneaky people can be.

• Study the mathematics and psychology of financial markets (and fraud in them).

  Perhaps the biggest reason not to gamble in regular Las Vegas style casino games is that it's really pretty hard to win or lose a fortune there, so whether your agenda is jackpot or ruin, it can be long, hard work to even approach your goal. (Of course if you are a "high roller" and can play in the high-stakes private rooms you can speed up the process of losing a fortune.)

  The real high-stakes gambling is found at the Chicago Board of Trade, in the options markets. Financial instruments invented to help hedge commercial risks can be used in instead to take the biggest gambles in the world. I recommend learning about this world, and the fickle and hysterical behavior of markets, and the history of investment scams, as a tonic against being seduced by this form of legal, high-stakes gambling.

  Learn about why Warren Buffet says the market is manic-depressive, why Andrew Carnegie got out of the market a few months before the crash of 1929 because he got a stock tip from a shoeshine boy, and why bond salesmen thrive on the stupidity of bond buyers. Learn about the tulip bulb bubble of the 1600s. Go to a news search engine like Google News [LINK_2-130] and look up the Enron and Merrill Lynch scandals. Research the work of Daniel Kahneman, whose work in "Behavioral Finance" won him the 2002 Nobel Prize in Economics.

  Here is some suggested reading on financial markets:

  • Where Are the Customer's Yachts? or A Good Hard Look at Wall Street (1940) by Fred Schwed [ISBN/ASIN: 0471119784]

    With a writing style as funny as Mark Twain's, Schwed points out that prices don't "move" the way a baseball does — a baseball moves continuously through space, while a price jumps from one number to another discretely (more like a quantum event, come to think of it). So it is never really accurate, he argues, to say a price is "going up" as if it had momentum like a baseball.

    These and other funny and insightful observations make this a great and educational read.

  • The Great Los Angeles Swindle: Oil, Stocks, and Scandal During the Roaring Twenties (1993) by Jules Tygiel [ISBN/ASIN: 019505489X]

    it is amazing to watch the slide of Julian Petroleum (as it moved from one owner's control to another) from quirky but honest, to questionable, to shady, to outright fraudulent, to embroiled in scandal with corporate officers on the lam. (Sound familiar?)

  • Liar's Poker: Rising Through the Wreckage on Wall Street (1990) by Michael Lewis [ISBN/ASIN: 0140143459]

    An insider's look at how legal stealing is done in the bond market.

  • The Edge of Chaos: Financial Booms, Bubbles, Crashes, and Chaos (1997) by Bernice Cohen [ISBN/ASIN: 0471969079]

    A purported look at chaos theory applied to markets it is light on math and heavy on the author's self-promotion, but still contains some remarkable cautionary tales of previous crashes. This book helped keep me out of the NASDAQ crash of 2000.

• Study the history and techniques of stage magic and confidence games.

  When physicists set out to investigate claims of the paranormal — psychic phenomena such as Extrasensory Perception (ESP) and telekinesis — they are often fooled by deliberate and even blatant frauds. This is because they are used to dealing with physical nature, which is blind, unconscious and (seemingly) without its own agenda. Nature can be incredibly subtle, and require immense patience and cleverness to understand even partially, but it does not set out to deliberately mislead. When they begin dealing with potentially deceptive and manipulative humans, these same physicists are often easy marks, because they are out of their area of expertise. Over time these scientists have found that they must include stage magicians in their research teams, because they are experts in the varieties and technologies of misdirection.

  Another group of experts are forensic criminologists, who very often deal with evidence that someone has tampered with or tried to hide or destroy. "Bunko" squads and insurance investigators face situations in which often very little is as it seems. These experts learn a lot about the ways people try to scam other people. But, as P. T. Barnum said, "There's a sucker born every minute." Con artists have no shortage of new, naive victims, and so most scams follow a simple, classic structure.

  In John Philip Quinn 's 1912 book on gambling devices mentioned above he devotes a whole chapter to an old "con" called the "gold brick fraud." It illustrates the classic structure well. The "Mark" is a man of means, who can lay his hands on a large sum of money without having to apply for a loan, which might lead to difficult inquiries by his banker. He is conned by a team of three: the Miner, the Indian and the Trailer. For props they require the Mark's name written on a piece of paper, a copper bar and some gold nuggets and shavings, plus a bottle to be purchased later. The Miner presents himself at the home of the Mark, using his name written on the paper as a pretext for making contact. Once the Miner determines that he has the "wrong man" he moves to make his leave, but happens to mention that he is very disappointed because "the Indian's so sick he can't tote the gold no furder." The Mark coaxes the Miner into telling his tale, of the huge gold bar the Indian discovered, and the how the Miner and the Indian have traveled far, searching for a man who they were told could turn the gold into paper money for them. The Miner shows his nuggets as proof, or possibly tries to pay for something with the nuggets. At this point the Mark's own greed takes hold, and he becomes convinced he can take advantage of the situation with these ignorant yokels (who probably don't know what the gold is really worth). After the Mark convinces the Miner to let him buy the gold, the Miner suggests that the Mark go to a drugstore and buy a bottle of acid to test the gold bar when the time comes. The Mark runs this errand, followed by the Trailer (who he has never met and never will); the Trailer buys an identical empty bottle and fills it with water. Of course when the Mark finally convinces the Miner to take him to the Indian, who is camped some distance away and too sick to go on, the bottles are switched, and the Mark uses water instead of acid to test a copper bar and concludes that is gold. He can also be given some gold shavings which he may have tested later without a problem. Ultimately, the fraud concludes when the Mark "rips off" the Miner and the Indian by underpaying them for their "gold" bar, only to find later that he is left as the victim and not the thief.

  This same structure can be seen in the now notorious "419" email scams purporting to come from places like Nigeria, South Africa, Lagos, the Congo Republic and so on, claiming to have millions of dollars that need to be transferred to a U.S. bank. Do a web search for "419 scam" and you will find a number of government and individual web sites fighting this scam. But there is no stopping it, because there is a sucker born every minute.

  Here is some suggested reading on deception:

  • The Magic Man; the Life of Robert-Houdin (1972) by I. G. Edmonds [ISBN/ASIN: 0840761465]

    When you see an archetypal "magician," say in the original Industrial Light and Magic (ILM) logo (as seen on Wikipedia [LINK_2-135]), you are seeing the image created by French magician Robert-Houdin for his stage persona. (Later American escape-artist Harry Houdini appropriated a portion of the name.)

    Robert-Houdin once performed an astonishing illusion at a party hosted at the ancestral estate of a royal personage. The magician borrowed a ring and made it vanish. Then he sent a footman to dig up a clay pot buried near the gate post of the estate. He continued with other illusions until the footman, still dirty from digging, returned with a soiled clay pot. Breaking it open, Robert-Houdin produced a decrepit packet sealed with wax. He asked the host if the seal was his family seal; the host confirmed that it was. Breaking the seal, the magician produced the ring and a letter from one of the host's ancestors from the previous century, declaring that he had buried the packet in anticipation of a magic trick by the great magician Robert-Houdin one hundred years hence.

    Of course the party guests were enthralled. How could such a thing be done? Well, the simplest explanation was that the host and his footman were in on the trick. The host provided the seal, the footman returned with a pot (he didn't even have to dig the hole). All Robert-Houdin had to do was make the ring vanish and then palm it to pretend to pull it out of the packet later. The host's motivation is that he gets to have his guests thoroughly entertained; the footman of course is following orders. Just like a criminologist, we are looking for means, motive and opportunity. Who had the means and an opportunity? What might their motive be?

  • The Art of Deception: Controlling the Human Element of Security (2002) by Kevin D. Mitnick and William L. Simon [ISBN/ASIN: 076454280X]

    A chilling read indeed, this guide to "social engineering" shows how easy it is for a "bad guy" to use incremental bits of information to achieve the appearance (or authoritative sound) of someone they're not, in order to gain information or work mischief. And 90% of problems would be prevented by saying, "Let me get your number and call you back."

  Another way to learn the classic structure of a "con" is to watch the movie The Sting (1973) [ASIN: 0783225873], with Robert Redford and Paul Newman.

{2.15.7} Resist the Urge to Hurl Yourself Into the Abyss

Can I confess something?

I tell you this because, as an artist I think you'll understand.

Sometimes when I'm driving, on the road at night, I see two headlights coming toward me, fast, I have a sudden impulse to turn the wheel quickly, head-on into the oncoming car. I can anticipate the explosion, the sound of the shattering glass the flames, rising out of the flowing gasoline.

— character of Annie's brother Duane (played by Christopher Walken) in
      Annie Hall (1977, movie) [ASIN: 6304907729] written by Woody Allen

I have observed that self-destructive or self-defeating tendencies come in two varieties: acute and chronic. People with acute self-defeating tendencies don't usually get hired in high-tech. They don't manage to write good resumes, they're late to job interviews, they make so many obvious mistakes that nobody even thinks of trusting them with an important job.

By contrast, people with chronic self-defeating tendencies often get into positions of responsibility, only to "flame out" when the stakes get too high or the stress gets too great or the job gets too boring, or whatever their trigger is for self-destructive impulse.

I have found that the ability to resist self-defeating impulses is a vital skill in managing risk in your career. Here are some specifics to avoid:

• Pranks.

  Techies love pranks and they are a venerable tradition. But a little goes a long way. A great prank has a certain structure, like the best episodes of the old Twilight Zone [ASIN: B0000714AP] TV show from the early 1960s. The victim must be propelled by a character flaw into their predicament. If on this occasion they were to act out of character and not exhibit the flaw, the prank should fail.

  A simple example: Most joke shops will sell you a nail with a nickel welded to the head. You drive the nail into a counter or floor. When someone comes along and tries to pick up the nickel, they either quickly give up (which is rational, since it's only a nickel) or stubbornly keep trying (which is a bit obsessive). The more obsessive and stubborn a person is, the more entertaining it is to watch them try to pick up the nickel. This prank succeeds best on misers and fails most thoroughly on monks who have taken a vow of poverty.

  If you have any doubts about a prank, don't do it. Find another way to have fun. And remember, the greatest of pranks also are, and remain, anonymous.

• Cracking.

  Computer security is often laughable. It is a techie tradition to "test" computer security mechanisms by attempting to "crack" them. Believe it or not, when I was starting out in my career unauthorized computer access wasn't illegal. In the 1980s laws were passed, and then the 1990s more draconian laws were passed, and then after 9/11 unbelievably harsh laws were passed. So the stakes are higher now.

  Perhaps I was fortunate, in that back before I could've ended up in Federal prison I tried my hand at "cracking" the security of a minicomputer system in the 1970s, within the company I worked for. It was trivially easy to break in, but proved harder to cover my tracks. I was caught, and my boss gave me an interesting speech. "Have you noticed these desks have locks?" he asked. "They're pretty flimsy. It's not hard to jiggle them open without the key, if you rattle the desk drawer right. And yet none of us here go around breaking into each other's desks. Why is that?" Of course, the answer is that it's a matter of mutual respect and professional etiquette. This is why you shouldn't be cracking any systems — plus the Patriot Act of 2001, which makes it a terrorist act to guess someone's password.

• Wing walking.

  Some foolish people show off at wok by doing risky things and getting away with it. They hot swap cables, or patch code they haven't backed up, or use unproven technology, or try to troubleshoot overly-complicated setups which have too many simultaneous variables, or otherwise set themselves up for failure by a blatant lack of caution. Don't be impressed, and don't emulate them. Maybe I should say, "Don't try this at work." If the managers and sales people figure out you're doing acrobatics without a net, they'll stop trusting you to get the job done.

• Blurting things out.
  Samson slew 1,000 Philistines with the jawbone of an ass, and more than that many sales have been killed with the same weapon!
  — American business proverb

  It is vital that you learn not to blurt things out. What seems like an innocent remark while it's in your brain may "come out wrong," and sound surly, or sarcastic, or whiney, or tend to cast a customer in a bad light, or disparage your company's products. Think about what you're going to say from all sides. Native American leaders conducting tribal meetings sometimes ask their members to "speak with good purpose." You should do the same.

  One of the things I especially recommend you don't blurt out in a work situation is, "I find you very attractive."

  Make sure you don't blurt things out in emails either. As a general rule, I only use email to convey information like dates, addresses, URLs, etc., and to ask for specific information. When I want to complain or confront or ask or beg or any other communication with an emotional component, I don't use email. If you're not sure, send it later when you've calmed down.

• Hypnotic and/or seductive situations.

  Know what tempts you. If you are seduced by gambling, don't hang out in casinos. If you have a drinking problem, stay out of bars. If you have trouble keeping your marital vows, don't mingle with singles (and stay out of chat rooms). Remind yourself of what's at stake. Call home. Look at the picture of your family you carry. Shop for a loved one.

  On my honeymoon, at Niagara Falls, I found myself on the Canadian side staring down at the rapidly rushing water. Just tracking it with my eyes — which was involuntary — seemed to to be hypnotic. I was in no way depressed or unhappy, but I felt seduced. I said to my wife, "I have this urge to hurl myself into the current." This of course would mean certain death as I was swept over the falls. My wife was holding my new $600 camera, the most expensive thing I'd ever bought besides my car. She hung its strap around my neck. Suddenly I knew I wouldn't jump — I didn't want to destroy my new camera.

  Strange though this experience was, I have used it many times since as a metaphor in my life. When you feel seduced, reach out to and connect with something you value, as an anchor. It will help keep you grounded.

The bottom line is that business and personal drama don't mix. Move your drama elsewhere in your life if you must. Try to get dates with celebrities, or enter the Boston Marathon, or add romance to your relationship with a cruise or couple's encounter weekend. Take a fire walk seminar or learn to parasail. Excitement is where you find it. But there are other people counting on you in your job. There you should be predictable, undramatic, even boring, for their sake if not yours.

Eight of Hosts You bought eight new servers for your ISP. In three months, only seven of them will be running. See if you can guess which one. That's the one you don't want to configure as your firewall. Feeling lucky? Hazard, chance. Reversed: Infant mortality. Silicon Valley Tarot © 1998, Thomas Scoville.

{2.16} WHEN IT PAYS TO PLAY

In the movie War Games (1983) [ASIN: 0792838467], the Kid, who cracked a NORAD computer and accidentally started it counting down to World War III, was talking to the Old Professor, who'd designed that NORAD computer, as they tried to stop Armageddon by distracting the computer with a game of tic-tac-toe. "Can you get it to play itself?" the Kid asked. The Old Professor replied, "Number of players: zero."

That is a hacker joke. (I use the term "hacker" in its original meaning as a term of praise for a great programmer, not the media-hyped term for a "cracker.") It highlights the playfulness of the technically creative, and reminds us that it is often an essential part of the character of the techie.

Some religions ask their practitioners to "tithe," that is, donate ten per cent of their income to the church. Similarly, I like to think of paying a "tithe of consciousness," not high as ten per cent, but certainly higher than one per cent, in which I attempt to become more conscious of my habits and to critique and perhaps improve them. I have found playfulness to be an important tool in this process.

I especially find it useful to play with my tools. This is sometimes called fiddling, or goofing around, or poking around, or "frobbing the knobs." I can tell when I've been away from it too long (too many tight deadlines, too serious about my work) because in the first 15 minutes I discover a bunch of ways to save time and solve problems that I've lived with for a long time.

In Jon Bentley's essay, Cutting the Gordian Knot, described in section 2.13 "SOLVING THE RIGHT PROBLEM" earlier in this chapter, he confirms this observation. He says that among his students some of the most useful tools have been developed while playing with the capabilities of technology.

(For a theoretical basis for this approach, see Homo Ludens (1971, book) by Johan Huizinga [ISBN/ASIN: 0807046817], about humans the playing animals.)

User Friendly cartoon with an HTML hexadecimal RGB color code in the punch line [LINK_2-141]

{2.17} SHOPPING FOR TECHNOLOGY

Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy lies a small unregarded yellow sun.

Orbiting this at a distance of roughly ninety-two million miles is an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea.

— Douglas Adams, 1979
      The Hitchhiker's Guide to the Galaxy [ISBN/ASIN: 0345391802]

An early reviewer of a draft of this book complained she'd expected more in the way of reviews of the latest handheld and mobile gadgets. Now, I'm a dyed-in-the-wool techie and I love gadgets, but I'm also a technical pragmatist and so I tend to ask "what will help me do my job?"

If it's up-to-date gadget reviews you want, check my blog which you'll find at:

travelingtechie.com [LINK_0-1]

But here's the big picture: I've found you have to divide your gadgets into two categories: early tech and late tech. An early tech gadget is one from a technology that isn't ready for prime time, and you're using it because:

• you think it represents the future, so you want to get in on the ground floor

• you want to learn all about it

• let's face it, you love it

You can only afford a few of these. With me my early tech gadgets have been Personal Computers (PCs), 3-dimensional computer graphics (3D CG), Digital Video (DV) and Global Positioning System (GPS). I'm sure you have your own list.

The rest of the gadgets in your life are late tech, you have them because you need them and you want the minimum amount of nonsense from them, so you get mature technologies. I am this way about, cell phones, laptops, Personal Digital Assistants (PDAs), cars and pocket knives. Again you have your own list.

When shopping for late tech gadget, the way to proceed is the begin with the application — the solution to your problem — and work backwards to software, operating system, hardware platform and manufacturer.

When I first decided to buy a DVD player a few decades ago, I started out by getting the movie Blade Runner (1982) [ASIN: 0790729628] on DVD. I really love its opening sequence — it looks great in movie theaters and not as good on VHS video. I wanted to see where in between the DVD players fell, so I brought it with me to stores to shop for DVD players.

I gave similar advice for years to people shopping for PCs: start with the application. A few years back my sister was given the job of shopping for a computer for a police station to use. She asked my advice and so I asked her if she had to be able to read or write files from any other police station's computers — was there any compatibility requirement? She didn't know but made some inquiries, and sure enough there was a group that had worked out which hardware choice would work okay with the existing systems, and they gave her all the information she needed.

I took the same approach in the early 2000s when I was shopping for a Personal Digital Assistant (PDA), such as a Palm Pilot. The main application for me was looking up phone numbers in a hurry. For years I used a computer-generated list, but it was bulky to carry around, time-consuming to use and problematic to update. When I began carrying a laptop computer it was an improvement, but it seemed to take forever to power on and boot when I was in an airport between flights and needed to look up a number — and then I had to wait for the application to come up too! For me the big selling point of the PDAs was that they are "instant on" and they automatically go right back to the application you were running and the screen you were on when you powered off. This is what made quick phone number lookup a "killer app" for me on a PDA. I didn't need wireless access or color, so I waited until I found a bargain on a discontinued model at the Palm booth at COMDEX in 2001 (a low-attendance year due to 9/11), and I got a great deal.

(These days I use an iPhone.)

So, applying these principles forward, if it was my job to put in place a wireless order tracking program for all employees of an e-commerce web site, I would start with a small pilot project implemented several different ways, do feasibility analysis, performance analysis, and a Return on Investment (ROI) analysis, including non-recurring costs like hardware purchases and software licenses, as well as recurring costs like bandwidth and training (training is recurring because of employee-turnover) before selecting the hardware and software platforms, or even deciding if it's worth doing at all. This would drive vendors crazy, but hey, that's their problem. The alternate approach is to lock in an expensive single-vendor solution before you know if it's cost-effective, and just march off a cliff, betting your career and the company along with you. (Given what a bad idea this is, it's amazing how often it happens.)

{2.18} WATCH THAT 'TUDE, DUDE

"You'd argue with a stump."
— Call to Gus in Larry McMurtry's Lonesome Dove (1988, novel) [ISBN/ASIN: 067168390X]

The largest inland sea in North America, the Salton Sea in Imperial County, California, was created in 1905 when an irrigation project went awry. Rivers always flow downhill, and the Colorado RIver flows downhill mostly to the south and to the west — through a vast expanse of the American southwest — until it empties into the Pacific Ocean through the Gulf of California. But the last stretch of river bed has been lifted up by geological activity until it is above a nearby below-sea-level "sink" to the west, which used to be called the "Salton Sink." If the river managed to jump its banks and "hang a right" near Yuma, it would begin to fill this sink. (In fact this has happened a number of times over hundreds of thousands of years according to the geological record, but the water had no way to drain and eventually the river returned to its course to the Pacific, leaving the inland sea to evaporate in the desert heat.)

Realizing this geological arrangement presented an opportunity for irrigation on a vast scale, an entrepreneur named George Chaffey, and his chief engineer Charles R. Rockwood, formed the California Development Company. They eventually began to irrigate the Imperial Valley — as they named it — with Colorado River water through a network of canals, which took water out of the Colorado in the US, ran into Mexico for a ways and then back into the US to fan out and distribute the water to farms. After they'd accumulated a bunch of paying customers their canal silted up where it branched off from the Colorado. They encountered legal obstacles to dredging the canal in the US and so decided to make a new cut in the river in Mexico. A mixup in communications lead the company to think it had permission from the Mexican government, and the cut was made in September of 1904. But permission was not granted, and the company was prevented from installing a floodgate at the cut.

In recorded history this river only flooded about once in every seven years, and never more than once a year, but in 1905 it flooded three times, and the third flood expanded the cut to 160 feet wide, flowing into a quarter-mile-wide channel followed by a 28-foot waterfall, ending in the filling of the Salton Sea. The California Development Company, lacking the resources to solve the problem, went bankrupt, the farmers were flooded out, and inland sea continued to rise until it threatened the tracks of the Southern Pacific Railroad, which eventually stopped the flooding by dumping rail cars full of gravel into the cut for weeks until the water stopped flowing out through it.

The cutting of the Colorado in Mexico without a flood-gate surely qualifies as one of the greatest acts of folly in the history of American businesses that work with technology. In one version of these events, the engineer Rockwood refused to make the cut in Mexico and financier Chaffey did it himself. I find myself hoping the story of Rockwell's refusal was true, because I like to think there are engineering heroes out there who will refuse to be the instrument of their company's destruction. This is a type of engineering orneriness that I consider good orneriness.

All the rest is bad orneriness. Sometimes people get the idea that it is a symbol of status to be hard on those around you, because it proves you must be really good at what you do or else they wouldn't put up with you. I say this is horse exhaust. The pain in the neck people are the first to go in a downsizing. They're too hard on everyone else's morale. Consider the fates of Michael Ovitz and Steven Spielberg. Ovitz used to head the most powerful agency in Hollywood, Creative Artists Agency (CAA), and was one of the meanest S.O.B.s in town. Everyone feared and despised him. Spielberg was a director with a few big hits, which gave him some clout, but everyone said he was the nicest guy and the greatest person to work for. Today, thanks to a series of finagles involving the Walt Disney Company, Ovitz is totally without power in Hollywood — despised but no longer feared — and Spielberg is part owner of his own Studio, the "S" in "Dreamworks SKG," which seemed to have vanished but then was reconstituted with investment from India. (For a good account of some of this tale see the 2001 book Keys to the Kingdom, the Rise of Michael Eisner and the Fall of Everybody Else by Kim Masters [ISBN/ASIN: 0066621097] .)

One more point about bad orneriness: you can't get away with it indefinitely; people eventually expect you to "shape up or ship out." When wolves are cubs they can wander where they want in and around the den, ignoring the territory marks of adult males, and will not be harassed. But once they show that they know where the boundary marks are, the puppies are no longer allowed to ignore them: the adult males begin defending them with gusto. There is no going back for the puppy. It has been my experience that high-ranking managers and others in a company treat individual techies similarly. Once you show that you know your bad habits are disrespectful, they are no longer tolerated.

Flame War Two pedants, locked in mortal combat, scorch each other with fiery words. Angry, aggrieved, they wield their righteous furies in rhetorical joust. Insult, invective, profanity - they will stop at nothing until one or the other is humiliated or banished. Quibbling, hair-splitting, dogmatism, nitpicking. Reversed: discord, misunderstanding, misinformation, mistaken opinion, perfectionism. Silicon Valley Tarot © 1998, Thomas Scoville.

{2.19} GIVE SOMETHING BACK

...the impulse to keep to yourself what you have learned is not only shameful, it is destructive. Anything you do not give freely and abundantly is lost to you. You open your safe and find ashes.
— Annie Dillard, 1989
      The Writing Life [ISBN/ASIN: 0060919884]

As you wend your way through the world of the traveling techie, your mistakes will teach you; make enough of them and be receptive enough and they may teach you some wisdom. At first you may not notice it; things will just go better for you. But when you realize you have achieved some mastery in an area, you have a duty to share your knowledge. Think about about all the people — those you've known and those you haven't — who've helped you. Then, "pay it forward" by helping others. Here are some ways to do that:

• write journal articles

  Get approval from your company's engineering and marketing department. The best topic is a real customer implementation, with problems encountered and solved. Find a customer who is willing to work with you. This will help your users, your company, and your own career. (Be sure to list all publications on your resume.)

• speak at conferences

  These have less prestige than journals but are more fun and educational: you get to travel and meet people and learn from other sessions. It's also easier to get accepted. Use the same type of topics as for journal articles. List these too on your resume.

• volunteer at conferences

  Speaking of conferences, many of these are nonprofit and volunteer run, dedicated to spreading useful information about technology. Volunteering is a great way to meet people, to learn, and to get in free to events. You can also create goodwill for your company if they support your volunteering efforts (e.g., with time off, contributions, resources, sponsorship, etc.). Be sure that your company gets good publicity for anything it contributes.

• post information on the web

  You can use a web site to give away free information to help others, and also to publicize yourself, promote your career, and you can even build a small business around it. See Multiple Streams of Internet Income (2002, book) by Robert Allen [ISBN/ASIN: 047121888X] for information on how to do this. The key thing about the web is that the incremental cost of distributing information is almost too cheap to meter.

• write a regular blog or e-Zine

  A web log, or "blog," is just a journal you post where web browsers can find it. Many sites and software packages are available to make it easy to keep a blog. Two of the most popular are blogger.com [LINK_2-146] and wordpress.org [LINK_2-147].

  The jargon term "e-Zine" is short for "electronic magazine," but it's really just an email newsletter. It can be a lot of work, but if you love the topic it can be very rewarding. People will send you the most amazing stuff. I have my own e-Zine called Cybernetics in the Third Millennium (C3M). (See A Curriculum for Cybernetics and Systems Theory [LINK_2-148] to subscribe.)

• write a pamphlet

  My dad is a fan of the long-gone General Motors (GM) models known as Corvairs, and has been active for years in local and national Corvair Clubs. These aficionados must scavenge junkyards for parts to keep these half-a-century-old cars running. Determining which parts will work will work on which models is a daunting task, and requires checking dates and serial numbers against lengthy lists. My dad decided to do something to help junkyard scavengers, and produced a pamphlet called The Corvair Junkyard Primer [LINK_2-149], which has all the data you need in a pocket-sized pamphlet. It's helped pay for his hobby (some years more than others) and helped a lot of people poking around junkyards for Corvair parts. (The project also got him into the world of Macintosh computers, Postscript files and laser printers.)

• contribute labor to open source projects

  Such modern wonders as Linux, GNU's C++ compiler, the Apache web server — even the software for Domain Name Service (DNS) that we all use (mostly without knowing it) to covert a web site name like www.tinaja.com to an Internet Protocol (IP) address like 65.254.248.195 so we can look at web pages from that host — these all are made possible by the open source movement. Volunteers contribute free source code, or else spend time testing, debugging, porting, tuning, and otherwise spreading the fruits of the open source movement. For starters find out more at Opensource.org [LINK_2-150].

• be a mentor

  About twenty years ago, when Virtual Reality (VR) and scientific visualization ("sciviz") were hot new things, I met a bunch of VR and sciviz pioneers at a computer graphics conference and I did an informal survey, asking them what inspired them to go into computer graphics in the first place. A few things like educational films and TV shows were mentioned (Walt Disney's 1959 cartoon Donald in Mathmagic Land [ASIN: 6301017129] was the most frequently named) but the number one influence was a special teacher or other interested adult who acted as a mentor. A mentor is more than a teacher: they believe in the student and encourage them to develop their talents.

  Was there someone like this for you? Then "pay it forward." Mentor a talented student. Tutor them in what you have learned. Encourage them to develop their talents. Don't break the chain.

{2.20} AN ETHICAL FRAMEWORK FOR TECHNOLOGY

"Technology without morality is barbarous; morality without technology is impotent."
— Freeman Dyson, 1988
      Infinite in All Directions [ISBN/ASIN: 0060915692]

Inventor, philosopher, architect and "friendly genius" Bucky Fuller gave me the best definition of wealth I have ever encountered:

the number of forward days of human life support

A military cargo plane filled with Meals Ready-to-Eat (MREs) is wealth. The primary "fount" of wealth creation is the miracle of agriculture: the sun's energy ensnared by plants in a form we can use to survive. But our wealth is compounded by our technological advances. If a telegraph can warn farmers of advancing severe storms and they can bring in their crops before they are ruined, this adds to our wealth. If a single, small satellite can do the work of a huge, fragile undersea cable, this adds to our wealth. Bucky called this ongoing process of doing more with less "ephemeralization." The most dramatic example is our ongoing breakthroughs in integrated circuits, but throughout our technological civilization we are figuring out how to do more with less mass and less energy, often by applying more miniaturized information. To the degree that this increases our life support capabilities, this benefits all humans.

{2.20.1} Computers For the People

Being afraid of monolithic organizations especially when they have computers, is like being afraid of really big gorillas especially when they are on fire.
— Bruce Sterling, 26 March 1994
      address at Computers, Freedom and Privacy Conference IV

{2.20.2} Creating Value

Work hard at your job and you can make a living. Work hard on yourself and you can make a fortune.
— Jim Rohn, motivational speaker
      The Art of Exceptional Living (1994, audio cassette) [ASIN: 0671505882]

How we fit in to this as individuals? Most of us are off chasing money, the way a bee chases honey. (Bucky was fond of pointing out that the bee isn't even aware it is pollinating the flower, it is only after the nectar.) But I've found you can't ignore money entirely. The cost is an integral part of any technology, determining what applications it can be used for. What I have found works for me is to look in the opposite direction of money flow, at value flow. How much value is flowing where? If your company is paying you $X per year (and probably close to twice that in total payroll costs), then you must be creating much more than that much value for them — otherwise they could not afford you.

I remember when Disney CEO Michael Eisner was getting so much flack in the mid-1990s about his hundreds of millions of dollars in compensation. (This was when his bonus was based on stock price increase, before he packed the board.) Some people argued that there was no way any executive could be said to "earn" that much money. But he did in fact create hundreds of times more value for the stockholders. You should've seen the company before Eisner took it over. Card Walker, a former company operations man, good at keeping the lights on but no visionary, almost ran it into the ground, until its stock value was below the value of its real estate and film library holdings alone, and corporate raiders in the 1980s were circling, eager to chop it up and sell it off. Eisner saved the company and built it into the largest entertainment empire in the world in his first decade as CEO. I'd say he earned his keep then. (Later on, not so much.)

Likewise you should focus on the value you are creating: the design and implementation work you do that enables and empowers others, the information you share which helps others create more value, the revenue you help bring into the company, the positive publicity, reputation and brand enhancement you help foster, and the morale you help to boost.

{2.20.3} The Case for Progress

"...my father replies that we are made to live here. We need air to breathe, water to drink, we suffocate without air and water: so why go (into space)?"

"For the same reason that makes us bring children into the world. Because we're afraid of death and darkness, and because we want to see our image reflected and perpetuated to immortality. We don't want to die, but death is there, and because it's there we give birth to children who'll give birth to other children and so on to infinity. And this way we are handed down to eternity. Don't let us forget this: that the Earth can die, explode, the Sun can go out, will go out. And if the Sun dies, if the Earth dies, if our race dies, then so will everything die that we have done up to that moment. Homer will die, Michelangelo will die, Galileo, Leonardo, Shakespeare, Einstein will die, all those will die who now are not dead because we are alive, we are thinking of them, we are carrying them within us. And then every single thing, every memory, will hurtle down into the void with us. So let us save them, let us save ourselves. Let us prepare ourselves to escape, to continue life and rebuild our cities on other planets: we shall not long be of this Earth! And if we really fear the darkness, if we really fight against it, then, for the good of all, let us take our rockets, let us get well used to the great cold and heat, the no water, the no oxygen, let us become Martians on Mars, Venusians on Venus, and when Mars and Venus die, let us go to the other solar systems, to Alpha Centauri, to wherever we manage to go, and let us forget the Earth. Let us forget our solar system and our body, the form it used to have, let us become no matter what, lichens, insects, balls of fire, no matter what, all that matters is that somehow life should continue, and the knowledge of what we were and what we did and learned: the knowledge of Homer and Michelangelo, of Galileo, Leonardo, Shakespeare, of Einstein! And the gift of life will continue." So he said, father. And to me it sounded like a most beautiful prayer....

— Ray Bradbury, as recounted by Oriana Fallaci in
      If the Sun Dies (1966, book) [ISBN/ASIN: 0689706103]
      (also on-line [LINK_2-155])

These words sum up so well the reasons for technological progress better than I could. Let me just add that humans and human civilization, our biology and our culture, could perish in many ways. Our sun can explode, returning ice ages or global warming or ozone depletion or other ecological disasters can befall us, a comet can strike and wipe us out like it did the dinosaurs (along with a whole bunch of other extinct species that don't get as good press coverage as the dinosaurs), plagues can befall us (both natural and bio-warfare agents), nearby stars can go supernova, a passing black hole can swallow us, and if the whole universe doesn't eventually implode (which is looking less likely these days) it is scheduled to endure a "heat death" due to entropy from which there seems to be no escape.

If we are to solve any and all of these problems in the long run it will be through the application of technological progress. Let's get going.

{2.21} HISTORICAL ROOTS

"History does not repeat itself, but it rhymes."
— attributed to Mark Twain

One can achieve a quick, oversimplified history of Western Civilization by following the history of snob appeal. We start with America. Though it must surely make intellectuals rage or weep, one of the most sought-after women in the world, measured by internet searches, was for quite a few years Pamela Anderson, and when she was on the syndicated TV show Baywatch (1989) [ASIN: B00000ILFP] it was number one in the world, with more than a billion viewers. This trend has continued since with other American starlets; today Scarlett Johansson of New York, NY is considered the "sexiest woman alive" by Esquire magazine, while Google says the most searched-for person last year was Whitney Houston, of Newark, NJ. So America, which is also the only super-duper power, holds a lead in terms of exporting culture in the 21st century.

But to Americans, it still remains the case that if you want to be classy, you essentially want to be English. Sooner or later the American class-seekers end up buying a castle in Ireland, or riding around on horses with English saddles, or driving Rolls Royces. When American popular movies want to seem classy they bring in Julie Andrews.

But where do the English get their class? Since the the Norman invasion of 1066 it has been de riguer in England for all things French to be classy. Virtually all of the English words for luxuries and fashion come from French roots, not the native Anglo-Saxon.

But the French based their notions of civilization and empire on the Romans. It was quid pro quo that the important ideas, and even words, came from the Latin. French is called a Romance Language because of all its borrowed Latin.

And of course the Romans got all their classy ideas from the Greeks. The entire ethos of higher education in Roman society came from Greek philosophers and the Greek language.

But prior to the Roman Empire, when Athens was the dominant military power in the region, the Greeks kept alive and revered the Egyptian mystery religion, in the form of the Oracle Centers throughout the Mediterranean. (This was the type of Oracle visited by Oedipus.)

Beyond this point we come a chain of empires of varying fame: the Persians, the Assyrians, the Phoenicians, the Hittites, the Babylonians, the Akkadians, the Sumerians, etc. (A detailed inventory is in Isaac Asimov's 1968 book The Near East; 10,000 Years of History [ISBN/ASIN: 0395065623].) Each tried to outdo the previous one, while borrowing their biggest ideas and some of their language. And so ancient empires gave us the seven day week and 360 degree circles.

Now let us run this history forward again and look at the evolution of the technician. From the derivation in the American Heritage Dictionary that began this chapter, we learn that "technique" once meant being good at weaving and fashioning stuff with an ax, and making wicker or wattle fabric to cover mud walls. Presumably just about anybody could pressed into slavery to make bricks, and then pile them up with mortar to make walls, but it took some kind of specialist to cover the mud with good wattle.

This suggests the beginning of a middle class, a trade or guild class wedged between rulers and laborers, though up through the Greeks this merely represented a category of "slaves with skills." Then the Romans conquered the Greek city-states and began making literate, well-educated Greek citizens into slaves.

These slaves, who had read Greek philosophers (the closest thing they had to scientists) on the nature of water, designed pumps so they wouldn't have to carry water. The Romans were impressed and began to learn from them. Civil and military engineering were pretty much born at this point. The combination of literacy and having to get a job done produced spectacular results.

But Rome fell. The dark ages for the West represented a time when only religious clerics could read and write, and society fell back into entirely oral traditions in technology.

The next big shift occurred in the 13th Century. It is described in a collection of essays on the history of technology by Lynn White, Jr., called Dynamo and Virgin Reconsidered (1969, book) [ISBN/ASIN: 0262730243]. He tells how the Benedictine monks were ordered to pray by laboring. The had to do manual labor as a form of religious worship. This included hauling water in buckets for their gardens. They could read and write, however, and they had some of these old Latin and Greek documents on how to make pumps laying around, and so they reinvented the windmill, and began using wind power to pump water. (As long as illiterate peasants were the only ones who had to carry water, these innovations didn't happen.)

This lit the fuse for the Industrial Revolution, which evolved through wind power, water power, steam power, diesel power and finally nuclear power. (Ironically we are now in the process in some areas of switching from nuclear to wind.)

But if you look aboard a modern military submarine, or in the organization chart of a modern aerospace company, you will find the same set of class-determined job roles that were found on a British man-o-war during the time of Admiral Nelson: commissioned officers or executives, who are the ruling aristocracy and manage abstractly, noncommissioned officers or technical professionals, who make everything work by managing the technical details, and the sailors or factory workers who operate the machines to get the work done.

In the satirical science fiction novel The Hitchhiker's Guide to the Galaxy (1979) by Douglas Adams [ISBN/ASIN: 0345391802] , a planet decides to get rid of its useless people (it's middle managers, marketing consultants and telephone sanitizers) and so a phony emergency is concocted, and they are told the planet is being evacuated. All of the scientists and engineers are going on one space ship, all the workers on another, and the third ship will be the middle managers, marketing consultants, and telephone sanitizers, whose ship just happens to be launched first. (Unfortunately, the planet was later wiped out by a plague carried by telephone handsets.)

As appealing as this prospect may sound — of ridding the world of "useless" middle management — it actually seems to me that the group that is most likely to become endangered is the workers.

In the satirical science fiction novel Player Piano (1952) by Kurt, Jr. Vonnegut [ISBN/ASIN: 0385333781], describes a high-tech future in which all of the blue collar jobs have been eliminated from industry by automation. (Certainly this is something that has been predicted for half a century, and it's slowly actually happening.) The proletariat are left to live on welfare or government make-work jobs (like the WPA in the Great Depression). Only the managers and technical professionals remain.

It seems fair to ask, will the categories be pared down again? Could there be just one class of high-tech employees? I think not, and here's why: the main discriminating factor between a manager and a professional is that a manger is loyal to the company while a professional is loyal to the profession. Both are needed. AnnaLee Saxenian described this high-tech professional culture in Regional Advantage: Culture and Competition in Silicon Valley and Route 128 (1996, book) [ISBN/ASIN: 0674753402] (Page 36. Copyright © 1994 by the President and Fellows of Harvard College. Reprinted by permission of Harvard University Press, Cambridge, MA.) :

As individuals moved from firm to firm in Silicon Valley, their paths overlapped repeatedly; a colleague today might become a customer or a competitor; today's boss could be tomorrow's subordinate. These relationships transcended sectoral and occupational boundaries. Individuals moved within and between industry sectors: from semiconductors to personal computers, or from semiconductor equipment to software. They moved from established firms to start-ups, and vice-versa. And they moved from electronics producers to service providers such as venture capital or consulting firms — and back again...

Professional loyalties and friendships generally survived the turmoil. In fact, this continual shuffling and reshuffling tended to reinforce the value of personal relationships and networks. Few presumed that the long term relationships needed for professional success would be found within the four walls of any particular company. Many came to rely on trade shows, technical conferences, and informal social gatherings to maintain and extend their professional networks.

As a result, Silicon Valley's engineers developed stronger commitments to one another and to the cause of advancing technology than to individual companies. According to a semiconductor executive who has worked in the region for three decades, "Here in Silicon Valley there's a far greater loyalty to one's craft than one's company. A company is just a vehicle which allows you to work. If you're a circuit designer it's more important for you to do excellent work. If you can't in one firm, you'll move on another one."

This kind of loyalty to the profession makes an industry strong, fosters innovation, and helps create a high-tech renaissance. But it does not ensure the survival and prosperity of the individual company, which is a fiduciary responsibility to stockholders by the corporate officers, and that's why mangers are essential as well.

Certainly the evolution of the modern techie, and of technical roles in high-tech companies, has not reached its ultimate form, and improvements will come in the future, but it does represent some of the accumulated wisdom of 10,000 years of culture.

Ace of Networks The network rises over the horizon, a new dawn of computing. Its golden rays pierce the dark clouds of stand-alone number-crunching. So-long, you stodgy, cranky legacy systems. Hello, client/server. Oh, yeah... did I mention terabytes of digitized porno, spam, and USENET flamewars, too? Auspicious beginnings. Reversed: Confusion, chaos. Silicon Valley Tarot © 1998, Thomas Scoville.

PREV UP NEXT

© 2014 Alan B. Scrivener