What things are you proudest of in your life?

I’ve written about some of the things I’ve built during my career while answering some previous questions but after forty-four years of dabbling in Information Technology, I accumulated more than a few.   One of my favorite sayings is “I’m glad I never learned I couldn’t do something” and the stories below begin with a pair of projects I undertook at Wright State University that few others would have even contemplated trying, followed by two situations where technical ability had nothing to do with achieving significant changes and finishing up with how I helped resolve a dispute without knowing anything about the subject being discussed.

GOTHIC was a mainframe assembler program that read a single input card and printed out, sideways, each character using multiple lines of asterisks, creating large letters in a Gothic-looking font. Since the mainframe printers used continuous forms, GOTHIC was perfect for creating large fancy banners, many feet long, announcing birthdays or other special occasions. But GOTHIC was written for an IBM DOS (Disk Operating System) mainframe, not the IBM MVT (Multiprogramming with a Variable number of Tasks) version we used at Wright State, so it would need some amount of modification to work, which I decided I would try, even though I didn’t have a clue what assembler language was, that class still a couple of years away. Undeterred, I slowly came to understand that most of the assembler language was a one-to-one mapping to the actual instructions that mainframes execute, for example, that an AR (Add Register) adds the contents of one of sixteen registers, essentially a really, really fast place to store a number, to another register. That was good news, as all those instructions did not need to change. The other piece to GOTHIC was something I learned were called “macros”, and those were different between DOS and MVT. One by one I swapped one macro, for example, a DOS DTF (Define The File) to its MVT equivalent, a DCB (Data Control Block). The program changed, I received some help with the JCL (Job Control Language) needed to compile, link, and execute GOTHIC and submitted it to run. A bit later I was asked to come back to the office of John Sloan, ever since a great friend and one-time townhouse mate, where I was told my program crashed MVT because I had not “saved my return registers properly”, which at the time I had no clue what that meant, but it was the one last difference between DOS and MVT. However, I was pretty sure that a mainframe should not crash because of a simple student error. All ended well, GOTHIC was converted and was a big hit for years to come. And it got my name known within the administrative computer center, which opened more doors in the months and years to come.

The last quarter of my freshman year included learning the COBOL (COmmon Business-Oriented Language) programming language. To stretch the mainframe’s limited resources, the class used WATBOL (WATerloo coBOL), a teaching compiler developed by the University of Waterloo in Ontario, Canada. All proceeded well until the last assignment of the quarter and I couldn’t get my program to run without it issuing an error and stopping. I checked the code over and over and tried a number of ways to figure out the source of the problem until I stumbled upon an unlikely “fix”. Adding a simple “PRINT” statement at a certain point in the program, for some unknown reason, bypassed the error. But this statement also meant my output didn’t look right. I was sure the problem was with WATBOL and not my program, and with my professor’s permission and support, I converted my program to COBOL, figured out how to create real MVT datasets, and copy WATBOL’s file data to the needed input files. I spent the first week of my summer break in a mad rush to complete this transition and was rewarded when my program, now running in a real COBOL environment, worked perfectly and I was able to turn in that final assignment and rest assured that my diagnosis of a WATBOL error was correct. It was a great lesson to learn early in my career that, even widely used programs like WATBOL can contain bugs and that nobody, and nothing, is perfect.

At The Mead Corporation, I managed the Network Services group which included all voice and data communications, and two stories on the voice side of things stand out as memorable.  I picked up responsibility for the shirt-pocket-sized company phone directory after its previous owner totally botched its production.  I told my group we were going to fix all the issues with the directory to the best of our ability and was greeted with a chorus of “why should we do that?”  Being the boss has the benefit of telling people they’re going to do it anyway and we proceeded to make a list of faults and ideas on how to fix them.  The biggest changes were moving from glossy to uncoated paper to make it easier to write on, going with a spiral binder instead of a glued spine so it could lay flat, and printing it landscape so each person’s information would fit on a single line.  The entire Network team did a QA check to look for errors and found hundreds of wrong names, numbers, and addresses, including one error for a member of our Board of Directors.  We received a lot of positive feedback and my favorite one was that it was obvious that people that travel put out the new directory.  The voice group was rightly very proud of what they had produced and I was proud to be the stubborn cuss that helped them get there.

The other voice story occurred when replacing the corporate phone system.  I had inherited a closet full of handsets that were collecting dust, mostly due to people upgrading to display phones.  I told my group that we were only going to have two handset choices, both beige and having displays, with the smaller one being for most people and the larger one available to call centers or administrative assistants that needed multiple incoming lines.  I was resoundingly told that this could never work as our executives wanted colors to match their office decor.  I persisted, knowing that our executives had more important things on their minds than their phone’s color, but also understood that if I was wrong I could change course and offer more selections, so the actual risk was minimal and the cost-savings of having standardized handsets was worth the try.  When people found they were all getting display phones they were thrilled and no executive ever asked about other colors.  My team members were shocked when nobody cared.  I’m really proud about being able to push changes in the face of the classic “we’ve always done it this way” mentality.  

The last story also occurred at Mead where I was invited to a meeting where I had no idea why I was included, as I didn’t know anything about the business topic being discussed.  After a few minutes it became clear that two people in the meeting had different views on something and instead of just sitting back and tuning out, I decided to challenge myself to see how both people could be right at the same time.  I figured that perhaps there was some assumption they were making differently and maybe I could find it.  So I sat and listened intently to their discussion, slowly figuring out what they were talking about and trying to spot that thing that would explain their differences.  After thirty minutes I thought I had it and it had to do with how the computer system worked and I was happy to be back in my comfort zone.  I listened for another ten minutes to validate that what I thought they didn’t know was the root cause of their disagreement and then asked the group for a few minutes at the whiteboard to present.  On the left side, I drew a diagram and asked the first person if that’s how they thought the system worked, and they said yes.  On the right side, I drew a slightly different diagram and asked the other person if it represented their view and they also said yes.  Then I pointed to the diagram that was correct.  Meeting over.  I was really proud of myself, not just because I successfully figured that out, but the fact that I didn’t waste an hour of my life just passively listening to people talk, but becoming actively engaged and making the assumption that both people were right, which was key to finding the resolution.