In job interviews they sometimes ask about a time you failed. It’s meant as a probe into your self-image and reactions. How you react when challenged; what do you do about obstacles. I suspect anyone whose career revolves around solving problems has a few stories about “the one that got away.”

A recent online conversation inadvertently reminded me of all three that stand out in my history. I made a note to write a post about them. The new year seems like a good time for a trip down memory lane…

The blessing is that, in all three cases, I was “saved by the bell.” For whatever reason, the client moved on and no longer needed the application. Although I know I failed — at least in the time I had — the fact of that failure never became part of my official record. On paper I always delivered. Unless the project folded; then no one delivered.

These certainly aren’t the only failures in 44 years. Anyone would fail many times in that span. These are the three that stand out, though, because I didn’t finish. Some fails are because no solution is possible. Others are initial fails fixed by a second (or third) try. I remember these because they’re unfinished business.

Anyway. In chronological order:

§ §

The Fortran Conversion. My fourth and fifth positions at The Company involved supporting various CAD/CAM departments: facilities, engineering, etc. It was the first position where coding was part of the job description. Up to then my coding was an extra (a hobby) that caught the Corporate Eye. From then on, I worked as a professional coder.

So, this was my first official bespoke coding task of any real difficulty. And I was in water over my head. The client had a giant vector plotter (big as a large conference table). There was an optimization program, written in Fortran, that minimized how much the plotter head had to move. A vector plotter draws lines, and when those lines are many feet long you really want to maximize the time the pen spends on the paper and minimize the time spent moving it however many feet for another line.

The client was moving to a different (corporate-mandated) computing platform and had to migrate their software. The problem wasn’t the Fortran so much as the hardware environment. Per another corporate mandate they were porting it to C.

The nice thing about a port is that you already have a version of the code. I didn’t know Fortran well enough to write it (let alone write it well), but it’s easy enough to read, especially if one has a language manual (which I did). Both languages are procedural and similar enough that porting the code wasn’t the problem.

The problem was that Fortran allowed extremely large arrays. It handled the memory allocation (which, for very large arrays, involves disk swapping). C not so much. It’s infamously “high-level assembler” — managing memory in general, let alone swapping it to disk, is on the user (and a source of many bugs). The optimization program sorted the plotter lines by how close their endpoints (and colors) were. (A best effort, because this is akin to the Traveling Salesman problem.) The program read the plot file into an array, sorted it into a second (same-sized) array, and wrote the results to a new plot file. The plots had lots of lines, so the arrays were huge.

At the time, the idea of writing a memory-swapping suite was intimidating. It was operating-system level coding, and memory handling in C was notoriously hard to get right. The internet wasn’t anywhere near the resource it is now, although USENET groups devoted to computers helped. (I hung out for years in the comp.lang.c group.) I was at a bit of a loss.

As my experience grew, I learned that Unix has built-in tools (such as memory mapping) that would have made my task easy. Unfortunately, that position was my first exposure to Unix, and that was a lot to learn. As I tried to figure out how to write the memory-handling suite, the company decided to stop supporting the plotter itself. No plotter, no optimization program. Saved by the bell.

§

Lotus Notes Application. Concerns about proprietary information cause me to keep this one very brief. We used Lotus Notes for lots of things; it was a corporate-mandated solution with a lot of top-level pressure to use.

At one point I worked for a small department that did odd jobs for corporate engineering departments (my sixth position). We had everything from CAD/CAM designers to electrical engineers. They hired me because they wanted someone who did programming.

I’d taken a class in Lotus Notes Applications and found it awful and hoped I’d never use it. For years I didn’t have to. Then a client wanted a document control system that used a corporate framework IT was pushing.

Most hated project ever, and I was having an impossible time trying to understand that corporate framework. The Lotus Notes programming language was, as I recall, hideous enough, but this corporate monstrosity was a ball of mud.

Here again things moved on, and the client lost interest. To be honest, I’m not sure if they got tired of waiting for me to figure it out or if an often fast-changing business just made their request obsolete. I only know I was told one day to no longer bother with that project.

§

The RC Car Project. I have proprietary concerns here as well, so suffice to say I was asked by an engineering department to write a program that ran on a CPU embedded in a Radio-Controlled (model) car. The car was equipped with an array of magnetic sensors, and the idea was to control its path with externally placed magnets.

They were hoping I would write code to integrate the sensor readings and output control signals for steering and speed. A neat project, but doing it right involves a lot of mathematical processing. I had a system to try, which was fun, and I was just starting to experiment with basic ways to combine the signals (as well as learn what the embedded CPU could do),… And the project just kind of evaporated. They didn’t even want the stuff back (I still have it).

I wish I’d had time to finish this one. I’ve always enjoyed coding that reads sensors and controls physical mechanisms.

§

Speaking of which, I was in the same department for both the Lotus Notes application and the RC Car project, my sixth position at The Company. Because of our association with the engineering departments, nearly all the reads-sensors-controls-motors programming I did was while working there. It was one of my favorite positions.

Sadly, a corporate mandate against small fry departments led to ending the operation (much to our clients’ dismay). Time ran out for us all that day.

§ §

I’d like to think, given time, I’d have figured things out in all three cases. The Fortran conversion wouldn’t pose any problems for me now; it’d be a fun project, in fact. The RC Car project I’d only gotten started thinking about and learning to code for. I’m sure I would have seen my way through that one.

The Lotus Notes one, though, that was as much my own resistance to the product and the language. That was also around the time my brief experiment with marriage blew up, and I was very distracted. I wouldn’t want a second try in either case.

Ø