Career Retrospective

Introduction

In February 2023, I (along with hundreds of others) was unfortunately laid off from an up-until-then great company shortly after it acquired a new CEO.

Fortunately for me after having spent nearly nine years there and having a high salary as well as very generous RSU compensation, I had amassed “f--k you money,” so there was no pressure to find a new job. That being the case, I only casually looked.

My problem is that I often bomb tech interviews. There’s just something unnerving about being asked to code in real-time with a time limit with someone almost literally watching over your shoulder. (For the jobs I have gotten over the years, I was either asked questions I was familiar with or I luckily had an “Aha!” moment.)

It’s been a year since the layoff and I think it’s time to retire officially. It’s been an interesting ride spanning approximately 45 years. Perhaps it’s time for a retrospective.

The Early Years (early 1980s)

My earliest memory of using a computer is programming in BASIC using a DECwriter (paper!) terminal at my high school connected to a remote computer maintained by BOCES.

I also occasionally went to a nearby Crazy Eddie and tinkered with their computer display models. The one I used most was their Atari 800. Fortunately, the sales guy was quite tolerant of me spending hours there tinkering.

My high school then started to acquire Commodore PETs and Apple IIpluses. I had become friendly with all the computer teachers in my high school. There was a plan to do a group purchase for PETs for personal use, but that deal fell through.

As a consequence, in 1982, my parents decided to buy me an Apple IIplus, a Disk II, an RF modulator, and a box of 5¼” floppy disks totaling $2017. (That’s equivalent to $6369 in 2024.)

This turned out to be a pivotal moment putting me on the path of using Apple computers — that I still use to this day.

I still remember being astonished when I saw the Apple II was able to plot “high-resolution” graphics. (The PET had no graphics capability; only PETSCII.)

On the Apple II, I eventually taught myself 6502 assembly and wrote an entire suite of extensions to Applesoft BASIC. I also taught myself Pascal that quickly became my then-favorite programming language.

At some point, I even got a part-time job programming for my school district using both Apple II and Apple III computers. Among other things, I wrote software to record students’ grades and print their report cards. I kept that job even after graduating high school and through undergraduate school.

I would like to thank Andrew L., Henry C., Linda P., Richard A., and Robert G. for being great teachers, mentors, and friends.

Undergraduate School (1985–1989)

Although I won the Rensselaer Medal from RPI while in high school, I decided to attend the then Polytechnic Institute. At the time, I didn’t feel comfortable moving away for college that I would have had to do to attend RPI; whereas “Poly” was only about a 20 minute commute by car from my parents’ house.

Eventually, I bought my first Mac. (I think it was a Mac SE or perhaps a Mac SE/30.) I also bought a complete set of Inside Macintosh and wrote programs for it.

At some point, I taught myself C via The C Programming Language and also found The C Programmer’s Handbook to be quite helpful. C displaced Pascal as my then favorite programming language. I’ve been programming in C (on and off) ever since.

The Bell Labs Years (1989–1995)

My first real job out of college was with Bell Labs (back when it was still part of AT&T). It wasn’t in New Jersey (where most of Bell Labs was); instead, it was at their Indian Hill facility in Naperville, IL (about 30 miles west of Chicago).

It was too good of an opportunity to pass up despite having to (finally) move out on my own approximately 850 miles away. I mean, if you’re a programmer, how can you pass up working at the company where Unix, C, and C++ were invented?

I don’t remember all the other companies I applied to, but I do remember that Apple was one of them. I didn’t hear back from Apple, so I figured they weren’t interested. But then shortly after I accepted the job at the Labs, I finally heard from Apple: they wanted to interview me. I told them they were too late.

This was another pivotal moment. If Apple had only contacted me sooner, my life and career might have taken a very different path.

At the Labs, I actually started in testing the 5ESS telephone switch. The job wasn’t directly a programming job, but I wrote a lot of ksh scripts. (I even met David Korn once, albeit briefly.)

At some point (for reasons I don’t recall), I also started playing around with Cfront just as templates were being added to C++. Apparently, I had a knack for both finding bugs and whittling my bug-manifesting test cases down to a few lines of code to submit to the authors. I eventually became an official Cfront tester.

Around this time, HyperCard was being used a lot on the Mac. For fun, I decided to translate The C Programmer’s Handbook to be a HyperCard stack. I then decided to see if Prentice-Hall (the handbook publisher) would be interested in a HyperCard version. (With me being from Bell Labs, they actually took my call.) They politely declined at which point I asked if they’d be interested in publishing a C++ version of the handbook — they said yes! It took me about a year to write, but I got The C++ Programmer’s Handbook published in 1992.

A few of the nice things about the Labs at the time was that they allowed me to use the AT&T “Death Star” logo on my book’s cover (that imparts a certain gravitas), they foot the bill for phototypesetting the camera-ready copy for my book, and they let Bell Labs’ authors keep 100% of book royalties. It was translated into French, Japanese, Russian, and Ukrainian (that I’m aware of). (Prentice-Hall sent me some copies.)

To help with my actual day job, I started writing scripts to generate software deliverable plan charts using dot for new 5ESS software that would need testing. I ended up collaborating with Steve North (one of the primary authors of dot).

In the old days before the break-up of the Bell System, it was common practice for the Labs to hire people with Bachelor’s degrees fresh out of college and immediately ship them off to a graduate school — of the student’s choice — to obtain a Master’s degree.

The kickers were that the Labs not only paid the tuition, but additionally gave people a monthly stipend to live on so they didn’t have to work and could focus on obtaining their degrees. The Labs didn’t even require people to sign any kind of contract to remain working for the Labs for a certain number of years afterwards. They just trusted people to do the right thing. Now that’s a deal.

The only caveat was that you had to complete your Master’s degree in one year (as opposed to the two years it normally takes), hence the name “OYOC”: One Year On Campus.

Post break-up when AT&T was faced with actual competition, they tended to be a bit tighter with their purse strings. While OYOC still existed, it was far less common. Despite this, I did make it known to my management that I’d like the opportunity to go on OYOC, but didn’t get an immediate reply.

One day, Steve asked me to send him a sample deliverable plan chart. He didn’t say why and I didn’t question it. Perhaps a couple of weeks later, I just happened to pass my department head in the hall and he casually said, “We’re going to see what we can do to get you into OYOC.” I was very pleasantly stunned.

It turns out that the sample chart Steve asked me for was used during a presentation of how Bell Labs research was collaborating with other departments and my department was featured showing the chart. This made my department head look good that I assume is what helped get me into OYOC.

I decided to attend the University of Illinois, Urbana-Champaign (UIUC). I did my thesis on a C++ implementation of statecharts: CHSM. Without trying, CHSM has actually been used in a few production environments such as Philips, Qualcomm, and for the ANTARES neutrino telescope project at CERN.

Upon my return from UIUC, I requested — and got — an internship in the the Labs’ Software Production Research Department (also in Illinois — just across the street from where I was previously).

While being at the Labs was great in general, being in a research department was even better. For me as a young computer scientist, I occasionally got to meet and sometimes even hobnob with the likes of Dennis Ritchie, Bjarne Stroustrup, Andy Koenig, and even Arno Penzias.

Regarding Bjarne, once I visited the Labs’ headquarters in Murray Hill, NJ, where he worked. Having my Bell Labs badge (they were the same company-wide), I was able to just walk in. I eventually found my way to Bjarne’s office, knocked on his door, and we had a chat. I no longer recall what it was about, but I do recall him being quite gracious.

At some later time, Bjarne came to Indian Hill to give a talk. After the talk, I — somehow — managed to be the only one who took him to lunch. I drove him to a small Mexican restaurant in downtown Naperville and we just had a 1-on-1 chat. (I don’t recall what we chatted about then, either.)

While in research under the mentorship of Steve E., I coauthored a few papers and got a few patents. It was a great time. Eventually, however, my internship was up.

Over the years, the hiring pendulum of research swung from fairly liberal (you only had to demonstrate talent) to fairly conservative (you also had to have a PhD — which I didn’t). Unfortunately at the time, the pendulum was on the conservative end of the swing and I didn’t get hired into research. Instead, I went back to a different group working on developing “configurator” software in C++ for the 5ESS.

Eventually, however, I grew tired not only of the job, but of Chicagoland in general. After leaving and looking back, I realized that, for some reason, I never quite felt “at home” there. I decided to move again, this time even farther to California and Silicon Valley.

The NASA Ames Years (1995–1999)

I got a job with Caelum Research Corporation contracting to the Computational Sciences Division of NASA Ames Research Center in Moffett Field, CA. I managed to get an apartment two miles away, door-to-door. My “commute” was so short that I sometimes went home for lunch and even had a quick nap.

Two of the projects I developed while there that stand out are:

• A web-based system that allowed planetary scientists to view images from a robot Mars rover and request experiments.
• The Postdoc project: a web-based system for document-sharing and collaboration system used widely at NASA.

For the Postdoc system, I needed a way to search do a full-text index and search of documents. I had tried SWISH-E, but it turned out to be terribly slow eventually taking more than 24 hours to index the previous day’s new content. (It turns out the authors were using unbalanced binary trees.)

I decided to write my own indexing and search engine: SWISH++. By simply using balanced binary trees plus mmap instead of traditional I/O, SWISH++’s performance was mere minutes instead of hours.

SWISH++ ranks as one of my favorite things to have done.

After about four years at Ames, the bureaucracy got to be too burdensome and I decided to jump into the start-up world.

The Startup Years (1999–2014)

Liquid Audio (1999–2000)

The first of the start-ups was Liquid Audio, a pioneer in digital music downloads. (This was a few years before iTunes.)

The job eventually required being on-call with a pager (back when people other than doctors still used physical pagers). My first night was a night from hell. The pager kept going off. I got no sleep. Despite this, I managed to get into the office the next day. Upon seeing me, my manager, Nathan (who had seen a transcript of the pages), sent me home to get some sleep. The next day, I had told him that I never wanted to do that again. (I also made a vow to myself: never again.) Even though being on-call was allegedly part of the job, he told me that I was too valuable to the company and that I no longer had to be on-call.

While at Liquid, I wrote a small, light-weight custom web server in C++ to serve music clips and designed and implemented a system for configuring and deploying software to servers automatically directly from source-control for which I got a couple of patents.

Eventually, things changed and the job was no longer interesting, so I left.

iPix (2000–2001)

I went to iPix. Among other things, I worked on:

• A large-scale file repository system over HTTP serving over 60 million images per day for eBay.
• A fault-tolerant file transfer server over HTTP for collecting virtual tour images from the field.
• An automated, modular queuing system for processing virtual tours complete with web administrative front-end.

Despite being fun with great people, eventually, iPix started to implode due to financial realities, so I left.

XQRL & BEA (2001–2005)

While I was still an intern in the Labs’ software research department, I was contacted by Fabio, then a researcher at CERN. We had collaborated at improving CHSM for his use of it there.

Fast-forward to now and Fabio had moved to Silicon Valley and started his own small company XQRL (pronounced “squirrel”) along with his wife Dana. They offered me a job to implement the type system for a Java implementation of XQuery. (I didn’t know Java at all, but taught myself. I don’t like Java.)

The XQuery type system isn’t like most programming language type systems in that a “type” can not only be something simple like xs:integer, but can also be a disjunction like xs:integer or xs:string. To answer questions like “Does type A match type B?” requires that each is converted to a DFA and employing algorithms like DFA minimization. From my work on CHSM, I was already familiar with such concepts.

My XQuery type system implementation ranks as one of my favorite things to have done.

XQRL was collaborating with BEA Systems and they eventually bought us out, so I worked for them for a while.

Light Crafts (2005–2011)

Fabio left BEA to start another company, this time developing desktop photo editing software. While Photoshop was dominant, it was designed by image scientists, not photographers.

Take the curves tool, for example. There’s no way to use this tool intuitively. It’s completely separate from the photo you’re trying to adjust. You just have to wiggle the line and see how it affects the image.

In contrast, Fabio’s idea was to create a tool that uses the zone system that’s much more intuitive. The result was LightZone. It also did all photo editing non-destructively and even worked on camera RAW files. It was largely written in Java to be cross-platform on Mac, Windows, and Linux, though there was some code written in C for platform-specific things as well as decoding RAW files.

I worked on image metadata ingestion and indexing as well as the low-level, platform-specific code for both Mac and Windows (the only time I’ve really done Windows programming) including detecting when a digital camera was connected via USB and directly importing photos from it.

We had booths at a couple of MacWorld conferences. In 2007, LightZone received the MacWorld Editors’ Choice Award.

At one point, we did MacWorld in Manhattan. Our booth ended up being pretty much across from Apple’s booth for their brand new Aperture photo organizer and editor. Also around the same time, Adobe released Lightroom. Even though LightZone’s editor was far superior to both Apple’s and Adobe’s, it was still pretty unfortunate timing. Had LightZone gotten to market a few years earlier, things would have likely turned out very differently.

28msec (2011–2014)

At this point, I went to work for another start-up doing yet another implementation of XQuery, but this time in C++. Among other things, I implemented the full-text extension and multi-lingual error reporting.

At one point, the company’s board of directors told the CEO to reduce costs — so I was laid off. There were only a handful of developers, so my being laid off was actually a significant reduction in people who could write code. When the board heard how the CEO reduced costs, I was re-hired. Still, as you might expect, it left a bad taste, so I started looking.

After 28msec, I decided that I’d had enough of the start-up world and looked for a mid-size to larger company.

The Splunk Years (2014–2023)

Despite an all-day, brutal tech interview, I got offered and accepted a C++ development job at Splunk. My first assignment was to improve the Splunk scheduler.

Briefly, users can write queries to search over indexed data. They can also schedule them to run periodically like cron. One of the issues was that there are, of course, resource constraints: there’s only so many CPU cores to run searches. If the number of searches to run at any given time exceeds that, you have to figure out which subset to run while still being (eventually) fair.

The changes I made yielded about a 20% search throughput increase. I got a couple of patents for this work.

My scheduler implementation ranks as one of my favorite things to have done.

After that, I worked on the integrating using S3 into Splunk for cloud storage of indexed data and intelligently caching retrieval in an effort to minimize latency. I got a few more patents for this work.

Up until this point, there was no on-call requirement for engineers (there was a separate team for that). But that was about to change in that even developers would be on-call. From my Liquid Audio experience, I had vowed never again, so I started looking for a new job.

I managed to find one and was given a nice offer; but then, serendipitously, I happened to be browsing LinkedIn and came across an open position from Splunk to start a new “developer productivity” team to reduce pain-points for developers through better education and tools.

Since I had been doing software development for a long time, I thought a change like this was good. I did want to do more educational stuff. And this job had no on-call requirement. I applied and was offered the position. I decided to stay with the “devil I knew” and remained at Splunk.

I developed and presented several advanced C++ talks including a full 9-part C++ course for newer developers. I also worked on both new tools and documentation to eliminate pain-points. Having been a developer there, I knew what all the pain-points were. I also lead the effort to upgrade our compiler toolchains from C++03 to C++17.

And then the lay-off happened. Although I had recently done a thorough analysis of my finances with my long-time advisor and concluded that I had enough to retire on, the lay-off still hurt.

Epilogue

It’s strange: 45 years seems to have gone by both slowly and quickly. On the one hand, it definitely seems like my career took a while; on the other hand, I can’t believe it’s over. All the classes, studying, exams, interviews, and jobs, and now, finally, it’s done. I made it. I can relax.

So what are my plans for retirement? I’d love to find a computer science teaching position at a local college. (Unfortunately, open positions don’t come up that often.)

In the mean time, I still enjoy hacking on various projects such as cdecl and writing my programming blog. Aside from computers, I enjoy gardening, cooking, and hope to do some travel.

I’ve toyed with the idea that, at some point, I might try to organize a reunion of some of my fellow classmates from Poly to see how we all made out in our careers and lives between graduation and retirement. The Farmingdale, NY, campus where we all went no longer exists, but there is a shopping center in its place with a Chili’s restaurant there. That might be an appropriate spot for such a reunion.

After 45 years in software, do I have any advice? Some, but that’s a story for another time.