Career Bookends

According to my offer letter, I was supposed to start at IBM sometime in June, 1976 (I’ve forgotten the exact date) and work on a compiler for the minicomputer that would be released as the IBM Series/1. However, I delayed reporting to work in favor of becoming engaged to Diane, and by the time I got to Boca Raton, the spot on the compiler team had been filled.

  • First day at IBM: July 19, 1976, Boca Raton, Florida, General Products Division

My first job at IBM was on the team writing telecommunications code for the Series/1. I wasn’t enthralled, especially when it came to testing the code, because we had to short out the peripheral cards to load in our code, and I didn’t realize that there was only low voltage in the Series/1’s card case! And the idea of dealing with information that left the machine and might or might not return successfully was strange, too.

So after a few months, I made a deal with my management — if I would provide a complete unit test plan for the code I’d written, they’d transfer me to the Operating System group (just down the hall). They were happy to oblige, so I wrote the first of many productivity aids, one which read the structured assembler code and annotated it according to our unit test scheme (“Test Plan 7”). It took me a day or two to produce the test plan for all of my code, and away I went.

The Series/1 was an interesting beast; it had 64kb address spaces (we only used one in the first release of the OS) and not enough registers. It also had short and long forms of many instructions (the short form had, if I remember, 256 bytes of addressability from “here” — anything else took the long form). We were perpetually running out of room in the address space, and it struck me that it would be a good idea to have a peephole optimizer which would convert long form instructions to short form when possible. So I wrote it, learning PL/S in the process. And people loved it — it was in our “Quality Plan” almost immediately. That was the first time I really understood how much leverage smart tooling could provide.

I created quite a few other tools while I was in Series/1 development; I’m not sure why other people didn’t do the same thing, because I found that doing so always saved me time, and then providing the tools to my colleagues really provided a big payoff, at no extra effort. And I even got to learn new languages in the process (most of which I have, mercifully, forgotten), which I greatly enjoyed.

I mentioned that we were writing “structured assembler” code — this was in the days that using structured code instead of GOTO statements was considered an “Improved Programming Technique”. There were many “Improved Programming Techniques”, not all of which were used well.

In particular, we documented our code using a technique called HIPO — the documentation for HIPOs said, very clearly, that they were not used to document the logic of a module, just its overall function; however, our “Quality Plan” called for us to use HIPOs as flowcharts to document the logic. I found this silly (not to mention very tedious), and so I wrote my first memo at IBM: “HIPO: Threat or Menace” (playing off a National Lampoon cover), quoting the HIPO documentation to make my point. In those days, we actually hand-wrote memos, and the secretaries typed and distributed them — my department’s secretary tried very hard to get me to change the subject line, but I refused. In hindsight, the subject line probably didn’t help my case, but the HIPOs vanished.

It’s been a long time since anyone has had to type a memo for me; I can’t remember the last time I got a real hardcopy memo, for that matter. Email has taken the place of memos, and, for better or for worse, nobody else sees them before they go out to the world.

I wanted to find a way to reuse the subject line of my first memo in my last IBM email, but the joke wasn’t all that funny in 1976 and hasn’t improved with age. So my last email had a more personal subject: “33.7 years – that’s not too many”.

  • Last day at IBM: March 31, 2010, San Jose, California, Business Transformation/IT

And you know what? I never did get to work on a compiler at IBM!

Google is not idempotent

Today was my last full day at IBM; I decided to spam thank some close soon-to-be-ex-colleagues before I left. Since I wasn’t sure that those who wanted to respond would do so before my IBM email address expired, I directed replies to an address at a domain that I set up for my family (let’s call it example.us, just to keep the real spammers at bay).

Mail for example.us is MX’ed to Google Apps servers; I’ve set up forwarding there for each of us to our real preferred GMail addresses. This has the advantage of letting me move from GMail if I want to, without anyone being the wiser.

But today, I discovered that Google isn’t consistent in its mail filtering. A friend at work thanked me for sending her the note and mentioned that she’d replied — but I was pretty sure I hadn’t seen her reply. And when I searched the GMail account, there was nothing from her. But when I looked at the mailbox on example.us, her note was there. And, in fact, there were several replies that hadn’t made it to GMail but were safely in the inbox for example.us.

So I guess I need to rethink my mail strategy and let mail for example.us stay there instead of forwarding it to GMail.

Life was easier when all my mail went to singer@almaden.ibm.com! (I’d worry about spammers getting that address, except that it’s been visible on the Web and well-spammed for many years, and, of course, it expires tomorrow.)