42 Years as a Software Engineer
by Owen Weber

On January 24th, 1977, I began my career as a software engineer. This article documents the highlights of my career, so far. (It's quite lengthy, but you can just skip the boring parts.)  

Table of Contents

Formal Education (skip to next section)

I graduated from Okeene High School in Okeene, Oklahoma in 1973. I knew that I wanted some kind of a career related to mathematics. However, at that time, the only occupational choices seemed to be an accountant or an actuary. I had taken an accounting class in high school but I wasn't too interested in it, and I wasn't even sure what an actuary was. However, when I was a senior in high school, my physics teacher, T. J. Williams, had taken me to Oklahoma City to hear Wernher von Braun speak. He was the German-American engineer and space architect who invented the V-2 rocket for Nazi Germany and the Saturn V rocket used in the Apollo manned lunar missions for the United States. I was intrigued by him, and a possible future in the space industry, but I neither gave it much thought nor had any idea of how to pursue it.

In the fall of 1973, I entered college at Southwestern State College (SWSC) at Weatherford, OK, which later became Southwestern Oklahoma State University (SWOSU). In my second semester at SWSC, in the spring of 1974, I noticed the brief "Computer Science" category in the course catalog. Like most people, I had never seen a computer. There were virtually no computer jobs yet, and I didn't know that Information Technology (IT) was about to become its own huge industry.

I decided to try it, so I enrolled in FORTRAN I taught by Dr. Benny Hill. I didn't know Dr. Hill very well, but he made learning fun, and he was very patient in teaching the radically new concept of computer programming. After a few days and weeks of being somewhat intimidated by the way computers worked, I finally understood what was going on, and I fell in love with it. The idea of feeding input into a computer, letting it do all the work by churning through a series of calculations, and receiving printed output from it did indeed seem to have potential for being a very powerful tool. Thanks to Dr. Hill (and subsequently, Dr. George Atkins) I was on my way to being one of the many pioneers on the forefront of the IT industry.

(back to the Table of Contents)

History of Computing (skip to next section)

In 1964, IBM had introduced a new generation of computers. The IBM 360 was at the high end of these computers, but by 1974 they were still so expensive that only the larger universities could afford them. Fortunately, IBM also offered the IBM 1130 at the lower end, but it incorporated the same new technology. SWSC had an IBM 1130, and that's where and how I learned computer programming. Amazingly enough, that computer had only 8 thousand bytes of memory, and it supported the whole campus. A typical $500 laptop today can easily have 8 billion bytes of memory--one million times more than what we had in college.

The entire computer lab was in a single room with about 300 square feet of space. The IBM 1130 set at the front part of the room, with a (huge) printer on the left; the Central Processing Unit (CPU), the auxiliary storage (a mysterious 13-inch encapsulated disk) and a crude typewriter interface in the center; and, the card reader on the right side. Altogether, this computer was probably about three feet wide, ten feet long, and four feet high. In the back of the room were four (huge--and noisy) IBM keypunch machines with a typewriter interface.

Some brief background on these keypunch machines is necessary here. These machines utilized an algorithm patented by Herman Hollerith in 1889. (This in itself illustrates the slow evolution of computing for the next 90 years, until about 1980 when the IT industry really exploded.) Hollerith’s invention included the electrical tabulation of data by punching rectangular holes into cardboard punch cards (approximately 7" long by 3" high). Each card contained 12 rows and 80 columns, and Hollerith's algorithm allowed for "any" number, alphabetic character, or special character to be coded into each of the 80 columns. As a result, each card could contain up to 80 characters of information.

In 1896, Hollerith founded a company called the Tabulating Machine Company. In 1911, this company merged with three others to form the Computing Tabulating Recording Corporation. Then, in 1924, this company was renamed International Business Machines Corporation (IBM) with Thomas J. Watson as the first president of the company.

(back to the Table of Contents)

Back to My Training (skip to next section)

So, when I wanted to write a computer program, I would write the FORTRAN source code on a pad of notebook paper during class. Then, at my designated lab time, I would go to the lab, open a box of these Hollerith punch cards, and load a stack of them into the keypunch machine. Then I would sit down and carefully type my program, one line per card, and the machine would punch the appropriate holes into each card, according to Hollerith's algorithm, which was readable by the computer's card reader. Then, after a special "data" card, I would continue typing the data that I wanted my program to process--again, with one piece (row) of data per card. Sometimes the resulting stack would contain hundreds of cards for a single program.

For example, suppose I wanted to write a program to calculate the results of a presidential election; i.e., given the total number of votes for Candidate 1 and Candidate 2 in each state, I wanted my program to show the total number of votes cast for each candidate in all 50 states. The pseudo code for my stack of cards might look something like this:

   1 TotalCand1 = 0
   2 TotalCand2 = 0
   3 If we have reached the end of the data cards, then GoTo line 8.
   4 Read values Cand1 and Cand2 from the next card.
   5 TotalCand1 = TotalCand1 + Cand1
   6 TotalCand2 = TotalCand2 + Cand2
   7 GoTo Line 3
   8 Print TotalCand1, TotalCand2
   9 Special card; i.e., data to follow
 10 92176 54231  // Alabama
 11 12347 22978  // Alaska
 Lines 12 through 59 would be similar data cards for the remaining 48 states

Then I would (carefully) take my stack of cards, in the order in which I had typed them, and place them face down into the input area of the card reader on the computer, and secure the cards with a weight on top of them. I would press a "Start" button on the card reader, and the card reader would read the cards, one by one, and I would retrieve my stack of cards from a bin on the side of the card reader. Of course, a card jam would frequent destroy a few cards and I would have to re-type them and try again.

Then the CPU of the IBM 1130 computer would process the information retrieved on my cards. It would treat the card reader input as a computer program until it read the "data" card, and it knew that the subsequent cards were to be used as input for the program. Upon recognizing that I had written a program in the FORTRAN language, it would load the FORTRAN compiler software from the (huge) auxiliary storage device, and the compiler would process my program. If it compiled without errors, it would then process each data card against the compiled (Assembler) code, and it would print the results (at about one line per second) on the huge printer. This was a typewriter-style printer that would actually print with typewriter keys, one full line at a time, so the printer made a fairly loud noise each time a 120-character line of output was printed, as up to 120 typewriter keys would simultaneously hit the paper through the printer ribbon, creating a rhythmic sound as it printed one or two lines per second.

On the other hand, if the compiler detected an error in my program, it would print a crude error message on the printer. I would then find the card that caused the error, re-type any needed new cards, and replace the old cards in the stack. Then I would try the modified stack of cards on the computer again. So, this is how Dr. Hill taught me to program computers.

Here's a project that I did for the Electoral College results of the 1976 presidential election that Dr. Adkins had published in the paper: College Electoral Map_1976. This was printed on that huge line printer. It illustrates how far computer graphics have come.

Some of the additional computer courses that I took during my college years included:

Advanced courses in FORTRAN - A scientific-oriented programming language
Courses in RPG - A business-oriented programming language
Courses in COBOL - A business-oriented language, actually assisting the college
Assembler - A low level programming language
System Simulation - Simulating ships approaching and leaving a dock, etc.

SWSC still did not offer a degree in Computer Science, as only the larger universities did. As a result, I graduated with a B.S. in Math, with a minor in Computer Science, in the fall of 1976, although I actually had more hours of Computer Science than of Math.

During the fall of 1976, I applied for jobs by sending (paper) resumes, letters, and transcripts to various companies. Several prospects were immediately interested, and I had early interviews with the following companies:

Phillips Petroleum, Bartlesville, OK
Texas Instruments (TI), Dallas, TX
Burroughs, Detroit, MI

Resume_1976 (Note the job experience section.)

(back to the Table of Contents)

IBM (1977 - 2001) (skip to next section)

By December, I had received job offers from Phillips Petroleum and Burroughs, but, disappointingly not from Texas Instruments. In addition, I had received rejection letters from many companies that wouldn't even grant me an interview, including IBM (IBM_Rejection_Letter). I had ruled out Burroughs because we didn't want to move to Detroit, so I was beginning to assume that I would go to work for Phillips. However, as time was running out, IBM decided to give me an interview with their Federal Systems Division (FSD) in Houston, TX.

When I interviewed with these companies, I didn't really know what was going on. I didn't know what to expect. I didn't know anything about the companies or their industries, and I had had no coaching on how to conduct myself during interviews. (Consequently, I believe that's why I blew the interview with TI.) When I interviewed with IBM in Houston, I was more enamored with the possibility of working for IBM (which seemed like the epitome of computer programming companies) than I was with the job itself--programming on their NASA space shuttle contract for the first shuttle mission. I remember interviewing with one manager named Sol Solomon who helped me to understand more about what I might be doing, but I still had no real idea what would be involved, or even what it would be like to work for a large company.

I was nervously waiting to see if I would receive an offer from IBM (my first choice). I actually had two letters prepared for Phillips--one accepting their offer, and one rejecting it. Finally, at the last minute, IBM made me an offer as a "Scientific Programmer," and I accepted. I would start with IBM's FSD in Houston on January 24th, 1977 for a salary of $263 per week. (Although this was only about $13K per year, it was three times more than I had ever made in my life).

(back to the Table of Contents)

Houston--Developing Onboard Space Shuttle Software (1977- 1981) (skip to next section)

So, I made the 550-mile move away from home and moved into an apartment in Nassau Bay, TX, just outside of Houston. It was right next to a bay off the Gulf of Mexico, and about three blocks from NASA. Karen still had eight weeks of class work to complete at SWSC before she could join me and begin her student teaching at Clear Creek High School in League City, TX. We moved to League City later that year. I was 21 years old and I felt like I was on top of the world.

IBM was apparently very aware that we new-hires were quite green, especially in an emerging industry, so their first order of business was to give us eight weeks of intense training in a Beginner Programming Training (BPT) class. There were 13 of us in my class, and we were sort of on probation until we made it out of that class. It was indeed valuable training, and we each emerged from that class with a job title of "Junior Programmer." We were each expected to excel enough in our jobs during the first year in order to receive our first promotion to "Associate Programmer." About half of the class was assigned to the Ground-Based Shuttle systems (GBS), and half went to the Onboard Shuttle systems (OBS). I was assigned to OBS on the Guidance, Navigation, and Control (GNC) project. My first manager was Nelson Harbison, and my second-line manager was George Mueller. I shared an office with Waldon Scott, a veteran Staff Programmer. Due to the nature of our work, I also had to acquire Secret security clearance with the federal government.

(back to the Table of Contents)

Inertial Measurement Units (IMUs) (Boring--Celestial Mechanics Stuff) (skip to next section)

My first programming project was for the Redundancy Management (RM) of the Inertial Measurement Units (IMUs). As I quickly learned, an IMU was a sensing device that was a key component of the navigation system of the shuttle. The shuttle had three IMUs, and each one included a gyroscope and an accelerometer. Basically, the gyroscope indicated the location of the shuttle (as a vector in three-dimensional space) and the attitude of the shuttle (the position/direction in which it was moving). The accelerometer indicated the rate at which the shuttle was accelerating or decelerating in that direction. The various computer programs on the shuttle ran anywhere from one hertz (once per second) to 25 hertz. The IMUs reported data to the software at 6.25 hertz, so the IMU software ran six times per second.

Since there were three IMUs, the RM software was necessary in order to reconcile any conflicting measurements reported by the IMUs for determining the true position, direction, and acceleration of the shuttle. This was standard operating procedure for the shuttle--to have multiple (backup) hardware devices in case of a failure. With the IMUs, the function of the RM software included determining if an IMU had failed; which of the three IMUs had indeed failed; and, to subsequently ignore any data from that IMU.

How was this accomplished, especially since I had only minimal training in celestial mechanics? Well, fortunately, we had scientific analysts who understood all of this. So, NASA would give the requirements to our analysts, and our analysts would give me detailed specifications--almost pseudo code. So, simply by knowing the HAL-S programming language (a PLS-type fourth-generation and top/down structured language), I would translate the scientific specs into software code.

Although I was on the frontier of software technology, our process was still quite crude at that point (a somewhat scary thought when considering the delicate requirements of sending humans into space and returning them safely). I would sit at my desk and figure out how to write the required programs. Then I would go to one of several small keypunch rooms, most of which contained two keypunch machines. After sometimes having to wait in line for a keypunch machine, I would keypunch my program onto cards, one line per card. Then I would write any specific instructions to the computer operator on a piece of a paper (such as loading a particular tape drive), and wrap the paper around the stack of cards with two rubber bands. I would lay this package on a specific table in the hallway, and a few times each day, a courier from NASA would collect all of the packages from the tables and take them across the street to the computer room at NASA. The computer operator would run my program on their mainframe computers (in a stand-alone environment) and send back (via courier) my stack of cards along with the printed output from the program.

This was a very frustrating way to have to conduct business, because the turnaround was so slow. I would typically get only one chance each day to run my program. I remember constantly checking to see if my printed output had been returned. I would often be disappointed after waiting until the next day for my output, only to find that I had made some silly mistake in my typing, or a card (often bent in transit) couldn't be read by the card reader, etc.

When all of us had our programs in working order, then the SDL (Software Development Laboratory) folks would integrate all of the software and test it in the shuttle simulator at NASA. Of course, eventually the software would ultimately be loaded onto the (five redundant) computers of the space shuttle itself, and our programs would navigate and guide the shuttle through the atmosphere, into space, and back.

(back to the Table of Contents)

Flight Control (skip to next section)

After working on the IMUs for a couple of years (for managers Mary Cole and Ed Zatopek), I transferred to the Flight Control area, working for Harold Herbold. I found this to be much more challenging, demanding a deeper knowledge of celestial mechanics and aerodynamics. (An old NASA joke: "I don't know what's so difficult about it. It's not rocket science... Oh, yeah, it is.") Basically, while Guidance and Navigation read sensors such as IMUs, the Flight Control system actually issued the various commands to move the shuttle from where it currently was, to where it should be 1/25th of a second later.

Each mission consisted of three phases--ascent (liftoff), orbit, and descent (re-entry into the atmosphere; i.e., flying basically as a glider). Depending upon the mission phase, different specific flight control tools were utilized. During liftoff, our code would send controls (3-D vectors) to the Solid Rocket Boosters (SRB engines) and the three main engines of the shuttle in order to accomplish all of the roll, pitch, and yaw maneuvers required to launch the shuttle through the atmosphere and into orbit. While in orbit, we controlled the flight by issuing commands to the Orbital Maneuvering System (OMS) engines in a weightless environment. During descent, we controlled the shuttle by issuing commands to the ailerons and the rudder, just like an airplane, as it entered the atmosphere, descended, and landed on a long runway.

(back to the Table of Contents)

Scarce Resources (Maybe not Boring for Software Engineers) (skip to next section)

Unlike today, hardware resources were very scarce in those days. Each of the five General Purpose Computers (GPCs) on the shuttle had only 100,000 bytes of memory. As a consequence of this, we programmers had to be very efficient in writing our code. In fact, I can recall occasions, while testing simulations, when I would have to write part of a program in just a few bytes (maybe 10 to 20 bytes) of memory. Here's how that went:

Our PLS programming language was a high level language, and a line of PLS code might look something like this:

if (sensor_level >= 1.7) GoTo 7

This means: If the condition in the parentheses is true, then go to line 7.

However, this PLS code then generated lower level Assembler code for compilation/assembly and linkage editing. A line of assembler code might look like this:

MOV AL, 1h

This might mean: Move the hexadecimal value of 1 into register AL.

It would take many lines of Assembler code to equal the above line of PLS code because it's done one step at a time; i.e., move several values to several registers, then do some compares, etc.

However, machine level code is the most basic (lowest level of code), and the hexadecimal code for a line of machine code might look like this:


For example, the "41" might be EBCDIC code for the letter "A"; "46" is "F"; "40 is a space, etc. It is comprised of these one-byte hexadecimal characters, usually in clumps of 4, 8, or 16 bytes.

This would then translate into binary code, as follows:

0100 0001 0100 0110 1111 1111 0100 0000

i.e., the "4" in hexadecimal (base 16) = the "0100" in binary (base 2), etc.

Anyway, sometimes after the code had been compiled and loaded into memory in the shuttle simulator, the programmer would be called upon to make a change, but then it had to be in the form of a machine language patch. In other words, I might be told that the code between memory locations 71,456 (bytes) and 71,536 was faulty, and I had to re-code those 80 bytes of memory using ones and zeros. I would send 80 bytes of ones and zeros across the street with instructions for the computer operator to patch those particular locations in memory with my new code.

The mainframe computers at NASA were quite interesting. IBM had introduced its line of IBM 370 computers in 1970, and they were much larger and faster than the 360s. NASA had two of these IBM 370s at the time, but they also had three of the older IBM 360 models--the same technology I had learned to program on with the IBM 1130 at SWSC. In fact, while I was with FSD, one of the 360s at NASA had the serial number "2"; i.e., NASA bought just the second one ever made (for use on the Gemini and Apollo programs), and I used it in my program development for the shuttle.

(back to the Table of Contents)

The First Space Shuttle Mission (Not Boring) (skip to next section)

The first space shuttle mission, STS-1, was scheduled for April 10th, 1981. I was among those that IBM had selected for real-time support of that first space shuttle mission and maiden flight of Columbia. The first orbital space flight of the shuttle sounds exciting, but the awesome responsibility hung like a yoke around my neck. After all, we were about ready to fill a huge fuel tank with liquid hydrogen; bolt a space shuttle to it; put two men in that shuttle; and then light it--and this had never been done before. So, tensions mounted as that date drew near and it became all too clear that those holes I had punched into those cardboard cards could mean life or death for the astronauts. In fact, a couple of scary incidents did occur.

First, less than two weeks before the mission, on March 30, 1981, President Reagan was shot during an assassination attempt. Although this incident had nothing to do with our space program, this was not at all clear at the time, so it made things very unsure for us. Also, there's a certain bipartisan unity and patriotism among defense workers (both in the Department of Defense as well as among contractors) that I had never previously experienced (and that is certainly not widespread today). It was sort of like being in the military.

When I would travel to places like the U. S. Department of Defense in Alexandria, VA, or Rockwell, International in Downey, CA, I would see the President's picture proudly displayed in most offices, meeting rooms, and hallways. Whenever a new president was sworn in, they would just as proudly replace the pictures of the outgoing president with those of the new one, regardless of their political views. The president was not only revered as the Commander-in-Chief, but also as the ultimate head of NASA. NASA is not technically a part of the Department of Defense, nor of any other Cabinet-level department. NASA's administrator reports directly to the White House, and of course the president recommends funding for NASA.

So, when
President Reagan was shot, it affected morale. Most of us were old enough to remember President Kennedy's assassination, and as the reports were leaked out about President Reagan, we couldn't help but draw some analogies to President Kennedy's situation. At first they said that President Reagan had not been among those hit, and some of the first reports in Dallas had said the same thing about President Kennedy. In Kennedy's case, reports quickly followed that he had indeed been hit, but that we could all take hope in the fact that they were rushing him to Parkland hospital, a very reputable hospital. So, when the next reports we heard about President Reagan said that he had indeed been hit, but that we could all take hope in the fact that they were rushing him to George Washington University Hospital, another very reputable hospital, we became very skeptical about any ensuing reports that sounded optimistic. Fortunately, of course, he recovered quite quickly, but not before a few anxious moments at NASA.

The second scary incident occurred during the first countdown of the STS-1 mission. Serving on the real-time software support team was one of my greatest challenges ever. Behind the Mission Control room at NASA (that most TV-watchers saw) was a smaller room for software support. During simulations and real missions, we staffed that software support room (needless to say--24 X 7), and we were at the beckon call of Mission Control, if any question or problem came up concerning the software.

One moment of tension always occurred during the Flight Director Chris Kraft's "roll call." At the beginning point of the countdown, and at several key points during the countdown (and the rest of the mission), he would contact each area (Guidance, Navigation, Flight Control, Software, etc.) in a roll-call fashion. He would simply say the name of that area, and he wanted to hear only one word in response, "Go;" i.e., he didn't want to say, "Software," and then hear "No go," or least of all any stammering around that would indicate any unsure or unstable tendencies. It was a very intense and demanding job, and I can remember the hair standing up on the back of my neck whenever I would hear the voice of Flight Director Chris Kraft in my headphones saying, "Software? ..."

Well, as I alluded to earlier, this scary scenario actually played out during the pre-flight moments of the first mission as the space shuttle Columbia set on the launch pad with astronauts Commander John Young and Pilot Robert Crippen onboard. I had worked for four years (with 800 other IBMers) in anticipation of this moment. I was in the software support room behind mission control when I heard the countdown for launch suddenly stop at about T-20 minutes before the main engines were supposed to fire. Something had gone wrong. Everyone at NASA was frantic and nervous, and sure enough, I heard the Chris Kraft's voice frantically saying, "Software?..."

As I recall, it was the voice of my peer, Roger Demeny (an IBM veteran), whose job it was to reply to Chris Kraft, "No go." We feverishly began looking at downloaded hexadecimal memory dumps, paging through software, etc. As it turned out, the issue had in fact been due to a software (timing) error, but it was in the system software (thankfully not my area), and the mission had to be "scrubbed" (aborted). The error had been coded by one of my colleagues, and he also supplied the fix.

However, it took a matter of hours / days to get things back on track and rescheduled. STS-1 was finally successful, lifting off on April 12th, 1981 and returning from a 54.5-hour mission on April 14th, 1981 (during which I went on basically no sleep).

I also recall some nervous moments during the descent phase of that first mission. Throughout the history of the shuttle development, it was generally thought that the tiles on the bottom of the shuttle were its primary weakness. These were a special heat-resistant type of tiles which were necessary in order to keep the shuttle from burning up as it re-entered the atmosphere from space. The point of concern was the glue that held the tiles onto the shuttle. They continually had problems with this glue, and tiles would sometimes fall off during testing. Nevertheless, they went ahead with the mission. As the shuttle is entering the atmosphere, there is a brief blackout period (maybe 90 seconds) when communications between the shuttle and the ground are not possible. I remember how relieved we were on that first mission when we once again heard the astronauts' voices, telling us that the tiles had done their job. Everything was fine, although I believe that a minimal number of tiles did indeed fall off, but not enough to cause any real problems.

One of the perks of my job was getting to meet some of the astronauts, including one meeting with John Young (one of only 12 men to walk on the moon) and Bob Crippen when they came to our IBM facility for a presentation. On another occasion, I traveled to Rockwell, International (who built the shuttles) in Downey, CA to meet with some astronauts about some specific software concerns that they had.

(back to the Table of Contents)

The IBM Culture and Advancement (skip to next section)

Meanwhile, I usually received above-average performance evaluations during those years at FSD. I was promoted to Associate Programmer (Promotion_Notice_1977) after just nine months, and to Senior Associate Programmer (Promotion_Notice_1979) after two years.

I quickly became deeply immersed in the IBM culture. IBM seemed like a company that would take care of me for life. In order to reciprocate, and to always put our best foot forward to our customers, male employees were expected to wear a dark blue or gray suit every day, with a white shirt, and a "sincere" tie, and the women were expected to wear dresses. This strict dress code continued until Louis Gerstner, Jr. took over as CEO in the early 1990s.

(back to the Table of Contents)

Tradition (skip to next section)

Tradition ran deep at IBM. Thomas Watson, Sr. had founded the company in 1924, and served as the first CEO. In 1952, he was succeeded as CEO by his son, Thomas Watson, Jr. (who later served both as the National President of the Boy Scouts of America, and as the U.S. Ambassador to the Soviet Union). In 1971, T. Vincent Learson succeeded Watson as IBM's CEO, but he served for only two years. When I joined the company in 1977, Frank Cary was our CEO--only the fourth CEO ever of the company that was then over 50 years old. The other CEOs while I was still with the company were John Opel, John Akers, Louis Gerstner, Jr., and Sam Palmisano.

(back to the Table of Contents)

Diversity (skip to next section)

One of my colleagues was a veteran IBMer who had joined IBM as a CE (Computer Engineer) in 1959, and he once related the story to me about his first day with the company. IBM had hired 250 CEs who reported to a large meeting room on their first day. My friend said that the group consisted of 250 men (no women), all in blue suits, white shirts, and ties.

Well, by the time I joined the company, big changes were (justly) underway at IBM, as well as at most other large companies, largely due to the Civil Rights Act of 1964. It was now IBM's policy to make sure that they didn't discriminate against any employee based upon ethnic background, gender, or age (and eventually, sexual orientation). Employees were regularly and frequently ingrained with related education, including programs such as Equal Opportunity, Affirmative Action, and Diversity. I'm proud to have been a part of the diversity movement that contributed to the advancement of women and minority groups in the workplace.

(back to the Table of Contents)

Goals (skip to next section)

I recall how anxious I was to advance my career through promotions. When I first started with IBM, I quickly noticed that it was easy to discern an employee's level by his/her office and desk. Employees who were at Staff level and below had to share an office with another employee (each with metal desks). Advisory level employees got their own private office with a wooden desk. Above that (Senior level and beyond), an employee's level was revealed by the size of his/her desk, and the amount of overhang on it. I quickly made it my goal to reach the Advisory level, and to have my own private office. Another goal was to become a member of the IBM Quarter Century Club, an elite group of IBMers who had 25 or more years of service.

(back to the Table of Contents)

Full Employment (skip to next section)

Another "benefit," although not officially a part of the benefits plan, was called "full employment." This meant (unofficially) that as long as an employee worked hard and kept getting good results on his performance evaluations, he didn't have to worry about losing his job. Officially, it was stated that no IBM employee had ever been let go for "economic reasons" in the history of the company (since it started in 1924). In other words, nobody had ever been laid off at IBM. It was sort of like having tenure as a college professor. I knew that I was a competent employee with above average performance reviews, so I made myself another goal: to retire from IBM with full benefits after 30 years of service on January 24th, 2007, although that seemed like a very long way off.

(back to the Table of Contents)

Dallas (1981 - 2001) (skip to next section)

Immediately after the success of STS-1, I applied for a transfer. My mother had been suffering from congestive heart failure for three years, and we wanted to move closer to her so that we could visit her more often. Also, my job on the space shuttle was very stressful, giving me prematurely gray hair. I had wanted to make it through the first flight, and I did.

(back to the Table of Contents)

ADF (skip to next section)

I applied for several jobs in the Dallas area. I learned about one of these jobs through an IBM colleague of mine, Dan Kemp, who had recently transferred from Houston to Dallas just as I was looking to do. I accepted that position, working in the same department as Dan, in the new Las Colinas development in Irving, about three miles from the old Texas Stadium. We moved to Carrollton, TX, and I started my new job as an Application Programmer on July 1st, 1981.

While FSD brought a lot of good press to IBM, it wasn't one of its more profitable divisions. My new job was more in the mainstream of IBM's core business. I was a software developer on a product called IBM ADF (Application Development Facility). It enabled our clients to customize their own applications on IBM mainframe computers. On the IBM 370, programs were run on operating systems such as VM (Virtual Machine) and MVS (Multiple Virtual Storage). I programmed in the PL/1 language, another fourth-generation language, using SQL (Structured Query Language) relational databases (RDBMS). I wrote my first SQL query in 1981, and those same queries would still work in today's RDBMS.

Our customers were mostly large companies, including several large banks. The idea was that ADF would allow each customer to control exactly what happened at the point of a customer transaction, in terms of data processing. Remember that this was before everything was electronic, automated, and online like it is today. Although our capabilities then seem crude now, I was still working on the very forefront of technology.

In addition to working for a more profitable division, it was at this time when I first became familiar with what we now call e-mail. This was still about 15 or 20 years before the internet, but IBM did have a sophisticated company-wide network where we could communicate electronically with other IBM employees (at least in the U.S.). So, I sent my first e-mail in July, 1981. I had a crude, huge, heavy, black-and-white (green) monitor on my desk (these were later referred to as "dumb terminals," because they only connected to the company network, without any CPU or memory of their own). Not only did we now have e-mail, but we also wrote our programs electronically via this terminal, so I no longer had to use stacks of keypunch cards. The difference was like night and day. Instead of using a manual keypunch, I could just type the lines of code into a file, save it, compile it, wrap the proper JCL (Job Control Language) around it, and run it as a batch job on MVS.

One of my specific tasks was to improve the performance on a sub-product of ADF called the Auditor. Even though I now used mainframes, resources were still scarce, and expensive, and computers were slow in comparison to what we have today. I had a lot of fun seeing how efficient and fast I could make the Auditor, and this experience taught me a lot about performance benchmarking. I excelled at this task, and within a year or so, I received a promotion to the Staff Programmer level.

While in my ADF job, I traveled some, including trips to Tucson, AZ, and my first trip ever to New York City. On the other hand, one of the things that I didn't like about that job was "the hotline." The members of my department would rotate handling the hotline, which meant serving in the role of customer support, by fielding phone calls from (sometimes irate) customers. I never felt like I had enough knowledge of all of the functionality of our complex software systems in order to provide the desired level of customer satisfaction, especially when being put on the spot on a phone call.

I was a workaholic. I was so devoted to my work that when my mother died in 1983, I only took two days off. On a Thursday, we received word that she was probably dying. We drove to Oklahoma after work that day, and she died that evening. I took off Friday; her funeral was on Sunday; I took off Monday when we drove back to Carrollton; and, I went back to work on Tuesday morning. That's really sad.

(back to the Table of Contents)

Interactive Satellite Education Network (ISEN) (skip to next section)

I had been in this job for nearly four years, and I was not really looking to change jobs. However, as it happened, our next-door neighbor in Carrollton, Ed Pitrucha, was a Director (executive level manager) with IBM. One day, his wife, Ann, invited Karen to a Tupperware party at their house. While Karen was there, Ed mentioned to her that he needed to hire a software specialist, and she indicated that I might be interested. Ed had recently moved back to the Dallas area from New York, where he had advanced so far in the company that he was even rubbing elbows with CEO John Akers. He now headed a department in IBM's Education Division called the Interactive Satellite Education Network (ISEN). He didn't need a programmer--just someone who could understand software and act as a liaison with the vendor. In January, 1985, he offered me a promotion to Advisory level, with my own private office (which had been two of my goals since joining IBM), and I accepted. Incidentally, that was the last promotion I ever received.

ISEN was a sophisticated education network that IBM used for customers as well as its own employees. There were four broadcast sites in: New York City, Chicago, Los Angeles, and Washington, D.C. There were 13 sites that could receive these broadcasts, including these four broadcast sites, as well as nine other sites such as in Dallas, Houston, Philadelphia, St. Louis, Boston, Hartford (CN), Minneapolis, etc. An instructor would sit in a studio at one of the broadcast sites and teach a course via satellite. At the receive sites, there was a satellite dish on the roof and a number of 8-student classrooms, again all equipped with the latest technology. At the front of each classroom were two monitors--one showing the instructor, and one showing his instruction material, foils, etc., along with a speaker broadcasting the instructor's voice. So, there were video, audio, and data signals being broadcast from the studio via satellite.

At each student's desk was an electronic device that would allow a student to direct a question to the instructor. The student would simply press a button which would send a signal back to the studio, where a light would be illuminated, indicating that a student at a certain site had a question. The instructor would verbally acknowledge the question, and the student could then speak directly to the instructor, with the audio of both the instructor and student being broadcast to all sites. This was at the expense of temporarily blocking the data line transmission, because that line was now being used for the student's audio. The idea was that the education could be just as effective as if the instructor was physically in the classroom, while reaching more students across the whole country, and minimizing travel (expense) for both the instructor and the students. (Today, we use the Internet for this.)

Although the concept was simple, the implementation was not. Our vendor was Hughes Aircraft, who supplied the communications hardware, and their vendor for the required software was NCR, a company based in Tokyo. I needed to learn how the software worked, how to respond to software errors, etc. One of the perks was that Ed sent me to Tokyo for three weeks in August, 1985 to meet directly with the folks at NCR. In addition, although I didn't need to write any ISEN software, I did write a nifty AI (Artificial Intelligence) VM application for IBMers for the scheduling of ISEN classes.

This was the time in my career when I learned how to travel. Not only did I get a trip to Tokyo, but with broadcast and receive sites scattered all around the country, I made frequent trips to many of those 13 cities, including New York City, Chicago, Los Angeles, Washington, D.C., Houston, Minneapolis, Philadelphia, and Seattle (where I was actually responsible for the building of a new receive site). As I recall, I believe that I went to Los Angeles and Washington, D.C. most often. I probably traveled between 25% and 50% of the time, making two or three trips per month, for one to five days each.

I've always said that Ed Pitrucha taught me how to travel. He was a big spender--one known to splurge--and he had a big IBM budget to spend. I once traveled to Philadelphia with him just so he could eat at Bookbinders (a famous restaurant, and one of Ed's favorites). On another occasion, he wanted to have lunch in New York the next day, so he and I left Dallas at 7:00 AM, went to the ISEN facility in New York just in time for lunch with colleagues, and we were back home by 8:00 PM that night. This was back before all of the metal detectors and other safety measures were in place at the airports. I can remember sometimes riding with Ed to the airport, getting out of the car, walking straight into the terminal directly to the gate, and boarding the plane at the last possible minute. Sometimes it made me crazy, but I did enjoy the travel, although I didn't like being away from my family in the evenings. (Ed got onto me after my Tokyo trip because I had racked up some $300 in phone calls to Karen.)

It was during my ISEN years that I got my first "portable" computer. It was called a Compaq Portable. It was about 24" X "24" X 6", and it had a five-inch black-and-white screen (that actually displayed in amber-and-black). I did lug it home on some evenings, but it weighed about 25 pounds.

Incidentally, I do remember a particular day that will always stick in my memory. On January 28th, 1986, a colleague of mine, Mark Reith, quickly stuck his head in my office and said, "Hey, we lost a shuttle." The Challenger had broken apart 73 seconds after the launch of its tenth mission, killing all seven crew members. I could envision the roll, pitch, and yaw maneuvers of those main engines as it exploded during the ascent phase.

(back to the Table of Contents)

Back to Development (skip to next section)

In 1988, I decided that I wanted to get back into software development. It was relatively easy for me to find such a job with IBM in Las Colinas. I had a lot of contacts in that group, plus they were expanding in an effort to directly compete with a competitor. Microsoft was about to deliver a new product called Microsoft Office. Yes, this was the same Microsoft Office that so many of us still use today, and that now has a monopoly on that market space. IBM was determined to steal some of that business away from Microsoft (especially since the sale of DOS to Microsoft had gone so badly). IBM had developed its own operating system for the PC called OS/2 (IBM's answer to DOS and Windows), and it was now going to develop a complimentary office product called OfficeVision/2 (OV/2) to compete with MS Office. It would include e-mail, a word processor, a calendar, a library, etc., just like Microsoft Office, plus the family of OV products would run on virtually any IBM platform, from the PC, to mid-range hardware, to mainframes. So, the job sounded intriguing.

Furthermore, when I was looking for a job in my previous organization, I found out that the software development organization was going to be moving from Irving to Westlake. Then I found out about a clause in IBM's Moving and Living Expenses policy that turned out to be very helpful. If a facility moves its location, and the resulting move would cause an employee to have to commute more than 25 miles one-way, then they were eligible for the full Moving and Living Expenses package from the company. (This was back when IBM was still making lots of money, and willing to spend it liberally--more about this later.) As it turned out, this policy also applied to me, as an employee joining (or re-joining) that organization. Since my commute from Carrollton to Westlake would be more than 25 miles, I was eligible. This meant that we could move and IBM would pay our moving expenses, and even buy our house if we had any trouble selling it, etc. This was about a $15,000 perk, and it allowed us to build the house in Coppell that we still live in today.

So, I accepted a job as an OV/2 developer, and we felt like we had it made. I was 32 years old and we had built our own new house, just like we had always wanted, and I had a job with my own private office with an outside window and a view of the lake and the park. I had the challenges of learning a new operating system (OS/2) and a new programming language ("C"). In fact, OS/2 hadn't even been announced yet, and our code name for it was "Winthorn." As a result, the operating system was evolving as we were developing on it, a situation which offered new challenges in itself. Nevertheless, we were determined to beat Microsoft in this head-on battle.

I worked in several areas of the new product, including the calendar and the library, and my travel even included a trip to Toronto. However, my diversification was not all good news. A major part of the reason that I jumped from one area to another was because we couldn't seem to actually get anything developed and shipped. Our development process was too slow. We were stuck in the same development methodology of the old IBM, back when it was the only kid on the block. Now that we had competitors who were cranking out new products and new features every day, we couldn't keep up. We were used to releasing updates every six months, but our competitors were releasing every six weeks. Sometimes, by the time we were ready to release something, Microsoft had already released something even better. Or, sometimes the evolution of our own operating system seemed to bring us back to square one. As a result, I found myself working hard to develop software, and then (repeatedly) just throwing it all away and starting over. Eighty-hour weeks were common, and sometimes I worked over 100 hours per week. That's hard to do without severely cutting into one's personal and family time. (Again--sad.)

One of the old-time analysts that I knew at Houston, Dick Lemmon, once gave me an apt illustration. He said that if IBM hired him to dig a hole, he would dig it. If IBM hired him to fill in the hole, he would do so. So, from the point of view of my relationship with IBM--work for hire--this might be OK. However, when assessing what a repeated pattern like this will mean for the company's bottom line, one should always keep an eye out for how it's affecting profitability, and what changes might occur as a result.

Reversing Course (skip to next section)

Meanwhile, little by little, and somehow almost unnoticeably, IBM started losing money. The quarterly earnings statements didn't mean much to employees. Earnings might be down one quarter, or one year, but there was always a reason to expect that they would turn around the next quarter, or the next year. Life internally at IBM remained plush, with unofficially guaranteed full employment, and everyone fat and happy and spending lots of money on traveling, moving, etc. However, Big Blue began major cost-cutting measures, including incentives to encourage eligible employees to retire.

Then suddenly in 1992 everyone, including Wall Street, noticed that IBM had been losing $5B per year for the last three years. ($15B was a lot of money in those days.) Well, suddenly an unprecedented series of events began unraveling:

- The price of IBM stock dropped from $160 to $40.

- John Akers (the last of the old-timers) stepped down as CEO, as he couldn't stand to make the changes that he knew were coming, and Louis Gerstner became CEO for the new lean IBM.

- New retirement benefits for future retirees that had been announced only a couple of years earlier were terminated. IBM was simply not going to carry through with what they had promised. Sorry!

- The cash incentives to encourage older employees to retire were discontinued. If you hadn't retired by now, it's just too bad.

- The Tax Deferred Savings Plan now made more sense. It had been introduced as an "opportunity" for employees to "share in their own retirement investment." However, now it was apparent that things were quickly moving towards a point where employees would be solely responsible for their retirement pensions, with no help from Big Blue.

- Less profitable divisions were sold, including the Federal Systems Division, so IBM no longer had a hand in the space shuttle, defense contracts, etc.

- Then came the bombshell--full employment was no more. In one day, IBM reversed course, from full employment to the announcement of the largest layoff in corporate history. IBM would soon lay off 110,000 of its 400,000 employees. We were told that on the following day, every IBM manager was going to call each of his employees into his office and let them know whether or not they still had a job. (There were few good nights of sleep that night.) Although I was told that I still had a job, four of the ten members of my department were laid off immediately; in some departments, 70% were gone. I knew one man with 18 years of service who was laid off with no pension or anything. (I had 15 years at the time.) It was all just gone for him, and that could easily have been my fate as well. I called it "The Purge of 1993." Ironically, this was the same year that Thomas Watson, Jr. died. He had been a driving force for "full employment" throughout IBM's history.

These events remind me of the squabbles in the press today about states going broke, municipal bankruptcies, public unions and pensions, private and corporate debt, the federal deficit, etc. People who have been promised a pension may not get the full pension that they were promised. Future Social Security recipients may not get the full amount they were promised. And, people are outraged. How can they not get what they deserve--what they were promised? Why is this the case? Well, it's because things change, and sooner or later, everything has to be paid for, in one way or another. If IBM fat cats and retirees spent all of the future retiree's money, then that retiree simply doesn't get his money. If public unions keep pressuring our government bodies for money they don't have, then it has to stop somewhere. If debt gets out of hand, then somebody, somewhere, sometime, has to pay for it. Is it fair? No, certainly not in terms of honesty and integrity. Is that the way it is? Yes, it's called "change," and sometimes we just have to learn to live with it.

(back to the Table of Contents)

Software Testing (skip to next section)

Well, about this time, my career took a change as well, and for the better. I moved out of software development, and into software testing--Quality Assurance (QA). I was really having trouble with continually writing software only to throw it away. As a result, my performance evaluations were suffering (for the first time in my career), and I thought I needed a change. As a brief explanation for those not familiar with it, (the "Waterfall" methodology of) software development included several phases which may be generalized as follows:

- Requirements - Gather the requirements from (perhaps potential) customers as to what they expect the software to do.

- Design - Business analysts produced the high-level specifications from the requirements; and, developers produce the low-level specifications from the high-level specs.

- Coding - The developers write the code and perform unit testing on their own code.

- QA / Testing - The Quality Assurance team performs function, integration, systems, performance, and regression testing, creating necessary defects (bugs) and testing the fixes for those defects.

- Support - The support team supports the customers who buy the software. They field questions from the customers, and provide feedback on defects and enhancements for repeating this whole process for the next release.

I have worked in every phase of the software development process, and in 1992, I discovered that my real calling is software testing. I love trying to break software, and I'm very detail-oriented, and that's critical in software testing. Plus, I think that my experience as a developer adds value to my testing. I've always prided myself in writing defects from a developer's viewpoint, so that the bugs are easy to understand and to reproduce without too many questions slowing down the process. Paraphrasing from what I once heard a baseball player say, "God made me to be a software tester, just not a very good one."

I recall hearing a story from some IBM veterans early on in my career at IBM, and it really stuck with me. The story had to do with the development of the IBM 360 system. As with most new products, the development team kept having trouble--finding too many defects, missing deadlines and dates promised to potential customers, etc. Well, management finally made a decision: Whenever the number of open defects dropped below 1,000 known software bugs, they would release it, and they did. This always amazed me, that they would take such a risk. I believe that this story always motivated me toward the software testing side of the business--to help ensure the utmost quality in our products.

Anyway, from 1992 to 1995, I stayed in the software development laboratory as a software tester, although during this time the lab moved from Westlake to Southlake. I excelled in software testing, including successful testing of products such as Address Synchronization/2. However, I faced a couple of big problems:

- Because I was at the Advisory level, I was called upon to be the team leader for testing teams, and I did not excel at leadership. My strength was in software testing, but I wasn't allowed to do what I was best at, and what I enjoyed. I have always performed best as an "individual contributor," in the most literal sense of that phrase.

- Microsoft was clearly beating us. We were still creating software and just throwing it away.

(back to the Table of Contents)

My Escape to Nowhere (skip to next section)

In late 1994, I made a business decision. In my view, the writing was on the wall for the Southlake lab. Microsoft had defeated us, and the company would not be able to afford to keep throwing money away on OV/2. I decided to look for another job, internally within IBM. Although the course I took had problems in itself, I will always look back on my decision to leave the Southlake lab as the right decision. Shortly after I left, later on in 1995, the lab was indeed closed down, abandoning any further efforts on the OV set of products.

(back to the Table of Contents)

The Beginning of the End (skip to next section)

There had always been another perk with the deep traditions at IBM. Each employee was given considerable flexibility in defining his own career path. Upon taking a new job within the company, he was expected to spend a reasonable amount of time in that job. Then, after doing so, he was free to look for another job within the company. So, far, I had been changing jobs within IBM about every four years, probably about the average for IBM employees at that time.

My new job was in Irving, just down the street from my house. I was the team lead for a small, but growing, software testing team. Our software product was one used only internally by other IBMers (marketing and sales personnel) in tracking hardware and software sales. The demands of my job were once again more for leadership than for the software testing that I enjoyed so much. My duties included building a team of testers (mostly contractors); i.e., interviewing, and making recommendations for hiring, firing, and performance evaluations. Still, my job rolled along pretty well for about a year, with very little interface with management, which was a break in the normal tradition at IBM, where each employee developed a close relationship with his manager. I really didn't even think that anyone noticed me much, but that was all about to change.

One day in 1996, I got a surprising phone call from a high-level, but technical, IBM executive who considered himself to be a QA expert. I knew him by reputation only. First he belittled me for not making / saving IBM anywhere nearly as much as he had. Then he abruptly told me that I had a new manager, in another division of the company, and that I was to report to her office the next day. Well, OK. I had often had managerial changes, and they usually came by way of a seemingly abrupt announcement, but there was usually very little change in my day-to-day duties and expectations.

I reported to my new manager's office on a Thursday afternoon for what I thought would be a get-to-know-you meeting. Instead, the whole meeting was a surprise and a blur from the beginning. The best word for describing my new manager's attitude was "curt." She didn't politely welcome me into her office. She simply laid down the law to me, without explaining the reasoning behind anything she said, and without welcoming any questions.

She simply told me that I was no longer the test team leader on my current project, because I was needed more urgently on another project. This was effective immediately. (This was another anomaly because changes within the company had usually been by way of smooth and lengthy transitions.) I was now a testing consultant on a marketing and sales team, and I was to prepare for life on the road. I was to meet up with my new team on Monday morning, in California, and work with them there for the next three weeks on our first project. It was such a blur that I cannot now recall whether it was in the LA area or in the Bay area.

I remember asking whether or not I had a choice in the matter, and being told that I didn't. In other words, I believed that my only recourse was to leave the company. Looking back, I still don't know for sure what I should have done, since one's first-line manager was always his go-to person at IBM. I probably should have taken the issue to upper management as an infringement upon one of IBM's five Basic Beliefs--Respect for the Individual, but I didn't want to make waves, especially in the "new" IBM where full employment no longer prevailed.

So, I did as I was told. I was already in California before I even figured out what my job was. The IBM Services Division was creating software for utility companies, and our first customer was PG&E (Pacific Gas & Electric). I was on a team with five other people--a marketing guy, a sales rep, etc., and I was the testing consultant. Now, I wasn't sure what a testing consultant was supposed to do, and I didn't know how utility company software was supposed to work. Nevertheless, I was supposed to help sell it to PG&E by showing them how we were going to perform integration and system testing on our software, in their shop.

Now, imagine yourself, whether an IT person or not, in my shoes. As you're reading this, you have about as much information about my new job as I had. I was absolutely clueless. I had no training in how to be a consultant, in the utility industry, or in our (potential) software; and, I knew that I wasn't a good salesman. I suddenly felt like a country dog in the city, either giving a (clueless) presentation to the customer, or locked in a hotel room with five IBM sales people working on a "team" proposal.

Well, I don't remember it all too well, but I believe that the travel part turned out not to be as bad as I expected. After a few weeks (and I don't know how many customers) later, my job somehow materialized into staying in our Dallas office and supervising dozens of people that I didn't know who were either testing or actually using our utility-related software that I knew nothing about, with no support from management. Occasionally I would get freed up from supervising long enough to look at the software and try to find a couple of defects. However, most of my time was spent just hating my job and not wanting to come to work in the mornings.

I guess I'll never know what really went on with all of this. All I know is that it jolted my confidence in IBM. I knew that I had to change, or I'd go crazy. However, I just didn't know what to do. The IBM culture had been turned upside down. It was no longer a place where I could enjoy my job. It's like I couldn't think straight (and the year of 1995 had been an incredibly tough year for me in my personal life--emotionally draining--from just about every perspective). I was desperate for a change, but there seemed to be very few options in the new IBM. In early 1997, I made all of the internal contacts that I could think of, I had a couple of interviews, and I ended up accepting a job in software support, working for Randy Stone, an old friend from the lab.

(back to the Table of Contents)

Software Support (skip to next section)

Now, you heard me right--software support. Remember? That's where I had to: "... support the customers who buy the software, and field questions from them, etc." That's in addition, of course, to being a team leader of other support folks. Does that sound like me? I wasn't given any time for training, and it was a nasty and explosive situation which seemed to be feeding on itself daily. How does one answer questions from customers (to their satisfaction) concerning software that he doesn't understand? How does he leverage the knowledge of his subordinates without looking like a fool himself? Furthermore, how does someone without real leadership skills actually lead a worldwide team of 14 support personnel scattered from Dallas and Austin to Belgium and Tokyo?

(Notice how the first part of this article is much more detailed than this last part. That's not intentional. It's just that something, at this point in my career, was preventing me from knowing, learning, and remembering the details of my own job like I did earlier in my career, and there simply aren't many of those details to recall. One of my problems was that I was just too good at "faking it.")

So, what was the problem? I was supporting a product that was later called WebSphere, IBM's strategic platform for building applications on the internet. All of our products were now being written using object-oriented (OO) programming languages, such as C++ and Java. Now, remember when I mentioned that I excelled in using "top-down" structured programming languages? Well that's about the opposite of what OO languages are. They just never made sense to me, and I never had the proper training for them, or something was preventing me from learning. To me, OO languages were like good programming languages gone bad. As a result, most of our customers who called me with questions already knew more than I did. How much less comfortable do you suppose I felt when my subordinates would ask me questions? So, what should I do? My answer was, "Travel." If you're on the road, then nobody can track you down to ask you about something that you know nothing about.

I was so out of my element. In June, 1999, I even had to serve as the moderator for an "All Things Java" webcast. I broadcast the event from a satellite center in Dallas. There were 681 attendees, and I fielded live questions from many of them (by myself), and somehow I got through it, but not without much pain and anxiety.

So, I began leveraging my situation as best I could, basically by "leaving" instead of by sticking around to be embarrassed about all the things that I didn't know and couldn't do. Although I couldn't justify international travel, I did keep the airways busy every week, mostly to Austin (where most of my team members were) and Rochester, MN (where the software was being developed). I also attended all of the seminars I could (like useless Java One road shows in San Francisco, and marketing events in Las Vegas), just to get out of the office.

(back to the Table of Contents)

The Peter Principle (skip to next section)

So, what had gone wrong? Well, there's an old axiom called "The Peter Principle," but I had never taken it seriously until looking back at this point in time. It says that one tends to get promoted to his level of incompetence. In other words, we all have limitations in what we can do, but we keep striving for promotions. We become so good at getting those promotions that we suddenly find ourselves promoted to a level where we can no longer perform our job duties. We rise to the level of our incompetence.

At about this time, I had a friend who worked for the Post Office. Like myself, he was detail-oriented and technical, but he received a promotion to a management position. After just a few days in the job, he asked for his old job back, and they chose someone else to take his management position. Now, this is probably what I should have done that first day in the late 1980s when I was approached about being a team leader. I should have said, "No, please just let me stay in my technical job that I enjoy. In fact, you can take back my latest promotion to the Advisory level, and the salary increase, and I'll just be a Staff programmer for the rest of my life." However, I was not as wise as my friend.

I learned an important lesson through all of this. Employers and employees do not put enough emphasis on making sure that each employee likes his job and looks forward to coming to work every day. Although change is inevitable, not enough is said about the gratification that the employee receives when he stable and contributing at a high level. He's not worrying about his job, his work is challenging, and he is happy. Instead, employers are constantly looking for "new opportunities for growth and learning" for the employee, as well as "preparing" him for his next promotion by pushing him out of his (productive) comfort zone. My pet peeve is an employer who insists on change even when the employee is stable, happy, and getting good performance reviews for a few years. Instead of letting him keep using the expertise that he has built up in the last few years, his employer wants to change everything (which usually means adding more recurring meetings you his calendar).

For example, instead of letting an "individual contributor" do the things he does best, his employer insists that he take on more leadership roles. This often ends up with the employee having to learn a new set of skills instead of continuing to utilize the skills that he has built up in his current job. This, in turn, finds the employee doing things that he doesn't enjoy and that he's not good at, which ends up hindering his own performance and his team's productivity. I'm all for learning new things and new challenges, especially in the ever-changing high-tech world. However, employers should understand that it's best for the employee, as well as the company, to keep employees productive, happy, and doing what they do best.

(back to the Table of Contents)

A Career Change (skip to next section)

So, I left IBM on July 17th, 2001 after 24-and-a-half years of service. (However, I'll always be an IBMer at heart.) I accepted a partial pension and a generous severance package. I was indeed fortunate to start collecting this pension because IBM terminated its retirement program in 2007. But, you can't retire on a partial pension, so what do you do? My answer was: You have no other choice. You haven't reached your goals, so set new ones, maybe with lower expectations, which is the best you can do. What about just enjoying your work? You pull yourself up by your own bootstraps and start fresh; i.e., maybe at a lower level. I was 45 years old, didn't have a job, and didn't know how to look for one. So, I started learning.

(back to the Table of Contents)

Resumes (skip to next section)

First, I had to prepare a resume. Come to think of it, this was the first time in my life that I had ever really needed a resume of my IT background. I had always maintained an internal resume within IBM, but I had never sent an external resume to anybody.

(back to the Table of Contents)

A Side Note - My History of the Internet (skip to next section)

Toward the end of the last century, my focus (as well as that of most other software engineers) turned to the internet. I had started using personal computers in the early 1980s, but most of my training was on my own--not from IBM. I started using Microsoft Windows in about 1990. It was the old 3.0 version that the user had to initiate from DOS. I first used the Internet (World Wide Web) in the early 1990s, using Internet service providers AOL and Verizon (Southwestern Bell / AT&T). This was a slow and laborious process, using a 32 bps dial-in modem, and either no browser at all or primitive browsers like Mosaic and NetScape. At that speed, downloads took forever, even to populate the first web page. I would set the browser to not download images so that the pages would load more quickly.

I soon learned that the Internet is a global system of interconnected computer networks that use the TCP/IP (Transmission Control Protocol / Internet Protocol) protocols for connectivity; HTTP (Hypertext Transfer Protocol) and HTML (HyperText Markup Language) for Web browsers; and, FTP (File Transfer Protocol) for uploading content. I learned enough about it to build my own website, and I was always an avid student of the Bible. So, I built my website, Christian Data Resources, on the verizon.com domain in 1997 where I published articles on Bible study and answered Bible questions from visitors. In 2008, I purchased my own domain name and transferred my website to http://www.christiandataresources.com. There are a lot of sites that enable the user to build a website, on their domain. However, in order to build a site from scratch on my own domain, I had to learn about:
  • Domain names - I got mine from GoDaddy.com.
  • Web hosting - Again, I used GoDaddy.com, for convenience.
  • HTML - I built all of my pages by hand with a text editor, or with a simple page editor (NVU). This included HTML Title, Meta, and Keyword tags, in order to be recognized by search engines, as well as linking structure (internal and external).
  • FTP (File Transfer Protocol) - For uploading files to the site.
  • Google Webmaster Tools - To let Google know about the site and to guard against cloaking, spamming, hidden text, link farming, etc.
  • Submitting links to search engines
  • Continually adding content
  • Wordpress - I use it for a blog.
  • Backlinks - This is trying to get other (hopefully popular) sites to link back to the new site.
  • Search Engine Optimization (SEO) - Tricks to make the site rank higher in search engines.
  • Google Adwords - Pay-Per-Click (PPC) online advertising for the site. Actually, I ended up using Bing Ads because they're cheaper.
  • AdSense - This is trying to make money by posting ads for other sites. I have since discontinued this because it seemed counter-productive due to the nature of my site. I like for everything to be free, with no ads, etc.
  • Google Analytics - To track site traffic, downloads, etc.
  • (Later) Mobile-Friendly Websites - To make my pages device-friendly, etc.
(back to the Table of Contents)

Mitchell, International (skip to next section)

I sent my resume (with the appropriate letters and applications) to about 150 companies. Then I started driving around the city where I lived (Coppell, TX), finding large and small businesses and knocking on doors. One day I saw a "Now Hiring" sign in a strip center. I carried my resume in and inquired. I found out that the company was called HNC, a small (and private) medical (Worker's Compensation and Auto) bill review company (although I didn't know what that meant) with about 1,000 employees. (HNC would later be bought by Fair Isaac, and eventually by Mitchell, International.) The HR rep seemed impressed with my resume, and she quickly got me two interviews. Within a week, they called me with an offer to be their EDI Coordinator. Again, I didn't have a clue what this meant--just something related to IT. They offered a starting salary that was only about 40% of what I was making at IBM when I left. After some negotiation, I accepted the job, but I was still making less than half of what I made at IBM.

So, I had found both jobs in my career (with IBM and with HNC) without the benefit of nepotism. Although there is much value in networking (in which I have very few skills), I had always been proud that I was able to find my jobs simply by approaching strangers in companies where I had no inside contacts.

(back to the Table of Contents)

EDI Coordinator (skip to next section)

I began my new job on September 10th, 2001 (yes, the day before 9/11). I remember taking a trip to St. Louis within the first couple of weeks because we were transferring an office from there, and the current (leaving) EDI coordinator worked there. Due to 9/11, there were hardly any other air travelers in the airports or on the planes.

Here's how medical bill reviewing works: Bill review companies or insurance companies bought or leased our SmartAdvisor software (named CompAdvisor at the time), or they hired us to do their medical bill review for them, for their Worker's Compensation and/or Auto claims. Insurance companies sent in their claims and related bills. The SmartAdvisor software applied all appropriate fees/discounts according to each jurisdiction (state laws), PPOs, etc., and it returned an Explanation of Review (EOR) or Explanation of Bill (EOB) to the insurance company. In some cases, the bill review company also handled invoicing and payments to providers (doctors, hospitals, etc.) Most claims and bills were automatically scanned into the system, and many bills were processed completely automatically by SmartAdvisor. In some cases, pended bills, or audited bills, needed manual attention from a bill review specialist or a nurse. In return for our software and/or services, our company received a fee for each bill reviewed, or an amount for the sale or lease of SmartAdvisor.

At the end of each day, data was exchanged between our company and the insurance companies through a process called EDI (Electronic Data Interchange), via FTP processes. For us, this included importing (receiving) claim files and bill files with the latest information, and exporting (sending) payment files to the insurance companies. In addition, imports and exports were also required for each individual PPO.

My new job with HNC was to coordinate these imports and exports. The intent was that I would initiate these jobs in the evenings and they would run automatically overnight. However, there were a lot of caveats (shortcomings in the software, etc.), so I often needed to write Java programs to fix mistakes, add or subtract fee amounts, etc. In addition, I created automation programs to launch the EDIs automatically. I excelled at this job, and received above average performance evaluations.

(back to the Table of Contents)

Back to Software Testing (skip to next section)

In 2002, Fair Isaac bought our small company, but my day-to-day duties remained basically the same. I enjoyed the challenge, but I often worked long hours, well into the evenings and nights, probably 60 to 80 hours per week. In 2005, I transferred into the Quality Assurance department for testing SmartAdvisor software. The SmartAdvisor development organizations were based in Irvine, CA, so I made a couple of trips to Irvine. I was now (finally) back into the area that I loved--software testing. In 2006, I had another stroke of luck. We developed a new product called SmartReports, and I became the primary person for testing SmartReports. This was exactly what I loved doing. SmartReports generates reports from the SmartAdvisor SQL databases using the same relational database SQL query language that I had used some 25 years earlier on the IBM ADF project. I loved testing the reports and comparing the results to SQL queries against the databases. I created defects as necessary, then tested the defect fixes. As the last group to touch the software before each release, QA is ultimately responsible for customer satisfaction with the quality of our products. I took pride in my work and I believe that I was very effective at it.

In 2003, I began suffering from cold and painful hands whenever I used the computer. I was diagnosed with Raynaud's Syndrome, and I had to cut back to part-time for a couple of years. However, for the past ten years, I've been working full-time again, controlling the Raynaud's by wearing gloves while I work, by limiting my time on the computer, and with medication.

(back to the Table of Contents)

A Side Note - Back to the Shuttle (skip to next section)

On February 1, 2003, we lost the space shuttle Columbia on its 28th mission (STS-107) resulting in the deaths of all seven crew members. This was the space shuttle that I had programmed for in 1981. It was almost home, already in the descent phase, and again I could envision the maneuvers of the ailerons and rudder as it was preparing to land. The space shuttle program ended with the last flight of the shuttle Atlantis, STS-135, on July 8, 2011. Every time one on those 135 missions ensued, I wonder how much of my software code was still being used for navigation and flight control.

(back to the Table of Contents)

Back to Mitchell (skip to next section)

In 2008, Mitchell International bought our SmartAdvisor division from Fair Isaac. SmartAdvisor was a better fit into the Mitchell organization, and we were growing and thriving there. In 2011, I had my 10th anniversary with Mitchell (/ Fair Isaac / HNC). Although I had worked for three different companies, I stayed basically in the same place for these ten years. In 2008, I began working from home every day, and I enjoyed this perk tremendously. Travel for Mitchell included trips to Irvine, CA, and a trip to San Diego for a software development seminar.

In April, 2012, Mitchell converted their software development methodology from "Waterfall" to "Agile," like most companies were doing. (I had been used to the Waterfall approach where the Business Analysts (BAs) prepared specification documents from which to test.) The adjustment was awful. I called it DSP (Developing by the Seat of your Pants). There was no documentation, but there were plenty of meetings every week:

- 5 Daily stand-up meetings - supposed to be 15 minutes each, but really 30 minutes to an hour (5 hours)
- Story grooming meetings - basically watching the product owner type (2 hours)
- Release planning meetings (4 hours)
- Sprint planning meetings (2 hours)
- Sprint retrospective meetings (2 hours)
- Demo preparation meetings (4 hours)
- Demo meetings--for all scrum teams (4 hours)
- etc.

The demos were a lot of trouble, showing what we had built to an indifferent audience. And the daily stand-up meetings drove me crazy. We were supposed to stand up, tell what we did yesterday, tell what we were going to do today, and list any roadblocks we had. It was like I was in grade school again. It made me so nervous that I had to rehearse what I would say. I often wanted to say, "Yesterday I went to meetings, today I will go to meetings, and my roadblock is too many meetings."

Sometimes I had eight or nine meetings per day. I found that instead of working 40 hours per week, I was working 55-to-60 hours in order to accommodate the extra 15-to-25 hours of meetings. I know to never say "never," but I will do my best to never put myself in that situation again. Of course, some meetings are really necessary, but in general I don't particularly like meetings, mainly because most are not necessary. I don't like the boredom of the meetings and I don't like having the attention of the group focused on me (because of my fear of embarrassment, etc.). I'm a software tester--not a meeting attender.

(back to the Table of Contents)

Brink's, Inc. (2012 - 2014) (skip to next section)

So, after suffering through a few iterations of two-week sprints, I felt desperate to find another job. I left Mitchell on June 29th, 2012, and I joined Brink's, Inc. as a QA software engineer on July 1st, 2012. They had tried Agile and they had decided to go back to Waterfall. I had fun testing and I felt productive for about a year-and-a-half, mostly testing CompuSafe (intelligent safe) software. Then a new sheriff came to town in the form of a QA director. He basically brought all of his own people in (dozens), and tried to run the existing team off by making life miserable for us. He was successful, as nobody wanted to work for him anyway. One-by-one we started peeling off.

(back to the Table of Contents)

HealthSparq (2014 - Present) (skip to next section)

I had several interviews with Thomson Reuters until the QA manager confided in me that he was leaving the company. My only other lead was through a former QA person at Brink's, Manjula Muniyappa. Her husband, Santosh Ramakrishna, was a development manager and he had recently moved to a startup company called HealthSparq, a subsidiary of Cambia Health Solutions. They were developing software to inform and empower health care consumers through an online shopping experience that helps them understand their options, make better choices, and learn more about the advanced solutions for health plans and employers. They're based in Portland, OR, but due to an acquisition, they now had an office in Lewisville, TX. I had a phone interview with Randy Pellegrini, the QA manager in Portland, and then an additional interview with Santosh and team members at their new location in Lewisville.

The job was the team leader of a one-person QA team. It sounded like a match except that they used Agile. However, they convinced me that their Agile approach had been honed down to be more efficient and have less meetings. I took the job, partly because I looked forward to it, and partly because I was so miserable at Brink's.

My last day with Brink's was on October 3rd, 2014, and I started with HealthSparq on October 6th, 2014 as a senior quality analyst. My first month there was rough. The learning curve was steep and the onboarding process was lacking. Furthermore, my father-in-law went into the hospital on October 13th, spent three weeks in the hospital and a nursing home, and died on October 31st.

My new job included testing web services (APIs) which I knew nothing about. Finally, Tomomi Ioffe, one of the QA people in Portland, tutored me for an hour or so, and I was on track. I learned a lot, I enjoyed my work, and I got to work from home two days per week. I even adjusted to the Agile way of doing things. I still had some days with eight or nine meetings, but they became fewer and further between. And, I still rehearsed what I'm going to say at the daily stand-up meetings, as well as the demos. However, the adjustment to Agile was easier for me at HealthSparq than it had been at Mitchell. I think this was because I was getting in on the ground floor of a brand new product: the Admin Console.

By 2018, technology was changing again. This time it was to automation, with Behavior Driven Design (BDD), Test Driven Design (TDD), Cucumber scenarios, and step definitions in the Ruby programming language. Automation was one of the reasons I left Brink's, and it would play a part in my leaving HealthSparq as well. Automation meant that HealthSparq changed my job role form Quality Analyst (QA) to Quality Engineer (QE). It doesn't sound like a big change, but the new technology was a major change that would take years to master. I was 63 years old and I could collect Social Security, so, on August 3rd, 2018, I retired, after 42 years as a software engineer.

(back to the Table of Contents)

Accomplishments (skip to next section)

Software Patents

During the early 1990s, I became heavily involved in writing software inventions and patents for IBM. IBM provided financial incentives for employees to come forward with new ideas, although, according to an agreement when I was hired, IBM was the owner of all resulting inventions and patents (Re. revenue, etc.). I was just the inventor / author. I had a lot of new ideas, and I had some 300 articles published in IBM Technical Disclosure Bulletins. In addition, I had the following ten patents granted by the U.S. Patent Office:

    Number       Title
- 5,600,828 File specification wildcard (First Invention)
- 5,664,063 Automatic user notification of certain meeting attributes
- 5,682,475 Method and system for variable password access
- 5,694,616 Method and system for prioritization of email items by selectively ...
- 5,761,420 Method and apparatus for telephone proof of documents
- 5,787,231 Method and system for improving pronunciation in a voice control system
- 5,878,230 System for email messages wherein the sender designates ...
- 6,230,121 Measurement and validation of interaction and communication
- 6,321,378 Automated code replication during application development
- 7,155,493 Method and apparatus for improved internet navigation (Patent)

You can view these only by searching at http://patft.uspto.gov/netahtml/PTO/search-bool.html for Inventor Name = "Weber" and Inventor City = "Coppell". My inventions on the U. S. Patent Office site: Inventions.

(back to the Table of Contents)

Certifications (skip to next section)

Throughout my years as a software engineer, I earned the following certifications:

- 1997, IBM Certified Professional, Integration and Test Specialist, IBM
- 1998, Certified Java Programmer, Sun Microsystems (Java_Certification)
- 1999, WebSphere Application Development Certification, IBM
- 2008, Certified Software Tester (CSTE), The Quality Assurance Institute (QAI)
- 2010, Re-certification as a CSTE (through 2014), QAI

(back to the Table of Contents)

Summary (skip to next section)


What changes have I seen? The changes in technology have been unreal. As I mentioned, from 8K of memory on the slow computer that ran my whole college 40 years ago, to 8B of memory on a laptop or a phone today.

Office attire has changed from a dark suit, white shirt, and tie every day to shorts, tank tops, and flip-flops.

Plus, working from home is a great perk.

(back to the Table of Contents)


So, where am I on achieving my goals?

- I fulfilled a childhood dream of working on the space program.

- I made the Advisory level with IBM after just eight years.

- At one point, I attained the private office that I had always wanted, only to give it up when times got lean at IBM, working instead in tiny cubicles, or in large "bull pens" with 25 other people. I never had a private office again until I started working from home. Maybe that's why I like working from home so much.

- I wanted to be a member of IBM's Quarter Century Club, but I fell short of that by only six months.

- I wanted to retire from IBM with full benefits after 30 years of service, but I fell short of that goal by five-and-a-half years.

- Instead, I retired on August 3rd, 2018.

Owen Weber 2018