It Wasn't Making me Happy - On Changing Jobs

Feeling small

Most companies like to say that their biggest strength is their people. Few can actually articulate how they ensure that they keep the best people, but most at least try to give the impression that they try by having free coffee, or free snacks, or free something (as long as it's cheap).

I had never worked anywhere that actively worked to give me the opposite impression.

The parking is a vacant lot, next to a gutted-out building, covered in shards of glass.

It took 4 days to get a laptop and an email login.

The laptop came with a pair of monitors. Two 1080p slabs, with pixels large enough to count.

The docking station was a USB-C hub from a no-name Chinese brand.

I asked for a QWERTY keyboard without a numpad. It was denied. The resulting email change went all the way up the org chart.

But most damning, the laptop didn't charge over USB-C.

Feeling lost

Starting in a new team means discovering a new codebase. Somebody points you at some out-of-date documentation full of wishful thinking and high hopes, and you're off spelunking.

Unfortunately, reading is all I could do. The hardware is large, and there's only a handful of units to use. There is no simulator for the system, so I could not actually run the code, and the tests are limited; large parts of the codebase are too tightly coupled to be easily unit tested.

If I can't run the code, I can at least study it. If only I could figure out what the relevant parts of it are. The class names are unhelpful, and the code itself is mostly lacking documentation. I stare at my open editor tabs: 5 of them are called Controller. All of them do different things. `

I ask for whatever documentation there is, and I am met with embarrassed smiles.

This codebase is hundreds of thousands of lines, takes a good 10 minutes to build on my beefy development machine, and I have no idea what it even does.

I'm lost, I wasn't expecting a reverse-engineering job.

Feeling Unimpressed

My first task, and the only code I successfully merged in my time there, was easy enough, take a pattern from one file, and apply it another. Add some unit tests. Watch the CI go green.

My second task was a simple change, it amounted to adding a single line to a function.

A good first issue on it's face.

After some time finding my bearings, I add the required line, and try to add a unit test.

I failed.

Oh yeah, that part of the code can't be unit tested. We'll just have to test on the actual hardware.

We go to test the change on actual hardware.

Connect the special cable to the special connector, grab the ssh key to log on to the onboard computer, overwrite the binary on the target system, and ... SEGFAULT.

Oh that happens every now and then. Look at the backtrace and just comment that line out.

I look on bewildered and confused. This isn't the highly resilient codebase I was expecting.

I duly do as I'm told, find the line, comment it out, rebuild, reflash, and ... the system still fails to initialise.

We look at the logs, scroll up, scroll down, scroll back up some more, ponder ...

After a brief moment, a pronouncement:

The motors are acting up. There's nothing more we can do today.

We make plans to return another day to test on another system.

A few weeks pass before we try again. This time, the code runs and the station boots. When we change a configuration file to see if the fix I had implemented works, another error comes up. Another subsystem is broken by the configuration change, my code never even ran.

I look on confused. Another pronoucement:

The fix won't work. This issue can only be handled at a much lower level.

I drop my changes. The best I can do now is merge the cleanups I did.

I am lost, but, more than anything, I feel helpless. How am I supposed to become productive in this code base?

I do not understand what the code actually does.

I cannot even describe the high-level architecture of the code.

I cannot even list out the main components of the code.

I'm totally lost. Fuck.

Feeling Powerless

If I can't land any changes to the actual software, I can at least try to improve the process. One of the quick wins would be to get people to actually write documentation.

In the past, I've had good success with a merge request template that simply asks if the change requires new documentation.

When creating a new merge request, you now have to explain why the documentation does not need to be uodated. Quite a few times, as I was writing the rationale, I realised what documentation actually needed to be updated.

The file, including comments, is about 20 lines long.

That should be a quick win.

I bring it up with the team lead, and he asks me to demo it to him. He's enthusiastic, and sends an email to the other team leaders asking them for their opinions.

Nobody answers.

It dies there.

The merge request that actually builds the documentation with doxygen, dead too.

The change to actually run the formatter in the CI pipeline. Also dead.

How dispiriting.

Making Up My Mind

Career progression is about learning. Every job I've had so far, even the ones that did not make me happy, had opportunities to learn more about the craft of software, the stack, or the culture.

I was hoping to see a quality-focused environment, obsessively eeking out the last drips of performance from the control loops, but seeing the hardware judder around killed that notion.

I was expecting to find a culture of quality, striving to create a reliable system, but seeing the system crash on a regular basis absolved me of those expectations..

I left every day, more and more confused as to how I would ever become productive in the code base, and what I had to learn from it.

The decision was made, I would find something else.