PREV UP NEXT

Chapter Two:
Tech

This chapter is about the magic that techies work, and how they do it. It looks at what makes a good techie, and what it takes to be a great techie, and what you can do to improve your technical abilities.

Because I am always interested in history — especially the history of technology — I was tempted to begin with a look at the history of techies: how did this specialization arise in civilization? But I though better of it, and consigned this historical perspective to the end of this chapter. (See section 2.21, "HISTORICAL ROOTS.")

If you talk frankly with managers, sales people, marketeers, and others who depend on techies, you'll find out that they sometimes view the techies they depend on as annoyances, or even as necessary evils. They also sometimes claim that "I could do that stuff if I wanted to," but it usually isn't true. (To be fair, there are a few who actually could do the job, or even have done it in the past. And there are some managers, sales folk and marketeers in small companies who are literally their own techies. More power to them. I'm just making a generalization here.)

In most cases, it takes a special kind of person to master the technology behind a high-tech company. What makes a techie different? What is it they can do that other people can't or won't?

{2.1} NO USER SERVICEABLE PARTS INSIDE

A CEO I worked for in job E liked to tell the story of how he and his hunting and fishing buddies rented a cabin on a remote island off the Maine coast every summer. They depended on an old gasoline pump to pump fresh water for the cabin, and one of the group was an automotive engineer from Detroit, and the responsibility fell to him to get the pump working shortly after they arrived. My boss said to him once, "I don't know how you do it. Every year this pump won't start, and you just sit here and fuss with this and that, and suddenly it works."

His friend replied, "I know that this pump worked once. It worked when it left the factory, and it worked when we left the island last summer. I just have to figure out what's changed since then."

Of course, the point of this story is that it is confidence in one's systematic determination to solve a problem that makes a good techie.

Once, long ago, a friend and I decided to dismantle an old television. As we began to pry the pegboard off the back, we noticed a sticker that said, "No user serviceable parts inside." My friend said, "Now's when you get to decide if you are a user." At some point every good techie has decided that he or she is not a user, but a technician.

There are ads on my TV these days that ask, "Wouldn't you like to learn to use a computer once and for all?" I laughed, because you can't learn to use a computer "once and for all." It's a constant evolution. But more significantly, you can't really learn about computers just by following directions. A good techie is the type who writes directions.

An automotive engineer will recognize that a certain pump has a design flaw, and this causes certain types of maintenance problems, and the engineer will look for these problems first. Likewise, a software engineer will recognize that certain usability problems arise when designers try to make both legacy customers and newbies happy, and the engineer will watch for confusion caused by these problems.

In either case, knowing how something is designed helps you know how to make it work and to solve problems that arise in its use.

Tech Tip:
Learn to think like
the designers.

{2.2} THE VARIETIES OF TECHNICAL EXPERIENCE

I would hope that this advice will apply to all forms of technology. My father rebuilt cars for fun growing up and later was trained by the U.S. Air Force as a jet mechanic, and went on to earn a degree in Electronic Engineering (the analog kind). He taught me about mechanical devices like gears, levers, and pulleys, and D.C. electrical circuits as a boy, and later encouraged my interest in electronics. Still, most of my experience is digital, hardware and software. I have found, however, that there are fundamental principles of technology that apply across disciplines. I will use specific examples to illustrate these general principles.

For example, a friend of mine was tutored long ago by an old techie who told him, in troubleshooting, the likelihood of problems goes:

  1. operator error
  2. mechanical failure
  3. electronics failure
  4. software problem
and he has found it true over a period of decades, working with a variety of electronic test equipment, medical equipment, and computers.

Another source of inspiration and information for me is the well-described character of the "technical representative" in James Michener's novel The Drifters (1971) [ISBN/ASIN: 0449213536] . He is an American engineer who works in places like Burma and Afghanistan, a product of the 1940s and '50s (he probably graduated high school in 1944, and is a Korean War veteran) — a good traveling companion who leaves an indelible impression on the story's narrator:

I've met a few people who reminded me of this character, and he helps me remember that there were techies with glorious traditions long before there was digital technology.

{2.3} LET'S GET TECHNICAL

But enough abstractions for now. Let's get technical, and see what happens. You can play along with me at home, if you have an internet connection and a telnet application.

Why an internet example? Because the internet is the future. That may sound funny after the dot-com crash, but every new technology (or other economic breakthrough) has a cycle of: fast boom, bust, slow boom, and the internet is now at the slow boom stage. (Virtual Reality followed this cycle, as did television, as did the economic development of the New World.) Consider, I have an appliance called a "router" that I have used to link my computers by Ethernet and have them all share an internet connection on my cable modem. It looks like this:

cover
Linksys BEFVP41 EtherFast Cable/DSL VPN Router
with 4-Port 10/100 Switch
[ASIN:
B00005Y7DQ]

It cost me a little over $100, but the original internet routers built under government contract cost hundreds of thousands of dollars apiece.

Not long ago a gadget like this would have configuration options which you would set with little switches (if you were lucky), probably DIP switches right on a circuit board that you set with a bent paper clip, or if you weren't lucky "jumper cables" — tiny little wires that you'd have to jam into tiny little sockets on the circuit board. The cool thing about this router is that you configure it through its Ethernet interface by accessing web pages. The router has its own little web server inside, and it vends the web pages for me to set all the configuration options through my favorite web browser, such as Internet Explorer or Firefox. The first page looks like this:

Never mind what a router does or what these settings mean. The point here is that in the future every device — every toaster, every thermostat, every inflatable sneaker — will have web server and let you configure it with a web browser, and it will make its connection with a wireless network that's everywhere Western Civilization reaches, and it will only add a few cents to the price of the device. You can see this juggernaut coming a long way away, because eventually it will add so much functionality at so low a cost that it will be unstoppable.

Tech Tip:
In the future,
everything will have
an IP address
and a web server.

That's why this is important. So let's take apart the link between web browser and web server and see how it works.

{2.3.1} This Isn't Rocket Science

The Tinker-Toy pieces the internet is made of are really not that complicated. There are five levels of complicated, if you ask me:

  1. stuff nobody knows how to do
  2. stuff only a few people know how to do, but it's hard for them
  3. stuff some people know how to do, and they won't tell how
  4. stuff some people know how to do, and they are eager to explain it
  5. stuff almost everybody knows how to do
The protocols of the internet are mostly at level four, despite efforts of many vendors to move it into level three. Science takes place at levels one and two, trying to move stuff down the list.

There are people who will give you information (see Request For Comment (RFC) 1945 [LINK_2-5]) and other people who will sell you information (see the 1996 book TCP/IP Illustrated, Volume 3 by W. Richard Stevens [ISBN/ASIN: 0201634953] ) about what I'm going to show you here, so it's definitely category four.

First of all, assume there is a test page at:

(which in fact there is) and that it contains the following text:


<HTML>
<HEAD>
<TITLE>test</TITLE>
</HEAD>
<BODY>
<H1>test</H1>
This is only a test.
</BODY>
</HTML>

This of course is HTML, the Hypertext Markup Language. (It's the twenty-first century, do you know HTML? If not, why not? Is it because you've been lead to believe it's complicated? If so you have been bamboozled. It's so easy that even social scientists can learn it. See the web site HTML Tutorial [LINK_2-8].)

A browser typically displays the HTML this way:

So what I'm going to do now is connect to a web server with the telnet application, one of the first utilities written for the internet. (The first test of the ARPANet — precursor to the internet — was a telnet session between UCLA and Stanford, in which someone at UCLA attempted to log in to a computer at Stanford. They had typed "LO" — the first two letters of a "LOGIN" command — when the Stanford system crashed. For more detail see Where Wizards Stay Up Late (1996, book) by Katie and Lyon, Matthew Hafner [ISBN/ASIN: 0684832674]).

Here is a schematic representation of the communication channel from me to the web server and back:

+------+  +---------+  +--------+  +----------+  +--------+  +--------+
|  me  |--| telnet  |--| socket |--| internet |--| socket |--| web    |
|      |  | program |  |        |  |          |  |        |  | server |
+------+  +---------+  +--------+  +----------+  +--------+  +--------+

Whatever I type into the telnet program gets sent to the web server, and whatever the web server returns comes back to telnet which displays it to me.

In the transcript below what I typed is in bold underlined. Now follow this session:


# (15) man telnet
Reformatting page.  Wait... done

User Commands                                           telnet(1)

NAME
     telnet - user interface to a remote system using the  TELNET
     protocol

SYNOPSIS
     telnet [ -8ELcdr ] [ -e escape_char ] [ -l user ]
          [ -n file ] [ host [ port ] ] 

DESCRIPTION
     telnet communicates with another host using the TELNET  pro-
     tocol.   If  telnet  is invoked without arguments, it enters
     command mode, indicated by  its  prompt  telnet>.   In  this
     mode, it accepts and executes its associated commands.  (See
     "TELNET Commands" below.)  If it is invoked with  arguments,
     it performs an open command with those arguments.

     Once a connection has been opened, telnet enters input mode.
     In  this  mode,  text typed is sent to the remote host.  The
     input mode entered will be either "line mode," "character at

# (16) telnet travelingtechie.com 80
Trying 72.9.137.7...
Connected to travelingtechie.com.
Escape character is '^]'.
GET
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Your browser sent a query this server could not understand.
</BODY></HTML>Connection closed by foreign host.
# (17) telnet travelingtechie.com 80
Trying 72.9.137.7...
Connected to travelingtechie.com.
Escape character is '^]'. 
GET /test.html HTTP/1.1
host: travelingtechie.com
 
HTTP/1.1 200 OK
Date: Sun, 13 Oct 2013 19:29:11 GMT
Server: Apache
Last-Modified: Wed, 25 Nov 2009 05:47:20 GMT
ETag: "352870d-64-4792b978d0a00"
Accept-Ranges: bytes
Content-Length: 100
Vary: Accept-Encoding
Content-Type: text/html

<HTML>
<HEAD>
<TITLE>test</TITLE>
</HEAD>
<BODY>
<H1>test</H1>
This is only a test.
</BODY>
</HTML>
Connection closed by foreign host.
# (18)

The above was captured while I was logged into a UNIX system running a C shell, but that's not very important. The "#" which appears repeatedly, followed by a number in parentheses, is my shell prompt; the number is a command number used in the shell history mechanism.

In command number 15, because I can't quite recall the exact syntax for the "telnet" command, I refresh my recollection by using the "man" program to get a manual entry, which I only read part of before interrupting it.

In command 16 I invoke telnet and tell it to log on to host "travelingtechie.com" using port 80 (the standard port for web servers).

I am connected and a web server silently awaits my requests. It expects them in a simple language called Hyper Text Transaction Protocol (HTTP). The letters "http" appear in every full web address, but few web users know what they mean. (The "web address" is technically known as the Universal Resource Locator, or URL.)

First I type a bad HTTP request. This is actually a mistake — I had typed the word "GET" when I inadvertently hit the return key. I left it in because it is informative. You can see the web server responds with an error message in HTML, suitable for a display in a browser, and terminates the connection. (In HTTP, the server terminates the connection after every reply.)

Then in command 17 I connect to the web server all over again, and this time I type a valid HTTP request which is three lines long (the third line being blank) and get the reply I wanted, the contents of file test.html, followed by another closed connection.

This is exactly what goes on when I use a browser to open the page, only instead of just showing me the HTML the browser interprets it and creates the attractive display I expect. Besides GET requests there are only a few other things the browser asks for: redirect requests and the dates of files (so it can decide it it's OK to use a cached copy), and the server answers with either file contents, dates, and/or new links to follow for redirects.

What about all the "special effects" you see on the web, Java and Javascript programming, Flash and Shockwave animations, Real Media, Windows Media and Quicktime videos, and so on? Well, each of those is just a file that gets sent to the browser by the web server. It's the browser's job to "make the magic happen," in other words, run the program, display the animation or show the video. All plug-ins, extensions and Active-X tricks, video streaming and GIF animation, Javascript pop-ups and changing cursor tricks happen in the browser, responding to files sent to it by the server.

The only time things get tricky for the server is when a mechanism is used in the web address such as "cgi" (the Common Gateway Interface, the protocol extending HTTP on the server side). This causes the web server to pass the HTTP request on to a program. For example, when you go the Census Bureau's "U.S. Gazetteer" at:

The "cgi-bin" in the web address causes the web server to invoke the "gazetteer" program.

The program reads the HTTP request, does whatever it thinks is appropriate (fetches from a database, sends an email, controls a Mars robot or whatever) and then creates a reply to be sent back to the browser.

When you search in the Gazetteer for the zip code 90210, you get back information on Beverly Hills, such as its 1990 population was 20,700. Look at closely this URL for Census Bureau's "U.S. Gazetteer" for zip code 90210:

The gazetteer program is being passed the arguments "city=none" and "state=none" and "zip=90210" as part of the address. Similar schemes for cramming parameters into the URL are used by other mechanisms for extending HTTP, such as "wo" for WebObjects from Apple and "asp" for Active Server Pages from Microsoft.

With what I've just shown you and the information in the links earlier in this section you can do your own experiments and learn quite a lot. (That is, assuming you can get telnet to work. See "Getting to step zero" in section 2.7 "YOUR NETWORK OF EXPERTS.")

Tech Tip:
Study protocols.

So how was that? Did you have one of these reactions?

It is my claim that a good techie will answer with something like the first two. When the covers are lifted and the secret mechanisms are revealed, you can flinch or you can stare. Techies stare.

(I said above that this isn't rocket science. Of course, there are people doing rocket science. I had a physics professor in college who said one of the most difficult problems in materials science is predicting the shapes of cracks, because each little change dramatically alters that which comes next. Nowadays, since chaos theory emerged, we would call this "sensitive dependence on initial conditions." When I traveled for job job H I met some scientists at a Department of Energy National Laboratory doing computer models of the occurrence of cracks in rocket nozzles. This was really hard science. It qualifies for level two difficulty above, stuff only a few people know how to do, but it's hard for them.)

{2.4} THE PERSONALITY OF THE TECHIE

I'm sort of sneaking up here on the question: are good techies born or made? The old nature vs. nurture, heredity vs. environment, concentrate on hiring vs. concentrate on training. Well, both, I think. A good techie must have a core set of qualities, but then also must develop them with experience and training. First I want to talk about the core qualities. These are features of the typically techie personality; if you don't have most of them then you just might not be a techie.

  1. curiosity

    A techie is almost always motivated by curiosity above all else. I recently got "spammed" with a resume from a local software engineer desperate to find a job. His language experience included FORTRAN and C. There were no object oriented languages — no C++ or Java — and no internet protocols. In fact, I didn't see any technology newer than the mid-1970s. Egads! This person was chronically under-curious. The first computer program I ever wrote was on paper, after reading a book on flow-charts at age 14. At the time our school district (of eight high schools) had one IBM mainframe and it was used to print payroll checks. Students weren't even allowed to see it. (Later I found out the Math Club got to run programs on a minicomputer at another school — I was sorry I'd missed out on that.) My point is that I learned to program with hardly any resources. Today it's easy. Software and training materials are available free in great abundance on the internet. Computers are also much more available — they can even be used for free in almost every library. (I personally in the last decade have done Java development with the latest versions of tools, as well as cutting-edge 3D graphics experiments, all on a 486-based PC that was literally rescued from a dumpster and loaded with free Linux.) So I have to ask myself, where has this guy been? How uncurious did he have to be to stop learning about programming languages 30 years ago?

    A true techie doesn't just learn things on a need-to-know basis, but mostly on a want-to-know basis. There is often a compulsive quality to a good techie's curiosity. Often by the time there is a "need to know" the information is extremely familiar, almost second nature.

    A common psychological miscalculation non-techies often make with techies is to think that money will always motivate them above all else. I've known several extremely talented techies (including me) who have traded off money for better working conditions, including more opportunities to learn and more control of the type of work done.

    This phenomenon is well-described in reporter Tracy Kidder's chronicle of a late 1970s computer engineering project, The Soul of a New Machine (1981) [ISBN/ASIN: 0316491977]. (Quoted by permission of Little, Brown and Company.) He compares the motivation of the engineers to pinball players — a pinball game doesn't give you money or prizes, just more games. Likewise the goal of the engineers is to "win replays," i.e., get more chances to design computers. After clarifying this in some detail throughout the book, he ends with this tale:

      The day after the formal announcement, Data General's famous sales force had ben introduced to the computer in New York and elsewhere. At the end of the presentation for the sales personnel in New York, the regional sales manager got up and gave his troops a pep talk.

      'What motivates people?' he asked. He answered himself, 'Ego, and money to buy things that they and their families want.'

      It was a different game now. Clearly the machine no longer belonged to its makers.

    More recently I was told by a technical manager at a National Lab that in order to get top scientific talent he had to allow them a certain percentage of their time at work (and supercomputer resources) to devote to their own research, which is to say research that interested them. This was more important than salary in attracting star contributors. More recently Google used a similar strategy, until they grew too big to stop the bean counters from canceling it.

  2. childlike qualities

    The first time I ever saw a magnetic stripe card was at a station for the Bay Area Rapid Transit (BART) system in San Francisco right after it opened in 1972. A little Japanese-looking boy about seven years old was showing an old man who looked like his elderly grandfather how to put dollar bills in a vending machine to buy a fare card for the subway. I realized then I was seeing the face of the future, both in the magnetic stripe technology and in the very young teaching the very old.

    We sometimes make the mistake of thinking of children as stupid, because they are so very ignorant and incapable, but in fact their ability to learn is far greater than an adult's. Looking only at natural language learning, their ability to absorb syntax, grammar and vocabulary is astonishing. Part of the mystery is that we talk to our children for a year or two and then they start talking back. This implies that every little interaction over those years somehow contributed incrementally to building the child's language skills, until somehow it all started happening. We have no idea how this works.

    But many techies give proof to the idea that in order to learn rapidly, especially new languages (such as technical jargon and computer languages), it helps to be childlike.

    I have heard a manager of pre-sales software engineers refer to the sales force they supported as "the adults," and the time the engineering group spent without them as "away from adult supervision." He was in fact referring to the times the group could "talk tech" freely.

    This can lead to problems. Sometimes there are negative side-effects of a childlike approach, mainly an impulse to irresponsibility. And sometimes there are perceived problems, such as when very serious, mature (dare I say "uptight") individuals, often corporate officers and finance executives, encounter the extreme playfulness that techies can sometimes manifest, and become afraid to trust them.

    And yet, most managers know that they hire techies without these qualities at their peril. To have technical staff capable of working quickly and creatively when necessary requires seeking out childlike minds.

    There is a historical trend in this direction. Our ancestors as recently as Shakespeare's time, 400 years ago, married at 14 and died at 40. Since the industrial revolution the teenager was invented, and we keep them in a juvenile state until at least 18, extending the time for education.

    My hunch is that this is all related to the principle of neoteny in evolution. The American Heritage Dictionary of the English Language: Fourth Edition (2000) [ISBN/ASIN: 0395825172] (quoted at Bartleby.com [LINK_2-14]) defines neoteny as: "retention of juvenile characteristics in the adults of a species, as among certain amphibians."

    From the 1920s to now there has been a developing theory of neoteny in humans. One of the themes is that our large brains and increased intelligence were achieved by arresting our development: our brain to body ratio is more like an embryonic ape than an adult ape. Perhaps as biotechnology sheds light on our evolutionary history we will learn more about this fascinating effect. In any case, it helps me understand why so many programmers like Legos so much.

    Tech Tip:
    Be childlike
    to maximize learning;
    be adult
    to manage responsibility.

    EVIDENCE FOR NEOTENY IN HUMANS

      To support the argument that we evolved by retaining juvenile features of our ancestors, Bolk provided lists of similarities between adult humans and juvenile apes: 'Our essential somatic properties, i.e. those which distinguish the human body form from that of other Primates, have all one feature in common, viz they are fetal conditions that have become permanent. What is a transitional stage in the ontogensis of other Primates has become a terminal stage in man' (1926a, p. 468). [Here is] an abbreviated list:

      1. Our 'flat faced' orthognathy (a phenomenon of complex cause related both to facial reduction and to the retention of juvenile flexure, reflected, for example, in the failure of the sphenoethmoidal angle to open out during ontogeny).

      2. Reduction of lack of body hair.

      3. Loss of pigmentation in skin, eyes, and hair

      4. The form of the external ear.

      5. The epicanthic (or Mongolian) eyefold.

      6. The central position of the foramen magnum (it migrates backward during the ontogeny of primates).

      7. High relative brain weight.

      8. Persistence of the cranial sutures to an advanced age.

      9. The structure of the hand and foot.

      10. The form of the pelvis.

      11. Certain variations of the tooth row and cranial sutures.

      12. Absence of brow ridges.

      13. Absence of cranial crests.

      14. Thinness of skull bones.

      15. Small teeth.

      16. Late eruption of teeth.

      17. No rotation of the big toe.

      18. Prolonged period of infantile dependency.

      19. Prolonged period of growth.

      20. Long life span.

      21. Large body size (related by Bolk, 1926c, p. 39, to retardation of ossification and retention of fetal growth rates).

      These lists ... display the extreme variation in type and importance of the basic data presented by leading supporters of human neoteny.

  3. rapid learning

    Techies are usually "a quick study," and pick things up in a snap. They have to, because there is so much to learn and usually so little time to learn it in.

    This is sometimes masked by the fact that in the United States there are regional styles of communication speed: typically, on the coasts, especially in New York, New England and California, the prevailing style is high-speed communication, while in what is sometimes called "fly over" country, especially the midwest and the south, there is more of a style of drawing things out a little, hence "the drawl." But don't be fooled. All techies must know how to learn quickly, even though they may speak slowly. Often information is presented fleetingly, with no chance to study it at length, such as in a training session or when given a demo. Once I trained a slow-talking Texan at a NASA contractor site in Houston early in my career, and I actually suspected he was brain damaged at first. But he turned out to be the top student in my class, and later I found out that when the space shuttle astronauts failed to capture the Solar Max satellite for repair in 1984, this guy was the person chosen to get on the radio with them and walk them through procedures.

    In fact, in the "hacker" community (programmers who are highly regarded for their skills — not the computer burglars the press calls "hackers"), people can become legendary for their rapid learning feats. In the summer of 1979 I was at job A when a new programmer arrived in the cube farm one Monday morning. He had never programmed the minicomputers the company was making, but in spite of that he learned the programming interface and coded a major application in an "all-nighter" Monday night and was giving demos Tuesday morning, all in his first 24 hours there. (We were all using a "line editor" originally designed for teletypes, even though we had the new CRT terminals on our desks. What this legendary hacker did was to write the first full screen editor for that minicomputer.)

    I took a page from his book when I found myself in transition from job H to job I in 1990, because two makers of minisupercomputers had merged. As a result two pre-sales technical teams were being united, and we were all assembled for training. In a short morning session we were given a quick tour of the other company's programming interface for 3D interactive graphics. Next on the agenda was a tour of the manufacturing floor of the company I'd worked for — I'd seen it many times. I stayed behind and spent the hour programming. When the group returned to the lab I had a 3D model I'd created in our format up on their graphics software. By doing this quickly, with no prior exposure to the system, I earned an reputation with the new group as a technical virtuoso, and enhanced my reputation with existing coworkers.

  4. good memory

    A long time ago, when I had my first home computer, I used to tell people that the screen was small but the world inside was huge. And that was just 48K of RAM and two floppy drives! Now, almost 35 years later, with RAM in Gigabytes, disk in Terabytes and the Internet at broadband speeds, the world inside that screen has grown gargantuan. There's a lot to keep track of these days.

    The best techies have great memories, usually from childhood. Most have memorized things for fun since they were kids, and usually they are still remembered into adulthood. I have heard techies able and eager to recite Lewis Carroll's poem The Walrus and the Carpenter, from Alice's Adventures in Wonderland (1865) [ISBN/ASIN: 0451527747] especially the stanza:

      "The time has come," the Walrus said,
      "To talk of many things:
      Of shoes—and ships — and sealing-wax —
      Of cabbages —and kings —
      And why the sea is boiling hot —
      And whether pigs have wings."

    Quite a few know the old camp song:

      Eddie cucha catcha cama, tosta nana tosta noka, samma camma wacky Brown.

    (along with many variations) about a man who drowned in a well because it took so long to say his name that it delayed his rescue.

    A popular childhood riddle known by some techies I know begins:

      When the eighth moon of Jupiter is in its elliptical phase, seldom, if ever, will an 'X' amount of wet birds fly backwards at night...

    The 1982 science fiction movie Tron [ASIN: B00005OCMR] made a techie reference to the line from the 1951 science fiction movie The Day the Earth Stood Still [ASIN: B00005JKFR] in which an earth woman had to remember this phrase in an alien language to keep a robot from disintegrating the earth:

      Gort, Klaatu birada nicto.

    Many techies in the audience chuckled at this reference.

    And speaking of disintegrating the earth, a famous Bugs Bunny cartoon has Marvin the Martian threatening to blow up the world with his:

      Illudium Q-36 Explosive Space Modulator.

    I've met quite a few techies that can quote the line verbatim, complete with the goofy Martian accent.

    An episode of the 1965 TV spy spoof Get Smart [ASIN: B00009MEH5] has the preposterous sign and countersign:

      Migrating birds fly over the sea,
      Shadeless windows admit no light,
      The wingless dove protects her nest,
      The toothless tiger rules the restless jungle.

    I know a few techies who recall this entire sequence exactly to this day.

    And many techies born in the forties or fifties remember the famous line in the science fiction movie 2001: A Space Odyssey (1968) [ASIN: B00005ASUM] when the computer, HAL 9000, says:

      Just a moment ... just a moment ... I've just picked up a fault in the AE-35 unit.

    These little details, fake technical realism if you will, seem to magnetically attract techies, who commit them to memory for the sheer delight.

    Who but a techie would memorize all of the specs of a Sopwith Camel, the World War I aircraft Snoopy favored in Peanuts comics by Charles Shulz [ISBN/ASIN: 1841610216]:

    
    Sopwith Camel Specifications 
     
                  Country: Great Britain 
             Manufacturer: Sopwith Aviation Company 
                     Type: Fighter 
    First Entered Service: May 1917 
             Number Built: 5,734 
                Engine(s): Bentley BR.1, 150 hp
                           Reciprocating Le Rhône Rotary x 1, 110 hp
                           Clerget 9B, 9 cylinder, air cooled rotary, 130 hp
                           Clerget 9Bf, 9 cylinder, air cooled rotary, 140 hp 
                Wing Span: 28 ft 
                   Length: 18 ft 8 in 
                   Height: 8 ft 6 in 
             Empty Weight: 889 lb 
             Gross Weight: 1,422 lb 
                Max Speed: 118 mph 
                  Ceiling: 19,000 ft 
                Endurance: 2.5 hours 
                     Crew: 1 
                 Armament: 2 Vickers .303 machine guns (F.1)
                           1 Vickers .303 and 1 Lewis .303 machine guns
                           or 2 Lewis .303 machine guns (2F.1) 
    

    I know some of you are saying to yourselves, "This is gibberish, why should I care about this trivia about children's rhymes and riddles, pop-culture and antique machinery?" But others of you are saying, "Yes, I remember that!" And when you got to the Sopwith Camel, you might have thought, "What is a 'Reciprocating Le Rhône Rotary x 1' anyway? Sounds cool." If so, you just might be a techie.

    These early memory games are good preparation for the adult world of technology, where you find yourself having to commit to memory detailed and cryptic information such as:

    A typical UNIX search path is:
     
    ~/bin /usr/local/bin /usr/bin /bin /usr/local/sbin /usr/sbin /sbin /usr/X11 .
    

    Tech Tip:
    Keep memorizing;
    your brain can't get full.

  5. rigor

      I throw a spear into the dark — that is intuition. Then I have to send an expedition into the jungle to find the way of the spear — that is logic.

        — Ingmar Bergman

      Think of the design process as involving first the generation of alternatives and then the testing of these alternatives against a whole array of requirements and restraints.

    This one is key. Some people are good at rigorous thought, some are not. I define rigor loosely as the ability to follow mental rules: those imposed by others, and even — especially — those you create for yourself. For example, when you paint a picture, when you make the first few brush strokes you are totally free to paint anything anywhere. But after a while, each new bit of paint must fit in with what you've already done. Or when you write a story, at first you get to choose where it take place, what the characters look like, and all the accompanying details, but later you must remember what you've already written and be consistent. The effect is similar in engineering. Bucky Fuller defined a "design" as "a set of inter-accommodations."

    I have met people who cannot or will not do this. It seems to make their brains hurt to struggle with the constraints they have created for themselves. For some reason they find it easier to try to find someone else to figure it out for them, or just abandon the project, than to work out the consequences of their premises.

    Over the years I have found a simple test that is extremely accurate in gauging a person's ability to operate rigorously. Here is my "Rigor Test" in full:

      Q: "If the moon's a balloon, what's the moon?"

    One of things this tests for is the ability to, at least temporarily, tolerate mystery, along with capriciousness and arbitrariness. Some wrong answers to this question include:

      A: "What do you mean?"

      A: "Huh?"

      A: "But the moon isn't a balloon."

    For partial credit I will accept the answer, "the moon," or any other statement of fact (i.e., "a satellite of the Earth"), but the correct answer is, obviously:

      A: "A balloon."

    This is roughly analogous to typing into an interpreted computer language (like BASIC, Logo or Perl) something like:

      moon = "balloon"
      print moon

    (This particular set of gibberish is lifted from the title of David Niven's autobiography, The Moon's a Balloon: Reminiscences (1971), which I haven't read but have heard is great. Meanwhile, the overambitious among you may take on the assignment of debugging the code shown, in BASIC, Logo and Perl.)

    Only someone who can tolerate mystery and capriciousness can tolerate the often absurd and inexplicable requirements of technology. If you're lucky, you'll find out later why something is the way it is, but for now, you have to accept things and barge ahead to get a job done.

    I still remember on my old Apple II computer; it originally used 13-sector disks and then later upgraded to 16-sector. To use the old 13-sector disks in a new 16-sector drive, you had to run a program that emulated the old drive. This program was called, "MUFFIN." and since it was a "binary" (machine language) program, in the Apple II's primitive operating system you used the "BRUN" command — short for "binary run" — to execute it. So the complete command was:

      BRUN MUFFIN

    This was obviously some juvenile programmer's idea of a bad pun, on "bran muffin," done for no good reason other than that he (or she) could. It speaks volumes about Apple's early corporate culture that this program didn't have its name changed before release. I was amazed at the time by how many people this tripped up. It seemed simple to me: if you wanted to use a 13-sector disk in 16-sector drive, you had to type "BRUN MUFFIN" first; if you didn't it wouldn't work; end of story. But I worked with some people who just couldn't manage to absorb and use this information, because it didn't match their idea of how a computer worked — they expected it to be logical. One person kept typing "BRAN MUFFIN" instead. When I corrected them, they asked, "Why isn't it bran muffin? That makes more sense." I sometimes call this the "Mister Spock Myth" (from the emotionless science officer in the 1966 TV show Star Trek [ASIN: 6305513406]), that computers — and technology in general — will be "logical." I have found that if you try to explain it all with logic you will go mad. (For one thing, classical logic does not allow for the passage of time.) Often, when people say "logic" they really mean "common sense." Rigor requires common sense, but also patience, determination, and awareness of what you are doing, and almost always leads to uncommon results.

    Three of Cubicles

    Three cubicles stand in relief against complex equations. Math may well be the Queen of Sciences, but she's slumming in the Silicon Valley. Computer scientists haven't had much to do with her for quite some time. Rigor, method, incisive thought. Reversed: reservation, caution, need for further inquiry.

    Silicon Valley Tarot
    © 1998, Thomas Scoville.

  6. constructs mental maps

    There are people who will create a folder on their computer named "Writing" with two sub-folders named "Fiction" and "Nonfiction," and never draw this picture in their heads:

            +---------+
            | Writing |
            +---------+
                / \
               /   \
              /     \
             /       \
            /         \
      +---------+  +------------+
      | Fiction |  | Nonfiction |
      +---------+  +------------+
    
    I guess they just memorize the clicks to get from one folder to another. This is analogous to the people I described in the previous chapter who don't form mental maps of the landscape as the wander the Earth; they just remember the turns (left on Second Street, right on Maple Drive, etc.) to get somewhere.

    Techies have to form mental maps — often elaborate, subtle mental maps — of the technologies they wish to understand. In rare cases these maps became diagrams and are available to others; most of the time each map exists only in the mind of its creator.

  7. structured creativity

    Techies face a constant need to be creative, but not in an open-ended, self-expression kind of way. Programmers have to invent filenames, variable names, method names, and often metaphors to organize complex tasks. System administrators have to come up with host names. (One place I worked we used sit-com characters: Lucy, Ricky, Fred, Ethel, etc.) Even electrical engineers must name the signal lines they design into circuits.

    This isn't like the creativity of poets and artists. This structured creativity must follow a pattern, be done on demand and often in a hurry (sometimes in large quantities as well), and communicate subtleties in a straightforward way. Most techies take this skill for granted, but without it they can be lost in indecision and unclarity.

  8. persistence

    I've especially noticed this trait in kids — not all children, or at all times in any given child, but sometimes a kid just won't give up. They try and try and try and try and try and try and try and try, and then, they succeed. (Maybe.)

    Conversely, as people get older they seem to become more inclined to try something only once, and abandon it on the first failure. In fact, I've learned that if I'm training inflexible (usually older) coworkers in the use of a new technology, I had better get all the bugs out first. If they see me having any problems at all, they won't be willing to attempt it themselves.

    Obviously, this persistent quality is essential to being an effective techie. I have found that documentation of technical procedures is often wrong. Maybe it was written wrong, maybe there was a typo that was never fixed, maybe it used to be right but when the technology was revised the docs weren't updated to match. In any case, you usually have to try at least a few variations to get anything to work as advertised.

    The situation gets worse if you're working on something that has never worked before. I have literally found myself trying something that might work a thousand different ways (actually, 1024 if I remember correctly) and proceeding as follows: I wrote a short program to create a list of all possible combinations, printed it out, and tried each one in turn as I crossed it off the list. I worked on it a few hours each day. (Unfortunately, there was no way to automate my search.) I was lucky — I hit the correct combination in less than 500 tries.

    A salesman I worked for early in my career used to talk about the "wall of pain." Anyone using a new technology had to make it through this wall. He believed one of the keys to success for any high-tech company was to help its customers through the wall of pain, giving them extra support and encouragement until they emerged victorious on the other side.

    Nowadays a trendy name for this quality is "focus," but I think this name tends to imply a short time scale. Someone with "focus" blots out the world and concentrates on a problem until it is solved. But the world does intrude. One has to eat, use the restroom, go to meetings, occasionally get some sleep, and attend to other requirements of life. Sometimes persistence means being able to return to a task again and again, as needed, despite countless setbacks, until it is completed. What I am calling persistence is a combination of focus and patience. Some tasks require weeks, months, or even years of persistently applied focus to reach completion.

  9. inquisitiveness

    One of the biggest causes of ignorance is people's fear of looking stupid. Good techies know this, and ask plenty of questions, especially when they have access to people with lots of answers.

    I often hear a person who has a computer but lacks the knowledge to use it described as someone who "doesn't even know how to turn it on." But this can actually be a nontrivial challenge (especially if it's a Mac from the 1990s). The real indicator here is that if a good techie is given a computer to use, and can't find the "on" switch, they will call the tech support people right away and ask. The sign of the clueless is to wait a few days, and then be so embarrassed to ask (because you will really look stupid at that point) that you find a reason to never use it at all. If this sounds crazy, I assure I have seen it happen more than once — if not with that particular question, then with others that were equally "stupid."

    One of my most valued teachers was a professor I had in college named Gregory Bateson. (More on him later.) He taught me that questions are more important than answers. If you have the right questions it's usually not that hard to find the right answers. Whenever I'm learning a new technology, I like to make a list of my questions as I encounter things that puzzle me. It helps in two ways: if I get access to an expert, I can pull out my list and make a lot of progress in a short period of time, and later, if I need to help other newbies, I have the beginnings of a Frequently Asked Questions (FAQ) list.

    Tech Tip:
    The only stupid question
    is the one you don't ask.

  10. fascination with 'meta'

      "The map is not the territory. "

        — Alfred Korzybski, 1933
              Science and Sanity: An Introduction to
              Non-Aristotelian Systems and General Semantics
        [ISBN/ASIN: 0937298018]

    I don't know anyone who confuses actual roadmaps with land masses. Likewise, nobody I know would try to eat pictures of food, or even a menu. But I have seen books of menus designed to help travelers select restaurants, and some of these are sold in combination bookstore/cafes which also serve food, so it is conceivable that someone could confuse a menu of menus with a menu, and try to order off one. This is where things start to get hairy. If you are shooting a TV commercial for the new High-Definition Televisions (HDTVs), how do you show how much better they look in a commercial that will be seen on someone's old, low-def TV? How do you explain to the audience why you can't show them the new, improved picture? Once you move the map/territory distinction into the realm of pure information, you start losing people.

    For example, in a typical UNIX shell (also called a Command Line Interpreter, or CLI) the asterisk symbol:

      *

    is a "wildcard" character which stands for any combination of zero or more legal filename characters, so A followed by an asterisk:

      A*

    stands for any filename beginning with A, such as:

      ANT.txt APPLE.jpg
      AR2.doc AZ.Java

    But what if you somehow end up with a file whose actual name is A asterisk:

      A*

    and you want to rename it to something less bothersome? (I won't go into how this can happen, but believe me, it can.) In this case you can use the shell escape character, backslash, to indicate that the following character is to be interpreted literally, not as a wildcard. So referring to the filename as:

      A\*

    would work. But if what if the above is the actual filename? The you need to escape the escape character, and then escape the asterisk, and so refer to the file as:

      A\\\*

    Are you still with me? This is the kind of 'meta' stuff that techies find fascinating, and many other people find incomprehensible.

    This stuff isn't new, either. A story from the Sufis, a group of mystics and philosophers which originated in the Middle East possibly 6,000 years ago, plays with these ideas:

      A king, disenchanted with his subjects' dishonesty, decided to force them to tell the truth. When the city gates were opened one morning, gallows had been erected in front of them. A captain of the royal guard stood by. A herald announced, "Whoever will enter the city must first answer a question which will be put to them by the captain of the guard."

      Mullah Nasrudin, who had been waiting outside the gates of the city, stepped forward first.

      The captain spoke: "Where are you going? Tell the truth ... the alternative is death by hanging."

      "I am going," said Nasrudin, "to be hanged on those gallows."

      "I don't believe you!" replied the guard.

      Nasrudin calmly replied, "Very well then. If I have told a lie, hang me!"

      "But that would make it the truth!" said the confused guard.

      "Exactly," said Nasrudin, "your truth."

    I will have more to say about these conundrums, which nowadays are called "paradoxes of logical type," later in this chapter. Suffice it to say at this point, if you can't figure out how to refer to a file with a backslash in its name, you just might not be a techie.

  11. strong syntax skills

    Above I said that in most UNIX shells asterisk stands for "zero or more legal filename characters." This is a syntax definition. I have found that some people can grasp this as-is, while others need examples. Don't get me wrong — examples are good. They confirm information. But for some, only the examples impart information; the syntax definition is incomprehensible. (Of course, there are also people who will never get it either way.) But the ability to understand syntax is vital to being a good techie.

    The first computer language I programmed in was Algol-60, which happened to be the first language defined in the syntax description language known as Backus-Naur Form, or BNF. A thorough discussion of BNF's history and significance is in the article "What is BNF notation?" on-line at:

    I have lifted the following quote from that site (this is a quote of a quote then, which shouldn't faze you syntax-savvy techies):

    The following is taken from M. Marcotty & H. Ledgard, The World of Programming Languages, [ISBN/ASIN: 0387964401] Springer-Verlag, Berlin 1986, pages 41 and following:


    The meta-symbols of BNF are:
    ::=
    meaning "is defined as"
    |
    meaning "or"
    < >
    angle brackets used to surround category names.
    The angle brackets distinguish syntax rules names (also called non-terminal symbols) from terminal symbols which are written exactly as they are to be represented...

    For example, the BNF production for a mini-language is:

    <program> ::=  program
                       <declaration_sequence>
                   begin
                       <statements_sequence>
                   end ;
    
    This shows that a mini-language program consists of the keyword "program" followed by the declaration sequence, then the keyword "begin" and the statements sequence, finally the keyword "end" and a semicolon.


    (end of quotation)

    So, did you pass the "eyes glaze over" test with that? If not, it should make sense to you that BNF is a meta-syntax, that is, a syntax for describing syntax. (Clearly, this is tied up with the notions of 'meta' I discussed in the last section.) Also, you should realize that, like the word "FOO" in the quote at the top of this section, the symbols "::=" are meta-syntactic as well. They do not appear in actual programs, and are only used to define the syntax of computer languages.

    It might seem that this stuff is of interest only to computer programmers — and certainly these confusions can get most intense in the case of symbol-processing systems like programming languages and mathematical logic — but issues of syntax permeate almost all technology. Herbert Simon, in The Sciences of the Artificial [ISBN/ASIN: 0262691914], argues that an invention is essentially a linguistic construct — even something as obviously physical as a chair or a crank. To support his argument he looks at the world before these inventions, which are much more recent than you might think — both date from the 13th century. Can you imagine what it was like to not know what a chair was? It's hard, because it involves syntax and language you learned at a very early age.

  12. strong language skills

      Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.

    Techies must communicate with people. They must communicate with other techies, which can be tough enough, but also with non-techies, which can be maddening. Here we venture out of syntax and into the domain of semantics — the meaning of language. Here we also reach one of the dividing lines between good and great techies.

    The parsing of syntax can be programmed. The XML (eXtensible Markup Language) standard is all about teaching programs new syntax in an automated way. But semantics is another story. A program that does a good job of parsing the semantics of English would get you a PhD at MIT or CalTech, no problem. But don't look for it soon.

    Until then, techies will have to do a lot of communicating in natural (i.e., human) languages — not only talking and writing, but reading and listening. Without a firm foundation of natural language communications skills, a techie is hampered.

  13. sense of responsibility

    Here is a touchstone that separates the good techie from the great, and for that matter the bad from the good. This is also to the antidote to the (usually inaccurate) perception some non-techies have than a techie's natural playfulness is a sign that they are unreliable.

    A great techie keeps their word. This means not promising what you can't be sure to deliver, as well as delivering what you promise. This quality can be improved with willpower and practice, but I don't know any way to instill the motivation to do so in the first place. A technical manager once said to me, "you have to hire for service, you can't train for it." This is true for integrity as well.

    If you reflect on this this you will realize that service and integrity are related. Some of the poorest performers in the technical world have the intellect, the curiosity, the persistence, in short the many qualities I have catalogued above, but lack the fundamental desire to be of help to other people. You may know some. They're the ones who like to demonstrate how smart they are, but not teach what they know. They can often write efficient programs, but won't document them — or even add comments to the source code. Or, as a hardware designer, they build devices only they can operate. In the science fiction novel The Mote In God's Eye (1974) [ISBN/ASIN: 0671741926] Larry Niven and Jerry Pournell describe the engineers in an alien race called "Moties" who operate this way in a very extreme case — never documenting or standardizing. I remember at the time I read it thinking that it would seem unbelievable that any beings could design machines that way, if it weren't for the fact that I was currently working with some engineers who were almost that bad.

  14. courage

    It may sound odd to talk of the courage of a techie. Certainly soldiers, police, firefighters, security guards, and others who face physical danger require greater courage to do their jobs. But consider that surveys show most Americans fear public speaking more than they fear death. What this tells us is that ego-based fears can sometimes be more severe than those inspired by physical dangers. Techies must have the courage to face failure, frustration, appearing stupid, and taking the blame for things sometimes beyond their control. I believe that often it is lack of sufficient courage that keeps many people from aspiring to technical mastery.

    Rudyard Kipling wrote the poem If... (in Complete Verse, 1907 [ISBN/ASIN: 038526089X]) about such courage. It begins:

      If you can keep your head when all about you
      are losing theirs and blaming it on you...

  15. orneriness

      In the remote areas of the world, I have known hundreds of tech reps — aviation, heavy tractors, communications, x-ray technicians, Coca-Cola bottlers, General Motors maintenance — and they always have four characteristics...

      . . . .

      Second, they are difficult to manage. Left alone in the Burmese jungle, they operate beautifully. Bring them back to California, where they have to attend parties given by the head of engineering, and they fall apart. In civilization they tend to be drunks, lechers, malcontents and irresponsibles. On the frontier they are powerfully organized. Putting it another way, they are the darlings of the technical staff, the despair of the personnel men. Within two weeks of bringing a tech rep back to headquarters, the man in charge of the home office can be counted on to shout, "Get that miserable son-of-a-##### out of here." But if you send a man to Burma who is not psychologically suited to be a tech rep, even worse trouble develops, and the same boss, reading the reports of the Burmese government, will growl, "Get that poor jerk out of there..."

      Thus the tech rep is the continuation of a fundamental strain in American life. He is the lineal descendant of the gifted wagon maker who could not get along in the settled civilization of Lancaster, Pennsylvania, but who was invaluable on the frontier in Santa Fe.

    I bring up this issue of orneriness, not because I think it is a good thing, but because it seems pervasive. Usually, when it occurs it is a problem, for the techie and for their management. It is seen as a character flaw to be overcome, and it is often the cause of techies being fired. An experienced technical manager will expect a certain degree of this, but it is almost never greeted with enthusiasm. Generally, all other things being equivalent, the less ornery you are the farther you will go. I will offer advice on how to deal with unwanted ornery tendencies in section 2.18, "WATCH THAT 'TUDE, DUDE" later in this chapter.

Tech Tip:
Don't be a pain.

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

I first heard the term "superlearning" in a seminar on personal and small business finance. (Called "Money and You", it was taught by Marshall Thurber, of the Burklyn Business School.) We spent over 12 hours a day in a room together, over a period of three days, with very little fatigue. The key was the way the seminar was structured: each session was 50 minutes long, followed by a 10 minute break. During the breaks we were encouraged to move around, and to eat fruit. (Coffee was also available, but discouraged.) Mostly the sessions each consisted of the group playing some sort of simulation game, and then discussing what we'd learned from it.

I found this methodology very useful, but the big take-home value to me was the idea that there was such a thing as superlearning. I began to look for other examples.

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

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:

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]:

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:

and the problem was identified as:

So I went to the Google search engine:

and searched for:

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

(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.

Tech Tip:
Seek out
superlearning
techniques.

{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:

Of course, you can often probe even deeper. In the colors example above, theatrical lights always include white, and printer inks always include black. It is arguable that "singularity," the center of a black hole, constitutes a seventh state of matter. And I've heard that some islands off the coast of Maine use the Atlantic time zone of the Maritime Provinces unofficially.

The point is that you can almost always dig deeper, and get more complete information. Certainly this is no way to spend all of your time, but on the other hand, when the opportunity presents itself it usually pays to dig a little deeper. My favorite analogy for this is the Hughes Glomar Explorer, a ship built by Howard Hughes' Summa Corporation in the 1970s, which the public was told was being used to explore the ocean floor for mineral-rich manganese nodules — but there were leaks that it was being used to raise a sunken Soviet submarine. According to one story, the mission was a total failure. Another version said that while the sub was being raised it split in half, and the highly-prized nuclear missiles and code books were lost. Yet another story said the nukes and codes were recovered. What raised suspicions is that the codes would be much more valuable to U.S. military intelligence if the Soviets didn't think they had been compromised. But there have been persistent rumors that even this wasn't the whole story. Or maybe the mission was totally different. The CIA is said to have tried to keep the media from reporting any of this, and then later they tried to keep the media from reporting that CIA was trying to influence the media. This story of a deep sea mining ship seems to have bottomless layers of cover stories. We will probably never know the whole truth. But digging deeper still yields more results. Such is the nature of most knowledge.

Tech Tip:
Do not take things
at their surface nature.

{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-ItTM 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.)

Tech Tip:
Get the most
out of your
technical books.

{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:

I have personally seen every one of these effects in action. But if you're on the receiving end of bad documentation, it doesn't really matter much why. Here are the antidotes:

  • 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.
  • Find a guru who has been down this road before, and ask them for a guided tour of the documentation — what's reliable and what isn't?
  • If it's programming you're studying, get ahold of some sample code, make sure it works, and compare it with the documentation.
  • if the documentation involves installing hardware or software, it can be extremely useful to have a working system to refer to. In the case of software, compare all the files on the working system to the one you're trying to get working.
  • Persistent experimentation and guesswork may be required — hang in there!

Once you have done the above — or as you are doing the above — record what you learn. If the manuals are only slightly wrong, mark up your copies. If they are way off, write your own notes. (In either case, if they are from your own company, be sure to give copies of your improvements to the tech writing department.)

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.

Tech Tip:
Record what you learn.

{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:

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.

Tech Tip:
Whatever it is
you do,
do it often.

{2.5.5} Memory Improvement

Earlier I discussed how important it is for a techie to have a good memory. (You do remember, don't you?) Here I will give tips on improving your memory. Neuroscience has revealed that there are two categories of memory: short term and long term. Back before mental health care professionals realized that electroshock therapy was cruel and ineffective, it was discovered that after a "shock treatment" the patient couldn't remember anything that had happened for about 45 minutes before the shock. Subtler and less destructive experiments since then have confirmed that short-term memory seems to be electrical, while long term memory is more chemical/structural, and the transfer from short to long term takes about 45 minutes (if it happens). Actually, I believe that only a tiny amount of what is stored in our short term memory makes it into long term. That's why I'm a big fan of writing things down. But you can't write everything down. So here are my tips, divided into the two categories.

To improve short-term memory:

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

Tech Tip:
Use memory tools
and play memory games.

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

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.

Tech Tip:
An expert is someone
who's solved your problem
before.

{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.

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.

Tech Tip:
Capture all failure
data from the field —
there is no other source
for this extremely
valuable information.

{2.6.3} Downstream data sources.

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

{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.

{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:

    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."

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.

Tech Tip:
Value content
over form.

{2.6.7} Beware of shills and covert agendas.

For thousands of years there have those who knew you need to be cautious in your business transactions and choose carefully whose advice you take, and there have been those who didn't seem to get it. Maybe this is because, as P. T. Barnum said, "There's a sucker born every minute."

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.

Tech Tip:
Don't be a dupe.

{2.7} YOUR NETWORK OF EXPERTS

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.

{2.8} IMPROVE YOUR UNDERSTANDING OF 'META'

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:

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:

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:

(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:

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:

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

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

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.

Tech Tip:
Intuition will get you through
times of no rigor better than
rigor will get you through
times of no intuition.

{2.10} THE ART OF TROUBLE SHOOTING AND DEBUGGING

Nobody seems to like this joke but me, but it made me laugh, because I remember being the SE and having stuff just "fix itself" on occasion! Nevertheless, this is not a good example of troubleshooting technique.

According to her autobiography, the verb "to debug" was first used by programmer Grace Hopper, who later gained fame for heading the team that invented FORTRAN, the first high-level computer language. She was working on the MARK II computer at Harvard, doing what is generally described as "getting the bugs out of the system," when she found a moth inside one of the relays, beaten to death by the flipping switch element. She taped the dead moth into the log book on September 9, 1947, with the notation:

    "1545 Relay #70 Panel F (moth) in relay. First actual case of bug being found."

Thereafter, whenever management inquired on the status of the MARK II, she would say, "We're still debugging it."

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:

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:

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

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:

{2.11.2} What's hard:

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.

Tech Tip:
Get the right tools
for the job.

{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:

For example:

    An operations researcher was assigned to devise a elevator scheduling policy to minimize passenger waiting time in a certain building. After visiting the building, he realized that the problem his employer really wanted to solve was to minimize the discomfort to passengers (who didn't enjoy waiting for elevators). He solved the problem by installing mirrors near each elevator: the passengers then spent their wait admiring themselves, and complaints about the speed of the elevators was dramatically reduced.

Here is another example, in the form of a quiz:

    Problem 1 — Sorting. The circulation department at Scientific American receives thousands of letters every day. The lion's share fall into half a dozen major categories: payments of bills, renewals of subscriptions, response to direct mail promotions, and so forth. The mail must be sorted into these groups before it is processed by the data entry clerks. Describe schemes for sorting the mail.

Before you read the solution used, think for a minute about different ways to solve this problem, and which would be cheapest.

    Solution 1. A clerk could manually place each letter in one of several bins; an automated solution might use a letter-processing machine for the job. Those solutions are expensive, so the magazine has the post office do the job for them. They use a different post office box number for each of the major categories, and the mail is delivered in bundles corresponding to the categories. Each box costs about 100 dollars per year, which is a tiny fraction of the cost of a clerk.

(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:

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

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

None of the rest of the steps that follow will do you much good if you don't really want to produce results. Make sure your motivation is high before resorting to any other techniques.

Of course, this easier said than done. Honestly, I am sometimes baffled by my own "muse." As the old song says, "When you're hot, you're hot; when you're not, you're not." But there are clues to be found, and it is vital to search for them. The key is being able to stay creative for long stretches of time.

One friend of mine, a musician and songwriter, has said that he wouldn't recommend this to anyone else, but that when he is feeling the blues the worst is when he does his best song writing.

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:

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:

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.

Tech Tip:
An ounce of motivation
is worth a pound of
time-management tips.

{2.14.2} Distractions

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!

Tech Tip:
Get into a mental zone
of high concentration and productivity,
and protect it from distractions.

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

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

In a high-tech company there is always too much to do — unless there isn't enough to do, which is a bad sign for your job, the company, and/or the industry you are in. But let's assume the happiest situation, which is there is too much to do. Organization involves both managing scarce resources (including your time, your "energy," shared tools, access to others) to get the most results, as well as deciding which results you aren't going to achieve.

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

Tech Tip:
Adopt a filing system
only if it saves you time
in the long run.

{2.14.5} Multitasking

If you look at the life-cycle of a task, it expands as you learn more about it and it contracts as you complete it (assuming it is converging, see above). It also usually includes a number of steps that involve taking action and then waiting for results. You put the cake in the oven and you wait for it to bake. You begin compiling a program and wait for it to complete. You request information by email or voicemail and wait for a response. I have found that the trick to effective multitasking is to do a good job of managing these tasks going in and out of "wait states," and to make it easy to task-switch quickly. Again my assembly language experience may be showing, but I remember the evolution of CPUs in the 1970s as complex instructions were introduced to store the states of registers on a stack in one step, and to in one step restore them from the stack back into registers. Later, in the move from Complex Instruction Set Computing (CISC) to Reduced Instruction Set Computing (RISC) in the late 1980s, some of these functions moved out of machine instructions back into software (giving it back to the compiler writers). This ability to cleanly save and restore the short-term structures you need to work on a problem is the key to seamless multitasking.

For example, if you have to do something to a bunch of files — proofread them, or print them, or even just read them, I'm a big fan of making a list of files and printing out the list, and checking them off with a pencil as I do them. It makes it easier to work on them a little at a time.

I've mentioned earlier how you can use Post-ItTM notes as bookmarks and achieve a finer resolution of where your "place" is. When you're debugging code and you must stop before solving a problem, make a note what's half-fixed in a comment in the source code. If a task has complex structure, make some type of chart or diagram to track progress.

While I'm on the subject of machine instructions and multitasking, I learned an important concept while working on multiprocessor computer architectures: the "atomic operation," which cannot be "split." The classic example was "decrement counter and jump if zero," which you wouldn't want interrupted after the decrement that reached zero and before the jump. Otherwise, if you interrupted this operation halfway through the counter would be zero but no jump occurred. The code after the jump is responsible for resetting everything, but that hasn't happened yet. Now lets say inside the interrupt handling code another "decrement counter and jump if zero" occurs. The counter, at zero, decrements to -1 or 65535 or some such garbage value depending on the chip type. The second test for zero fails and the jump does not occur. Later, the code returns from the interrupt and does the first test for zero, which also now fails, and the jump isn't executed then either. Result: the condition is missed, none of the reset code is run, and there's garbage in the counter. Bad craziness. That's why this instruction is made "atomic" and can't be split.

Likewise some of your steps in performing tasks should be atomic. If you're printing out files with a checklist as I describe above, the print operation and the checking off the file on the checklist must be together in one "atomic" operation. In other words, you must "disable interrupts" during the operation. If the phone rings right after you press "Control-P," answer it with, "Can you hold please?" Check if the file is printing. Check it off on the list. Now take the call.

(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

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

Motivational speaker Jim Rohn (the "grandaddy" of the motivational speakers revered by Tony Robbins, Zig Ziglar, Robert Allen, etc.) has spoken on several occasions about the importance of making sure resting does not become a goal, or a state you strive to end up in and stay in. One of his oft-quoted saying on this is:

    Make rest a necessity, not an objective. Only rest long enough to gather strength.

This can get a little tricky if you use "taking a break" as a reward for achieving goals. I recommend you don't make the break itself the reward, but instead have something you get during the break, like iced tea or a dip in the pool or picking out a new CD to play. Otherwise don't confuse the feeling of "Oh boy, I'm almost to my goal," with craving inactivity. This happens to people sometime when they retire, and then they go stir crazy. One antidote to this type of error is the old "postman's holiday." Take a break by doing something very similar to what you do for a living, but for fun or even as a volunteer for a good cause. (They call walking for fun the postman's holiday and driving for fun the busman's holiday.) The British have a saying:

    A change is as good as a rest.

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

The first principle to be sure you follow is, if you find yourself procrastinating on a task, make sure you do something else useful, not just do nothing. Procrastination can sometimes be simple to get over, and sometimes it is complex. But do not permit logjams to form. Make sure if you get stuck on one task that you keep making progress on all the others.

The first response to procrastination should be to review this checklist:

  • Verify the priority of the task. Is it really important, and worth using resources on now?

  • Make sure you have a plan that you have confidence in. Do you think you know how to do what's required? If not, how will you figure it out? If you don't have a plan, or if you don't think your plan will work, that can be a big stumbling block.

  • Use the technique described above to start a project. You don't have to make much progress, just do a small chunk. See how it goes. Maybe it won't be as bad as you think.

  • Are you rewarding yourself with little goodies? Hey, it works. You can't knock success.

  • If the task involves calling someone, do you have their phone number written on your "to do" list? Do you know what time is best to call?

  • In tackling a number of unpleasant tasks, I find it useful to do the most unpleasant first. It creates a feeling of empowerment, plus from that point it's "downhill all the way." It works especially well with phone calls.

If none of the above shakes you out of your procrastination, then there's one more thing to check for before I'd conclude that you have a "serious" problem; it's what I call: a mind-lock loop. This is a way of getting "stuck" that is easy to stumble in to.

When you are in a mind-lock loop you go through a loop of thinking you have to wait for a condition, then later when that condition is achieved you realize there is another condition you have to wait for, but when that other condition is achieved you forget that's what's needed and go back to to waiting for the first condition. This problem sometimes comes if you use vague or misleading terminology on your "to do" list, or don't think through the steps involved to perform a task. An example should help. Let's say you decide you want to build some bookshelves to go in your hall, and you write down on your "to do" list:

    [_] buy lumber -> [_] build shelves

which is shorthand for the "build shelves" task depending on the "buy lumber" task being done first. So one day on your way home from somewhere you see a lumber yard and pull in to buy that lumber. Standing around among the stacks of 2x8x48" pine boards you realize that you forgot to list a vital prerequisite step, and the "to do" list should in fact say:

    [_] measure hall -> [_] buy lumber -> [_] build shelves

because you have no idea what size lumber to get. So far this is just a snarl. What makes it a loop is when you forget to update the "to do" list, and later forget the whole lumber yard visit, and one day you are sitting at home waiting for the cable installer or something and you look on your "to do list which still says "buy lumber" first, and you think, "It's too bad I can't go to the lumber yard but I have to say home and wait for the cable installer," so on your next free day you finally make it out to the the lumber yard and there among the the stacks of 2x8x48" pine boards you realize once again that you haven't measured the hall. It can make you feel really stupid, which is a memory that's easy to suppress, priming you for the whole loop again.

This kind of nonsense usually goes on with tasks that are fairly low in priority, because you are distracted by other things, and so usually the problem is fixed by the application of clear, focused thought and an elevated level of consciousness and awareness. In the light of day these mind games seem absurd, but there they are. It is when they are never exposed to consciousness that they become monsters. Like the speck of dust that grows into a pearl inside the oyster's shell, an unexamined, undissolved mind-lock loop can grow into a big ball of resistance and avoidance, all over something trivial to begin with.

At this point if you're still stuck, you need to do some serious introspection, and ask yourself: is the task the problem or am I the problem? Because if there's an important message for you here either way. If you're the problem this is an opportunity to grow, and to face your resistance. Is it fear of failure, fear of success? Fear of looking stupid? Fear of change? Or is there anger here, resentment, or envy, or destructive competitiveness? You have to grapple with whatever's up for you. Your procrastination is trying to teach you what you need to do to move to the next level in your career.

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]:

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.

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:

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:

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.)

{2.15} RISK MANAGEMENT

Much of this material is directly involved with time management, but I have pulled it out into its own section because there are some common themes I want to emphasize. Also, it is sometimes the case that a techie masters most aspects of time management but still doesn't practice good risk management: the symptom is that they complete task assignments on time most of the time but occasionally are very late or fail entirely. This section is about avoiding these potential "flame-outs" that prevent you from being a great techie.

{2.15.1} Maximize Slack

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.

{2.15.2} Isolate Research From Production

Earlier I detailed the ongoing research a techie must do: frequently the manuals are wrong or missing, and so you have to do your own experiments and write your own documentation. But research is a messy business, involving very many unknowns. It's hard to be sure you've put everything back the way it was when you started sometimes. This makes it risky. You can mess up production systems as well as demo systems with research. That's why it's so important to isolate them. Keep the risk away from the valuable workhorse systems. That way, if your research system goes down, the only consequence is you can't do more research for a while, but nothing else is adversely impacted. Here are some steps to follow in isolating the risk of research:

  • Set up a test bench when practical.

    I used to work for a former aerospace engineer who told me tales of "destructive test" of turbines and jet engines, inside "destructive test chambers" made of cinderblock, in which he would over "rev" the turbines until they exploded. I suppose you can learn a lot about turbines and how they fail by doing this. But it would be reckless to do it in the turbine factory. That's why the cinderblock structure makes so much sense.

    Think about what your "cinderblock" is going to be. In the world of computers, this can mean having a separate machine for research if possible, or maybe a removable disk with a separate research environment, or a bootable disk partition. if not, can a separate test login be created? Make a "test" folder where files for experiments are isolated. If you're going to modify files, especially system and configuration files, copy them first. Is there a way to create scripts to copy a whole set of system files in and out of the "test" folder with simple commands, in order to easily switch between the test and production environments? Figure it out. Protect yourself.

    When doing software development, I like to have a "test bench" program which I can use for experiments without polluting my project code. Typically my test bench will call other functions or methods while printing out extensive information before and after. It's handy to be able to hack at it to do a quick experiment without the overhead of creating a new program, and without putting my project at risk.

  • Label or throw away broken stuff.

    When I was a boy my dad had a workbench covered with interesting junk. One item was a transformer, a metal rectangle with a heavy coil and core inside, which he'd wrapped in duct tape and labeled in his crisp, all-caps engineer's printing: "INOP" I asked him what it meant, and he explained it was short for "inoperative." This transformer didn't work. A wire was broken in the coil. He'd tested it with an Ohm meter and figured that out, and he labeled it so that he wouldn't have to test it again later, or be otherwise confused by it. He was going to salvage the core, or else just throw it away, but he hadn't decided yet. He ended up giving it to me, because I requested it. I used it as a paperweight for years. It always reminded me to label or throw away broken stuff.

    This is especially important with computer data files and software. With just a few keystrokes or mouse clicks you can create dozens of perfect digital copies, and then modify each slightly to see what happens. That's very educational, but you need to make sure you don't leave broken stuff lying around where it can confuse you later. Delete the files, or rename them with "BAD" added on, or put them in a "BAD" folder, to save yourself some grief later.

  • When a test bench is impractical.

    Sometimes your ability to isolate your research is limited by the resources you have. You may have one laptop with a non-removable disk. You may be using an Integrated Development Environment (IDE) to both code and demo, which has global settings you can't partition somehow. And yet, you need to be experimenting to keep learning. The best you can do in this case is to partition over time. Spend a few days (or hours) doing experiments, and then put it back in demo mode and thoroughly test the demo. Leave it in demo mode when not actively doing research. You'll be ready for unexpected demos.

    Tech Tip:
    Always be experimenting,
    but test the demo last.

    Another tip is to always be on the lookout for systems to be sacrificed. If either a computer is to be discarded, or hard drives are to be erased and all files reinstalled from scratch, ask to borrow the system for a few days first. See what you can disable by scrambling the settings. Take good notes.

  • Avoid demonstrating unstable technology.

    In almost every job I've had we've exhibited a high-tech product at trade shows, and there was always a faction that wanted to use the latest, untested, "beta" version of the product straight out of engineering, because it had the "new features." I have found that this is almost always a bad idea. Here are my reasons:

    • Potential prospects walking up at a booth don't know anything about your product. The "new features" probably don't even make sense to them out of context. They need the whole story of your product.

    • If they see your product "crash" or otherwise misbehave, or see your demo pilots acting nervous or confused, they will think bad things about your product, no matter what the "new features" are.

    • At any point in a healthy high-tech product's life cycle, there will always be the current, released version, which customers are hopefully using and which is hopefully pretty stable; there will also always be the new version, in some partial state of completion, and dangerous to mess with. You should also always have ready a slide show of bullet points and diagrams explaining the features in the new version. Show prospects that, not the beta.

    • Keep in mind that the purpose of a trade show is not to show everything you have and answer all questions, it is to create interest in your products. If you succeed in having interested parties initiate dialogs with your sales force, your mission is accomplished.

    If you actually get a hot prospect who needs to see the new features in the beta, do it this way: Bring them to your headquarters. Take them into the board room, your best conference room with the dark wood paneling and the track light and projector screen controls on the remote control unit. Have someone in a suit give them the standard product story, using slides and a demo of the current, released version. Explain the new features they are going to see. Remind them for the 100th time that it is a "beta" version. Take them back into engineering, into a messy lab full of wires everywhere and disassembled gizmos lying around. Have an engineer in business causal attire (beard okay, in fact a plus) use a funky-looking engineering system to demonstrate the untested version. Stress that the company doesn't usually show beta software; this is a special favor for an important customer. If the software crashes or acts up (and even if it doesn't), be sure to include a briefing about and tour of your Quality Assurance (QA) department, who hopefully look like they're ex-Navy. (Warn them in advance to wear white shirts that day.)

    Tech Tip:
    Don't run barefoot through cow pastures
    and don't demo "beta" software in public.

{2.15.3} Simulate and Rehearse

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:

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.

Tech Tip:
Test exactly the same the way
you will demo or deploy.

{2.15.4} Make Extra Copies

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.

Tech Tip:
If you have too many copies
you can delete some.
If you don't have any copies
you're out of options
and possibly in deep trouble.

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

In the travel chapter I gave a list of hazards to watch out for on the road: situations in which it pays to pay extra close attention, such as when you are collecting your personal items and getting off an airplane. Similarly, in your technical work there will times of higher hazard when you should be paying close attention. They are too numerous to list, but a few examples will help clarify:

{2.15.6} Stay Cynical

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:

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

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:

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

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:

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 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

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

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:

{2.20} AN ETHICAL FRAMEWORK FOR TECHNOLOGY

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

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

When I first got involved with the corporate world of computers in the late 1970s, many of my fellow employees came from a youth oriented, college crowd kind of "counterculture," and on more than one occasion somebody asked me, "Doesn't it bother you that you've sold out?" They were in favor of a number of progressive social agendas, and saw computers as a tool used only by greedy corporations working to pull us farther away from those agendas. Luckily I had been exposed to some of the high-tech visionary works of people like Alan Kay, Stewart Brand, and Ted Nelson, as well as groups like the People's Computer Company in Palo Alto, California and the Community Bulletin Board project in Berkeley, California, so I knew about some positive visions of computers for social good.

For example, I like to believe that the utility of the Internet and the cheap availability of the Web, Email, Telecommuting, Collaboration Groupware, and Videoconferencing, among other tools, has made a bigger contribution in reducing the energy usage of developed nations than any amount of "energy policy" efforts within government or political activists.

The Stockholder

An ordinary suburban woman and her cat stand skeptically against an Annual Report. She has invested her savings, and now has second thoughts. The cat is symbolic of domestic life. The two of them are dependent on the company's earnings, estimates, dividends, and growth for their upkeep and retirement. Admonishment to company officers: Never, ever mess with a woman or her cat. Responsibility, obligation, prudence, vigilance. Reversed: penury, poverty, unmet expectations.

Silicon Valley Tarot
© 1998, Thomas Scoville.

{2.20.2} Creating Value

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

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

As promised at the beginning of this chapter, I want to look briefly at the historical roots of the "techie" before I close.

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.) :

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