My Career as a Software Engineer

January 24th, 2016 will mark my 39th anniversary as being a software developer. This article documents the highlights (and lowlights) of my career.

Formal Education

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. 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 was intrigued by the brief "Computer Science" category in the course catalog, although I really had no idea what it involved. 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. The idea of taking a computer science class was probably suggested by one of my math professors or by a fellow student.

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

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 what we had in college.

The entire computer lab was in a single room with probably 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 CPU (Central Processing Unit), the auxiliary storage, 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 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.

So, when I wanted to write a computer program, I would 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 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 go to 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 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.

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

On the other hand, if the compiler detected an error in my program (which was usually the case), it would print a crude error message on the printer. I would then find the card that caused the error (in my huge stack of cards), type a new card, and replace the old card 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.

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 COBOL - A business-oriented programming language
Assembler - A low level programming language
Courses in RPG - Another business-oriented 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 letters and transcripts to various companies. Several companies were immediately interested, and I had early interviews with the following:

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

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. I had ruled out Burroughs because we didn't want to move to Michigan, 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. I was nervously waiting to see if I would receive an offer from IBM (my first choice). I had two letters prepared for Phillips--one accepting their offer, and one refusing it. Finally, at the last minute, IBM made me an offer as a scientific programmer, and I accepted. I would start with IBM in Houston on January 24th, 1977 for a salary of $263 per week (approximately $13K per year).

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. 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. I remember interviewing with one manager named Sol Solomon, and he helped me to understand more about what I might be doing, but I still had no idea what would be involved, or what it would be like to work for a large company.

Houston

I moved into an apartment in Nassau Bay, TX, just outside of Houston, right next to a bay off the Gulf of Mexico. 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.

IBM was apparently quite 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).

IMUs

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. 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 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--basically pseudo code. So, simply by knowing the PLS programming language (a 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 our program on their mainframe computers (in a stand-alone environment) and send back (via courier) our 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. We would typically get only one chance each day to run our programs. 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.

Flight Control

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. (I don't know what was so difficult about it. It wasn't rocket science. Oh, yeah, it was.) 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 in 1/25th of a second from now.

Each mission consisted of three phases--ascent (liftoff), orbit, and descent (re-entry into the atmosphere); and, the flight control tools utilized depended upon the mission phase. During liftoff, our code would send controls (3-D vectors) to the SRB engines and the main engines 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 OMS engines. 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.

I 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 entered the atmosphere from space. The point of concern was the glue that held the tiles on 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 when communications between the shuttle and the ground are not possible. I remember how relieved we were when we once again heard the astronaut's 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.

Scarce Resources

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

4146FF40

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, the programmer would be called upon to make another 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, and I used it in my program development.

The First Space Shuttle Mission

One of my greatest challenges was serving on the real-time software support team. Behind the mission control room at NASA was a smaller room for software support. During simulations and real missions, we manned that software support room, and we were at the beckon call of mission control, if any question or problem came up concerning the software. 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 flight director's voice in my headphones saying, "Software?"

In fact, this actually occurred during the first mission, STS-1, as the Space Shuttle Columbia sat on the launch pad with John Young and Robert Crippen onboard. I had worked for four years (with 800 other IBMers) in anticipation of STS-1, scheduled for March, 1981. I was in the software support room behind mission control when I heard the countdown for launch, "T-15 (i.e.,'T minus 15 seconds'), T-14, T-13, T-12, T-11, T-10...," but then I didn't hear "...T-9..." Something had gone wrong and the mission had been aborted only ten seconds before the main engines were supposed to fire. Everyone at NASA was nervous, and sure enough, I heard the Flight Director's voice frantically saying, "Software?..."

We feverishly began looking at memory dumps, paging through software, etc. As it turned out, there was, in fact, a software error, but it was in the system software, thankfully not my area. The error had been coded by one of my colleagues, and he also supplied the fix. However, it took a matter of 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 no sleep).

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 Robert Crippen when they came to our IBM facility for a presentation. On another occasion, I traveled to Rockwell, International (who built the Shuttles) in Downy, CA to meet with some astronauts about some specific software concerns that they had.

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

The IBM Culture and Advancement

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, we 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.

Tradition

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

Diversity

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 and white shirts.

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 engrained with related education, including programs such as Equal Opportunity, Affirmative Action, and Diversity.

However, the rightful advancement of these diversity programs came at a cost. When the current workforce was comprised primarily of white males, how could the hiring and promotion of employees become more diversified without discriminating against some white males?

Suppose that two people were competing for the same job opening or promotion--a white male, and a black female. The federal government was keeping close tabs on diversification trends, especially in large companies. Now suppose that the white male was better qualified for the position than the black female. After all, it would be no surprise if this were the case, since the white male had probably been more likely to have received training, job experience, etc. However, with continuous pressure from the federal government to become more diversified, company executives and managers were sometimes forced to hire or promote the lesser qualified candidate.

Since I was a white male (and during almost all of my time at IBM I was under the age of 40), I sometimes questioned whether or not reverse discrimination was an issue. It's difficult to say for sure, especially since much employee information is confidential, but I believe that I was passed over for promotion in this respect on at least one occasion, and I didn't receive a fair performance evaluation on a few occasions. Still, there was probably no way to become diversified and still be fair to everyone. Regardless, I'm proud to have been a part of the diversity movement that contributed to the advancement of minorities and women in the workplace.

Goals

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.

Retirement Planning

Another goal had to do with retirement planning. When I joined IBM, I was quite ignorant about IBM's benefits plan. I may have known that my new benefits included some type of medical benefits, and a vacation plan, but that's about all. However, as soon as I joined the company, I started receiving occasional memos about all of the benefits, so I soon learned more about them.

One of the things that seemed very appealing was their retirement plan, including a full pension upon retirement at the age of 65. In fact, during these first four years with the company, they were improving the retirement plan every year. First, they reduced the retirement age to 55, although this early retirement did decrease one's pension amount, on a graduated scale. Then they stopped decreasing the pension amount for early retirement, and they would pay a full pension at age 55, as long as the employee had 30 years of service with the company. Next, they allowed full retirement after 30 years of service, regardless of one's age, and this meant age 51 for me. Although I wasn't giving much thought to retirement at my age (21 when I started), it did seem like a good incentive for me to stay with IBM as a loyal employee.

Full Employment

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/her performance evaluations, he/she didn't have to worry about losing his/her 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.

Dallas

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. 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 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 call ADF (Application Development Facility). It enabled our customers 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), with SQL (Structured Query Language) relational databases. I programmed in the PL/1 language, another fourth-generation language.

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 employees (at least in the U.S.). So, I sent my first e-mail in July, 1981. We each had a crude, huge, heavy, black-and-white (green) monitor on our desk (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, we also wrote our programs electronically via this terminal, so I no longer had to use stacks of Hollerith 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 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, I only took two days off. She died on a Thursday night, and we drove to Oklahoma after work that day. 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.

Another Note about Retirement Planning

By 1985, I had eight years with the company, and I had made a big dent in my goal to retire after 30 years. In fact, the good news kept coming about the retirement program. It kept getting better and better, in the way they calculated the retirement benefits, etc. They were now even offering something called Social Security Leveling, for employees retiring before the age of 65. The idea was to balance one's income over the course of their retirement years, instead of having a big disparity of income once Social Security kicked in. IBM would estimate how much one's Social Security payments would be once they reached the age of 65, and they would make up the difference such that one's income would remain the same once they turned 65.

For example, suppose that an employee retired at age 52, and his IBM pension was $1,200 per month. They would then estimate what his Social Security benefits would be at age 65; let's say $600 per month. So, from age 52 to 65, they would increase his pension benefits to, maybe $1,600 per month. The only caveat was that when the employee turned 65, they would reduce his pension to, say $1,000 per month, but he would then collect his $600 per month from Social Security, for a total of $1,600 per month. So, it worked out good for both parties.

In addition, a couple of things were starting to happen at IBM which seemed like great news, although I just wasn't smart enough to see the writing on the wall. Starting in about 1984, IBM began encouraging many of its older employees to retire. IBM was nice, right?--wanting to see its veteran employees being able to take advantage of all the retirement benefits? In fact, year after year, they were giving more and more incentives for older employees to retire. By 1988, they were giving veteran employees as much as two years’ salary for retiring. I remember one man telling me, "They kept throwing so much money at me that I had to retire. It just didn't make any sense not to retire."

Another thing that happened in 1984 was a new voluntary benefits program called the Tax Deferred Savings Plan (TDSP). Many companies were starting similar plans, and they're what we now know as 401-K plans, with at least partial matching from the company. So, an employee could even add to his own pension by saving some of his own money, plus more from IBM. Everything about this sounded good too: "Tax -deferred" sounded good; "savings plan" sounded good; "voluntary" sounded good; and, "matching" sounded good. (Retirement Planning--To be continued, below).

ISEN

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 the 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, 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.

Although the concept is 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 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 now recall, it seems like I would go 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.)

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. I could envision the roll, pitch, and yaw maneuvers of those main engines as it exploded.

Back to Development

For whatever reason, in 1988, I decided that I wanted to get back into software development. It was relatively easy for me to find a job. 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 OS2, and it was now going to develop a complimentary office product called OfficeVision/2 (OV2). 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 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 the job, and we felt like we had it made. 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.

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.

More on Retirement Planning

In about 1989, IBM announced the latest improvement in the retirement plan: There was an extra bucket of retirement for everyone--the PMP bucket (I forgot what the acronym stood for). IBM was simply going to contribute an extra 6% of each employee's salary to this extra bucket every year, and it would simply be more money for us future retirees to retire on.

Reversing Course

Meanwhile, little by little, and somehow almost unnoticeably, IBM began losing money. (This had been IBM's incentive for cutting costs by encouraging employees to retire.) To employees, the quarterly earnings statements didn't mean much. 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.

Well, suddenly, by 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 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.

- The PMP plan for future retirees, announced only a couple of years earlier, was being 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 employee 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 (I had 15 years at the time), with no pension or anything. 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.

Software Testing

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 includes several phases which may be generalized as follows:

- Requirements - Gathering 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.

- Testing - The Quality Assurance team performs function, integration, systems, performance, and regression testing, creating necessary defects 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 in software testing. I love trying to break software, and I think that my experience as a developer adds value to my testing. I'm very detail-oriented, and that's critical in software testing. 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.

Software Patents

During the early 1990s, I also 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. I was just the 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 patents granted by the U.S. Patent Office:

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

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 exceled 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 team leadership. My strength was in software testing, but I wasn't allowed to do what I was best at, and what I enjoyed. (See more on the Peter Principal below.)

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

My Escape to Nowhere

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.

More on Retirement Planning

Throughout the 1990s, IBM continued to cut retirement benefits. They made cuts in the way pensions were calculated and in how one's number of years of service contributed to the calculation; they simply cut the amount of one's pension; and, they cut other retiree benefits such as health care. As these announcements were made, year after year, I couldn't help remembering back to a time in the mid-1980s when IBM would distribute brochures boasting about all of the improvements they had made to the retirement plan, year after year.

The Beginning of the End

There had always been another perk about the deep traditions at IBM. Each employee was given considerable flexibility in defining his own career path. Upon taking on a new job within the company, he was expected to spend a reasonable amount of time in that job. Then, upon 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 most employees.

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 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 was told that I had a new manager, in another division of the company, and I was told 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 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 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, but I didn't want to make waves, especially in the "new" IBM where full employment no longer prevailed.

Well, 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. Yet 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, looking back, I was probably suffering from depression (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 an old friend.

Software Support

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 also think that my depression kept me from learning the software that I supported. It was a nasty and explosive situation, and it seemed to be feeding on itself. 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 ability 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 depression was preventing me from knowing, learning, and remembering the details of my own job at this point 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? First, 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 exceled 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 either never had the proper training for them or my depression 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.

The End of a Chapter

Well, if you think this is where the story gets better, think again. I was suffering from anxiety and depression, and IBM never reached out to me. I felt helpless, and I couldn't stand the stress any more. On July 17th, 2001, after 24-and-a-half years of service, I took early retirement from IBM with a reduced pension for the rest of my life. I was 44 years old at that time, and my pension was approximately equal to my starting salary 24 years earlier.

The Peter Principle

So, what had gone wrong? Well, there's an old axiom called "The Peter Principle," but I had never taken it seriously until this point. 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.

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.

Curing Depression with a Career Change

Well, you can't retire on $13K, so what do you do? My answer was: You have no other choice, so you cure your own depression. You haven't reached your goals, so you set newer ones, with lower expectations, which is the best you can do. You pull yourself up by your own bootstraps and start fresh; i.e., at a lower level. First, I filed for unemployment, and then the truth struck me: I was 44 years old, didn't have a job, and didn't know how to look for one; so, I started learning.

Resumes

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. I had always maintained an internal resume within IBM, but I had probably never sent an external resume to anybody. Even when I applied to IBM, that was just a matter of sending a letter, a college transcript, and a completed application form.

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 medical (Worker's Compensation and Auto) bill review company (although I didn't know what that meant) with about 1,000 employees. 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 of $40,000. Now, I'm not a hardball negotiator, but I was coming off a job that paid more than twice that amount. I somehow asked if they could raise that a bit. They offered $45K, and I accepted. I had received unemployment for only five weeks.

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 have always been proud that I was able to find my jobs simply by approaching strangers in companies where I had no inside contacts.

EDI Coordinator

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 buy or lease our SmartAdvisor software (named CompAdvisor at the time), or they hire us to do their medical bill review for them, for their Worker's Compensation and/or Auto claims. Insurance companies send in their claims and related bills. The SmartAdvisor software applies all appropriate fees/discounts according to each jurisdiction (state laws), PPOs, etc., and it returns an Explanation of Review (EOR) or Explanation of Bill (EOB) to the insurance company. In some cases, the bill review company may also handle invoicing and payments to providers (doctors, hospitals, etc.) Most claims and bills are automatically scanned into the system, and many bills are processed completely automatically by SmartAdvisor. In some cases, pended bills, or audited bills, need manual attention from a bill review specialist or a nurse. In return for our software and/or services, our company receives a fee for each bill reviewed, or an amount for the sale or lease of SmartAdvisor.

At the end of each day, data is exchanged between our company and the insurance companies through a process called EDI (Electronic Data Interchange), via FTP processes. For us, this includes 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 are 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 exceled at this job, and received above average performance evaluations.

Back to Software Testing

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--the same relational database SQL query language that I had used some 25 years earlier on the IBM ADF project. I love testing the reports and comparing the results to SQL queries against the databases. I create defects as necessary, then test 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 take pride in my work and I believe that I'm very effective at it.

In 2008, Mitchell International bought our SmartAdvisor division from Fair Isaac. SmartAdvisor is a better fit into the Mitchell organization, and we're 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 2009, I began working from home, and I also enjoyed this perk tremendously. Travel for Mitchell included trips to Irvine, CA, and a trip to San Diego for a software development seminar.

Brink's, Inc.

In April, 2012, Mitchell converted their software development from "waterfall" to "agile." (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 plenty of meetings: daily stand-up meetings (30 minutes to an hour), 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 daily standup 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.

I found that instead of working 40 hours per week, I was working 55, including an extra 15 hours per week of meetings. I know to never say "never," but I will do my best to never put myself in that situation again. I don't like meetings. 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 goer.
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 software engineer on July 1st, 2012. They had tried agile and gone back to waterfall. I had fun testing and I felt productive for about a year-and-a-half until 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.

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. Her husband was a development manager and he had recently moved to a startup company called HealthSparq, a subsidiary of Cambia Health Solutions. They develop software to inform and empower health care consumers through an online shopping experience that helps them understand their options and make better choices, and to learn more about our advanced solutions for health plans and employers. They're based in Portland, OR. I had a phone interview with the QA manager there, and then an additional interview with the development manager and team members at their new location in Lewisville. The job 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 engineer. My first month there was brutal. 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, one of the QA people in Portland tutored me for an hour or so, and I was on track. I have learned a lot, I enjoy my work, and I get to work from home two days per week.

Certifications

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

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 five 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 through medication.

More on Retirement Planning

Meanwhile, back at IBM: In 2007, IBM discontinued its retirement plan (like so many other companies); i.e., employees joining IBM in 2007 or later were no longer eligible for a pension from IBM upon retirement. This seemed very ironic; as 2007 was the year I should have retired from IBM.

Summary

So, where am I on achieving my goals?

- I did make the Advisory level with IBM after just eight years, but that was probably a (Peter Principle) mistake, and I've never had another promotion since then.

- 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. (My, how things do change.) I never had a private office again until I started working from home.

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

- Most of all, I had wanted to retire after 30 years of service with IBM, but I fell short of that goal by five-and-a-half years. I worked so hard through those years, and made it over 80% of the way, only to fall short. Instead of writing about working in a second career for the past fifteen years, I should have retired from IBM nine years ago with full benefits. Now I find myself still making less money than I did fifteen years ago.

So, I had hoped to be fortunate enough to retire at the age of 51. How do I feel instead? Well: Fortunate. I've come to realize that the most important things in my life are faith and family. Concerning faith, I know what I believe (in Jesus Christ), I'm comfortable with it, and I'm ready for the afterlife. Concerning family, I have a wife who has loved me for 38 years, two loving children and their spouses, one granddaughter and two grandsons. Maybe I was just too focused on the wrong goals.

Outside of my career, I traveled to Hyderabad, India in 2000 for a Gospel Crusade, where I preached three times a day, having never preached before in my life. I also maintain a website: https://www.christiandataresources.com, where I write Christian articles and answer readers' questions.

Owen Weber 2015