On Disappointment

First Contact

The hiring process had been slow, but fair. The interviews had been challenging and interesting, so I was quite eager to start.

By the end of the first morning, I had a laptop (Windows unfortunately), and login information for outlook and teams. A low bar, but one many companies fail to meet. Laptop in hand, I went to my new manager, and things took a turn for the worse.

• “You’re going to read documentation for the first month” he said.

• “No, I’m not!” I responded, reflexively.

He assigned me documents to read, and I hit my first roadblock. I did not have access to the document management system, and could not access any of the assigned documents.

Things did not get better after that. After a week of reading increasingly repetitive and irrelevant documentation, my brain was melting: I could no longer focus on the handful of remaining pages. As my gaze passed over them, my eyes glazed up, and the content passed through me without ever encountering a conscious thought.

I begged for access to GitLab to at least take a look at the software for which I was reading the documentation. I was met by a certificate warning. I tried to clone the repository, and spent the rest of the afternoon looking for the root-certificate and installing it.

When I finally looked at the code, I was struck by cursed formatting styles, applied haphazardly, and without any uniformity.

This was not the high-quality codebase I hoped to see.

My first month crawled by: I was required to come to the office every day, and would sit in front of my computer, glumly, silently, only meeting colleagues at lunch, before sitting in traffic for an inordinate amount of time on my commute home.

I was miserable.

Somehow, it gets worse

With my first month up, I was assigned my first real work. Software testing!

Aerospace is big on paperwork, and one big chunk of paperwork is proving that you did enough testing. Important systems require 100% unit-test coverage (or more accurately: require you to provide some kind of documentation showing that you have 100% test coverage). The quality of tests themselves is not examined, just the number.

Once those pass, a bevy of integration tests are required, showing that core requirements are addressed.

In a reasonable environment, this would be a handful of automated test runs. Run a handful of commands, get the logs, and attach them to the report. In a well-oiled system, the tests would be run automatically by the continuous-integration as part of a tag pipeline, and the certification work would be limited to downloading the automatically-generated test report.

This was not the case. Two weeks were budgeted for me to learn how to run the tests, followed by two weeks to actually run them. Another month of my life, commuting to work every day, for a job that had explicitly advertised 50% home-working.

This may have been the most difficult period of my entire professional career to that point. The steps to run the manual tests were often wrong, or incomplete. Worse, many of the tests had unclear pass/fail criteria, and in many cases there was no way to differentiate between a test that passed successfully, and a test that had been executed incorrectly.

The most egregious test though were the automated tests. Hours-long test suites, that failed to check any pre-conditions. Forget to run a service: half of the tests will fail with obscure error messages, for something that should have been detected in the first 5 seconds.

I was going insane.

Somehow this agonising period also came to end, and I was promised my first real project. I was hopeful again.

All hope is lost

I cloned the repository, ran the build commands in the README, and was immediately stopped by a wall of errors.

The project had been entirely staffed by external contractors, working more-or-less independently, until that point. I was the first internal person to look at the code in a year.

I asked questions, found some answers, and eventually got the project building, but somehow, nobody was able to tell me, in any useful detail, what the short-term goals were, what was actually working, or not working, or even find references for the core algorithms that were required for the project.

As I looked deeper, I only grew more worried, the documentation was scarce, and most of what I could see was a half-baked, under-development, in-house framework, for … message passing between threads?

Where was the actual meat of the project?

Where were the tests?

Where was the continuous integration?

Where was the documentation?

I grew more concerned.

I dug in some more, found some trivial race conditions.

I pushed deeper, and started to notice a total lack of error handling.

This was not what I expected. Instead of a carefully architected system, designed with the expertise and caution most people would associate with an aerospace company, what I had in front of me was an unnecessary framework, rapidly growing more warts as the core design problems became more apparent.

Here I was, on a project staffed by contractors, very much on the outside. Desperately trying to figure out what was going on, without even having access to the issue tracker, or an invite to the weekly progress meeting.

What the f… was I supposed to do now?

Pushing Through

Not one to give up easily, I rolled up my sleeves and tried to understand the writhing monster of a framework, growing every week, with undocumented, and untested code. At each refactor, the framework resisted, mutating under my fingers: a new push, attempting to fix another issue that should have been apparent from the start, haphazardly adding parameters to function I had removed.

Nobody wants to throw away a year of work, but faced with the realization that understanding undocumented code is harder than writing it from scratch, and absent any signs of an actual grand vision for the software architecture, maybe that would be the best path forwards.

I groaned silently. That would be a hard sell.