I have been working as a computer programmer since the dawn of the Information Age. I started as a computer operator and quickly became a computer programmer. In the many decades since then, I have watched the evolution of computing technology unfold before my eyes.
As technology marched onward, older programming languages and systems gave way to newer ones. If you survive as long as I have, the pile of obsolete programming languages grows into a small mountain. I reflect on this mutated mole hill occasionally as I grow older; wondering what lessons I can draw from this slag heap of old code. As I look backwards over the years, I realized that I have learned something important at each step along the way. This posting is a whimsical visit to the “Golden Days of Yester- Year” and a trip down memory lane into the haunts of ancient computing platforms and the programming languages that became their voices. I have no idea where this story will wind up, but I will start simply by exploring each of the programming platforms and languages I have learned and forgotten to see what real lessons they taught me.
I will do my best to humanize this journey and share some of the life lessons I have learned as well. It is my hope that you get a more complete picture of me as a person. For the past 20+ years I have been working on becoming a better man, one day at a time. I have occasionally introduced myself as a “recovering engineer,” and I can assure you that the recovery is not complete.
In the Beginning
In 1967, I was living in White Plains, New York, taking whatever manual labor work Manpower had open that day. Digging ditches was not calling to me, so I went to a local job placement office and learned that they had two job openings. One was for a bank teller at $85 per week and the other was for a computer operator trainee at $75 per week. At that point, I didn’t see myself working in a bank, but computers interested me. I got an interview at Purdue Frederick, a pharmaceutical manufacturer in Yonkers. Jack Ingram was the hiring manager and he gave me a bunch of tests that I dutifully completed and turned in and waited for him to score. An hour later I had the job. I started the next day.
Purdue Fredrick used a Univac 1004 computer to perform all of their core business processes. The version we used had a card reader, a card punch and a printer. Its functions were controlled by a 2″x 2″ wired board. It was quite primitive, but it took up the half the computer room,
Jack turned me over to the operations manager (I can still see his face, but cannot remember his name) who introduced me to the card sorter and taught me to sort punched cards. Each card had up to 90 characters of information encoded in round holes, and they needed to be put into the correct order so the computer could process them. [Quick test: did you notice anything strange about the number of columns in the cards?]
On my second day on the job, Jack came up to me and handed me two Honeywell COBOL manuals and said, “As soon as you learn to program, I will give you a $10 per week raise.” He then proceeded to tell me that I had scored pretty high on his tests. Apparently my scores matched the best scores he had ever seen, so he felt pretty comfortable hiring me, but I had a question.
“What is a program?” I asked Jack. To this day, over 46 years later, I still cannot precisely define what a program is, even though I have written thousands of them. I did, however, get the raise two weeks later.
We were planning to replace our Univac 1004 with a Honeywell 120 with four tape drives, but it hadn’t arrived yet, so I cut my teeth on the 1004 which was a wired board card processor. It had no disk or tape drives and only a small amount of “core” memory. Someone had created a wired board that was actually a simple assembler that made it possible to write simple programs. At this point in the history of computing, the programming was done with the wiring on the boards; so a program that could create other programs was really quite cool. In only a couple days time, I wrote a program that balanced my check book. Each card represented one check or deposit. The excitement I felt at getting this program working faded as I sat in front of the key punch transcribing my check register, and my first lesson emerged: The cost of the solution cannot exceed the value of the result. I spent more time keypunching and re-keypunching cards than it was worth to me. This lesson has been of immense value to me over the years. It explains why people make choices. If one does not know the value of a given result, it defaults to low value; and if one doesn’t know the cost, the default assumption is high cost. These two assumptions keep things from happening and form the basic challenge that sales people face in getting a customer to make a purchasing decision. The customer has to believe that he or she is getting a deal, a result that they value more than the associated cost. All that learning from a simple check-balancing program!
Honeywell 120 COBOL
When the Honeywell arrived, all of the programming was to be done in COBOL. I went to school in Manhattan for a week to learn Honeywell COBOL and came back ready to rock and roll. As a part of the conversion, we had to write a new Accounts Receivable program to track customer invoices and payments. Our Honeywell sales engineer had designed the program and the format of the cards and tape data files. As our keypunchers created thousands of cards reflecting customer payments, I set to the task of writing the AR program. Things progressed well until I was ready to test with live data. Nothing balanced. Since this was my first program, I naturally assumed that the fault lay in my own code. I checked and rechecked my logic to no avail, and eventually realized that the problem may lie in the data itself. Sure enough, the keypunchers has misunderstood how to apply a customer payment that covered multiple invoices and had punched the cards incorrectly. I tried to make changes to my code to work around their mistakes, but could never get the results to balance properly. Eventually my body decided to send me a message that my brain could not seem to hear. I got violently ill and wound up in the hospital for several days. The doctors could find nothing wrong with me, so they sent me back to work. Within 30 minutes of picking up my program listing, I was running a 104 degree temperature, and was ready to learn my second lesson: Garbage In, Garbage Out. There was no possible way to make the bad data produce good results. Unfortunately, I did not learn the “Listen to my body” lesson until many years later.
Once we got the system working, we realized that we had a problem with our billing process. Under the card system if we encountered a problem, we simply pulled the cards out and replaced them with correct ones and reran the billing. But with a tape system, we could not easily remove bits from the tape. In fact, we couldn’t even see the bits on the tape! So Jack asked me to write a quick and dirty program that would remove the incorrect bits from the tape and replace them with the correct bits. I remember sitting down at the keypunch about 6:00 PM in the evening and writing the program off the top of my head. And it worked. Ten years later, I was able to visit with Jack and I learned that the quick and dirty hack I had written ten years earlier was at the heart of their billing system. Who could have thought my code could last that long?
I learned several more lessons from my time at Purdue Frederick. The first had to do with the billing program. You never know how long your code will last so write it well.
The second lesson requires a bit of framing. $85 did not go far in 1968. I was living in the White Plains YMCA and had to eat all of my meals in restaurants. I had no car, so I took the bus to and from work. One Saturday in the middle of winter I was walking down the street flat busted broke… and hungry. I was thinking, “If I had five dollars I could make it through the weekend just fine.” About 60 seconds later, I stopped dead in my tracks. Lying face-up in the snow across the sidewalk was a five dollar bill. I was stunned. It was as if some higher power had heard me and given me exactly what I asked for. I learned another lesson from this experience: If I am clear in my request, the Universe will take care of me.
A year after I started, Jack told me to find another job. I could take as long as I wanted, but he saw that I would quickly outgrow my current job and he wanted me to spread my wings and move onward. My remaining lesson took me many years to fully absorb: not all managers are as wise and enlightened as Jack was. In fact in the years since I worked for Jack, I came across only one other manager I liked and respected as much as him.
I left Purdue Frederick in the summer of 1968 and drove to Cleveland, the city of my birth. By this time I had an old Saab with a two-cycle, three-cylinder engine. Loaded to the gills with everything I owned, I arrived in Cleveland at the end of July, just after the Hough Riots. I had landed a job with a Computer Usage, a consulting company that had an office in a building near University Circle on the East side of Cleveland. It’s important to distinguish that I was on the East side because Cleveland is really two cities: the East side and the West side. They are quite different. I was born in Shaker Heights, on the East side. Now I was returning to a city that was having real troubles. The race riots had driven people away. The Cuyahoga River even caught fire! Cleveland was not a pretty place to live and I was young, alone and scared.
IBM 1401 AutoCoder
I found an apartment on Lake shore Boulevard and was assigned to a programming job at the Parma Board of Education. The school board wanted to create a system to create student transcripts. The school board had an IBM 1401 computer with a couple tape drives and an early form of disk drive.
To build the transcript system, I needed to teach myself Autocoder, the 1401 Assembly Language and learn how to access the disk drive. The 1401 was an interesting and quite distinct computer. Instead of binary, it was based on decimal numbers and strings were delimited with a “Word Mark”. The command to move a string was “MCW” (Move Character to Wordmark). Why I include this bit of trivia will become evident later.
I spent the next year working on Parma’s transcript system and got it working but I had some questions that I needed some help with so I went to the local IBM office. I told them what I had done and the IBM System Engineer (SE) looked at me very strangely. “That’s impossible,” he said. “We have tried to build a transcript system and it can’t be done.”
“Well, I didn’t know it was impossible so I just did it. Now can you help answer my question?”
The work at Parma School Board lasted about nine months before Computer Usage transferred me to another contract in Detroit that involved translating 7010 Autocoder to 360 PL/1. The assumption the contract managers made was that since I knew 1401 Autocoder and Honeywell COBOL, I should easily be able to translate the 7010 Autocoder to 360 PL/1.
This experience was one of the more painful I have ever had for two reasons, one technical and the other one highly human. Technically, there is absolutely no similarity between PL/1 and COBOL, and only a passing similarity between 1401 and 7010 Autocoder variants. It was made worse by the fact that we had no documentation on what the 7010 programs were supposed to do. All we could do was guess, submit our jobs for keypunching and execution, and wait for the inevitably disastrous results. The job was not designed for success, but it certainly taught me several lessons.
This experience was rife with lessons, but I think the most significant one was that managers (and especially managers responsible for selling) tend to make terrible technology decisions. Many technical sales persons are not very technically competent and will sell whatever they think the customer wants regardless of whether their technology team can actually deliver on the sales person’s promise. The lesson here is, don’t trust technology sales persons to know what they are selling to their customers. Corollary: be very careful about signing up to deliver on their promises.
The other big lesson involved the work environment. I sat in a conference room with half a dozen other young men who were just as frustrated as I was and possessed the same rather retarded and immature social skills that I had back then. Instead of talking honestly about our frustration and feelings of overwhelm, the conversation was about sex, sports and put-downs of each other. I have never been any good at that game and it hurt me badly to be attacked and put down day after day. I had no friends or family in Detroit and couldn’t wait to get back to Ohio. The lesson I learned here was how cruel men can be to each other for no apparent reason.
I endured the pain in Detroit for several months, and one day I was contacted by the IBM office in Cleveland. They were impressed by the work I had done for Parma Board of Education and wanted to hire me as a Systems Engineer (SE). My job would be to work with a team of sales people and keep them honest. It took me all of 1.01 nanoseconds to accept their office, say goodbye to Computer Usage and return to Cleveland.
I spent a couple weeks getting to know the sales team I had been assigned to. It was led by a huge and charismatic Irishman named Miller McCarthy. Miller had a wonderful way of making me feel good about myself and I found myself rapidly falling under his spell. Here was a man who could look at me and see the gold inside me instead of just criticizing me and putting me down.
Before my first month with IBM was over, I was sent to their “Computer Systems Training” class. The training was 10 solid weeks of intensive schooling led by a wonderful woman named Georgia Roberts. I am certain that every guy in the class had a crush on her. She was beautiful, dynamic, smart and technically very sharp. In the class, we learned both technical and sales skills. We practiced dealing with customer’s objections and I vividly remember a short training film in which a copier salesman tried to sell a machine to Vince Lombardi. He was five minutes early for his appointment and Vince told him, “Five minutes early is ten minutes late.” That has stuck with me.
A week before my training was scheduled to complete, we were assigned to teams and tasked with creating a sales presentation. Some IBM managers would be acting as customers and our job was to close the sale. My team worked hard to prepare, but the night before our presentation, Miller held a “team meeting” at his house in Geneva, way out east of Cleveland. Miller’s house was on a ledge of ground 50 feet above the shore of Lake Erie. It looked as if the next significant storm would gobble it up, but that evening, Miller was in a party mood. He barbecued some steaks and we all proceeded to get very hammered. About 1:00 AM, I finally made it out of the party and headed for my apartment (no, I should not have been driving).
The next morning I woke up with a huge pounding in my head and clear evidence that my whole body had been poisoned. And I had to make a presentation in less than an hour and I could barely see my face in the mirror. Somehow I managed to dress and make it to the office. I joined my team and we made the presentation. And we closed the sale. How, I haven’t a clue, but the feedback we got was that we had closed the sale very early in the presentation and spent the next half hour almost shooting ourselves in the foot.
I suppose there are lots of lessons here, but the most important (other than “Don’t trust the sales guy”) was to pay attention to people’s body language. I was so hung over and so much in my head that I completely missed the clues that they were sending.
On Friday, June 20, 1969, I graduated from the IBM training second in my class overall and first in my class in technical skills. The following Monday, IBM’s Buck Rodgers announced that IBM was unbundling SE services, meaning that customers would be charged for services that had previously been bundled with the cost of the computers IBM sold. I had the distinction of being instantly obsolete. I was, however, allowed to work on a project for the Lake County government because that agreement had been signed before the unbundling happened. I built a real property taxation system for Lake County that ran on an IBM 360/20 with four tapes and no disk drives. Miller McCarthy had sold it without disk because it was on bonus points that month, but without any disk drive, it took as long as 40 minutes to assemble a program. I had to write everything in 360 Assembler because the computer could not handle COBOL. Remember that lesson I learned earlier about trusting the sales guys?
Towards Christmas, 1969, I was working 90+ hours per week on the Lake County system and also working to complete some updates to the Parma BOE system. Parma was 20 miles to the south west from my apartment and the Lake County system was in Painesville, about 30 miles due east. As Christmas approached, I found myself locked in battle with one particular bug. There was one Move Left Character (MLC) instruction that was simply not working correctly. At one point, the IBM branch manager had a Christmas party at his house on the west side of Cleveland and I left the party in an illegal state and in a heavy snowstorm, I drove all the way to Painesville to stare at that single line of code. It was then that I realized the consequence of working on both the 1401 with its MCW command which moved the first argument to the second argument and the 360 with its MLC command that moved the the second operand to the first. I had simply reversed the operands. Lesson learned: Know where you are. Painesville (360) and Parma (1401) are different worlds.
IBM 1100 Fortran
When I finished the Lake County system, I had no new clients. Only the best senior SEs had work. I had lots of time on my hands. IBM’s strategy was to ride things out and let normal attrition trim the staff, so I spent a lot of time in the Cleveland data center. They had lots of different computers there and nobody was using the 1130. It was a small machine that was optimized for FORTRAN. I decided to write a FORTRAN program to predict how soon I would go broke. I made it handle bills, loans, credit cards and general expenses. It was quite comprehensive and lots of fun to build.
While I was playing with the 1130, I was asked to make some sales calls. On May 4th, 1970, I was returning to Cleveland from a call several counties to the west and I heard the news of the Kent State shootings. This had a profound impact on me. I looked at myself in the mirror and knew that it was time to take off my suit, get out of the corporate world and go back to college. I cannot say exactly why this felt so compelling to me. Perhaps it was that line from the Stones’ song about “Getting my share of abuse” or maybe I just didn’t see any future for me at IBM, but it was time for the next step.
The Rebel Emerges
I left IBM and got a job in the Administrative Data Center at Ohio State University and moved back to Columbus. In the next few weeks, I met with most of the professors in the Computer Science department and was granted proficiency credit for my entire major. Turns out that my IBM training was pretty good, because the professors wound up asking me lots of the questions that they didn’t know the answers to; but when I tried to declare Computer Science as my major, I was told that I could not do that until I had completed several years of math prerequisites, because I couldn’t possibly understand the computer science classes without the math. Go figure.
Lesson Learned: Bureaucrats make rules that make no sense, but they run the ship. I decided to let them make rules. I would focus instead on making money and having fun.
For the next three years, I worked on student grade processing systems at OSU. This was one of the happiest periods of my life. I played racquetball almost every day with my co-workers. I rode dirt bikes with my next door neighbor, Tom DeFanti and partied a lot. I also wrote lots of COBOL code.
COBOL was invented by Grace Hopper and was the first machine-independent language. She was a US Navy Admiral who was an early information technology visionary. I met her three times and each time she astounded me with her ability to reduce complex topics to simple metaphors. Perhaps her most famous example of this was embodied in the question, “How long is a nanosecond?” She could see that microprocessors were the way of the future many years before their time, and she knew this because of the limitations of the speed of light. She would pass out pieces of wire that were 11.8 inches long to communicate how far light can travel in a nanosecond. In large computers, the wires had to go longer distances, but in small computers, the wires are shorter, so the computers can be faster. Great lady.
IBM 360 COBOL E
All of the OSU student information was kept on 5081 punched cards. Three cards for each student and one for each course. With over 50,000 students, that was a lot of cards. We wrote all of our code in IBM COBOL E. This was a simple, stable version of COBOL, and anything but exciting to write in. It seemed to reflect the culture of our team. My manager was a quiet, don’t raise any ruffles kind of guy. He was OK to work for, but didn’t challenge me at all. He pretty much let me work on whatever I wanted to.
The operations manager was an ex-marine with a rather shallow sense of humor. At one point, he wanted to track key-punch usage, so he put a log sheet next to each machine and asked that we fill it in whenever we used the keypunch. In those days, the key punch was our terminal, so I tended to spend lots of time punching in code. And since each key punch was a shared machine, I cleaned up the space after each usage. Unfortunately, the key punch usage logs tended to disappear in this process. Can you say, “passive aggressive?”
Several months later, the director of the center lost a political battle with one of the bureaucrats and we were structurally merged with the computer center that ran the library circulation system. This was an on-line system written in BTAM (Basic Telecommunications Access Method) and used a poling protocol to loop through every terminal and see if it had any traffic. The group was lean and nimble and fun to work with. Based on my current relationship with the management of the administrative data center, I was “invited” to move to the staff of the library center.
Although the operations management might have breathed a sigh of relief, it was short lived. They published a directive that any job should be submitted for execution on either computer. As the only person in either center who could see the fallacy of this idea, I decided to make it obvious. I submitted a job at one center using the JCL standards of the other center. It failed completely and I was challenged shortly thereafter by the former gunnery sergeant to the effect, “What the hell do you think you are doing?” Having anticipated his challenge, I simply held up his memo about submitting jobs at either center along with the memo describing the JCL (Job Control Language) standards of the library center. I was right, but I didn’t make any friends that day.
I have long held a belief that people with excessive power will abuse that power. While at OSU, my rebel emerged from my conformist shell and started pushing back on what I judged were abuses. It took me many years to learn that my behavior was, although well intentioned, both ineffective and childish.
IBM 360 Assembler
Every program that processed data had to include logic to load each of the validation tables and then search it for the data being validated. This led to lots of code-bloat. I tackled this problem by writing assembler routines that could search any table. This simplified the process of searching tables, but they still had to be loaded. For this I decided to take a look at PL/I.
IBM 360 PL/I
PL/I (Programming Language One) is an interesting do-it-all language. It is said that you could pump a random set of punched cards through the PL/I compiler and it would compile something. Perhaps this is a bit of a stretch, but PL/I is a powerful language. Today, though, it is #34 on the TIOBE index of programming languages. I only tackled this one problem in PL/I, but when done, the table searching process was reduced to only a couple lines of code for each table.
After the Party
In February, 1973, Miller called me and asked if I had had enough partying. He had left IBM and joined forces with another company called Electron Ohio, and he wanted me to move back to Cleveland and move into the world of minicomputers. It was time to say, “Goodbye Columbus” again.