Blah.. Blah.. Blåhaj

Don't enthusiastically agree to rewrite the entire system at work, at least not until you've read this

Hoping this resonates with someone out there and I'm not just screaming into the void. I've spent the last year plus on a massive rewrite at my current job, and I want to get some of it off my chest. Hopefully you get a chuckle out of it even if you can't relate directly.

The system had already been through one major transition before I joined (an old desktop app turned into a web app), and the stack it landed on left us stuck. The backend framework was years out of date, and the frontend was built on a library that had since gone through a major breaking rewrite of its own, meaning our code was frozen against a years-old version with no reasonable upgrade path. A frontend rewrite was happening one way or another; the only question was whether it happened as part of a bigger plan or on its own.

The beginning

I joined this company after they'd gone a stretch without any developer, and the bug queue showed it. It took a few months of steady grinding to get it down to something manageable, enough that I finally had room to start adding features, much to the delight of a CEO who loves suggesting new integrations without necessarily loving the maintenance surface they create.

The rewrite

Once things stabilized, the idea of a full rewrite came up. I'd pushed for exactly this at a previous job where the old system was a tangle of disjointed, poorly aged pieces, so I was primed to say yes. I put together a plan with a firm end date.

The existing system technically had documentation, but it had really started small and grown arms and legs over years of little additions, turning into a mostly undocumented hodgepodge. Even after two years here, I know there are parts of it I still don't fully understand. There were no automated tests and no specs for a lot of what had been built, and if specs ever existed, they were probably buried in some long departed developer's inbox.

On top of that, a handful of unspecced features got folded into the "baseline" for the new system right around release time, at management's request. And throughout the project, management kept asking for more integrations between the old and new systems, adding to the workload as we went.

The slide

Partway through, it became clear I wasn't going to hit that date solo. I was the only developer on it, and it was starting to feel like a slog, so I asked for more hands. I got two extra developers, which upper management seemed to interpret as "this will now ship way earlier," a claim I'd never made. I'd only ever said it would keep us on track.

From there, the promised date did what these things do: it kept creeping closer on paper while sliding further away in reality. Every time I gave an honest revised estimate, it seemed to get compressed back down before the next check-in, so on paper we were "late" again and again, even though we ended up landing almost exactly on the date from my original plan the whole time.

The breaking point

In a recent review, I was told that if this wasn't finished by the (now heavily slipped, publicly announced by the CEO) date, there'd be real consequences, and reminded, pointedly, that I hold a senior title and I'm paid like one, so I needed to be pulling more weight. It didn't help that a recent, reluctantly approved raise seemed to have left a bit of a chip on the CEO's shoulder about what he's paying me for.

This all came up again around a mistake that had actually been flagged and waved off by my manager every other time it surfaced, except the one time it landed while he was away, at which point it became a reflection on me instead. It's a pattern I've noticed before: when I've had to step into his usual responsibilities while he's out, it's been fine until something goes slightly wrong, at which point it's suddenly my failure to have touched it at all. The same conversation also came up when I asked for a single day off, which happened to land during what would have been a release window.

Where things stand

We're close to the finish line now. The last of the bugs got cleared recently, but now that management has actually gotten hands on with it, small issues keep surfacing. I'm hoping to close them out soon, ideally before I run out of goodwill.

On top of the work pressure, a coworker I liked working with being let go recently hasn't helped. I haven't felt fully like myself for a few weeks. Programming used to be something I did for fun outside of work too; now I can't remember the last time I opened a side project. I used to get through books quickly and lately I've managed a handful of pages in two weeks, because that's about all I can bring myself to do.

Some nights I lie there dreading the morning, knowing it's more misconfigurations and real bugs in what feels like an endless queue. If I'm honest, right now the main thing keeping me moving is the anxiety of what happens if this isn't done soon, rather than anything more constructive.

Takeaways

Looking back, I'd have pushed harder to properly spec the previous system before estimating, rather than working off my best read of it. I think that read was decent, but it meant things like entire missing screens didn't surface until right at the end. I'd also push back harder when my manager trimmed weeks off each section of the estimate to make it more palatable to the CEO. I let that happen because it seemed reasonable considering it was originally to be an estimate; I wouldn't make that call again.

I'm honestly not sure how much longer I'll stay here. This isn't the first time a project like this has worn me down this badly, and last time, it wasn't too long before I moved on.

Caveat: if you know your workplace won't mess with timescales, you'll probably be okay.

Okay-ish.

A four-panel comic. In the first panel, one stick figure says

Love this post? Hate this post? Feeling similarly? Want to chat or add something? I love hearing from my blog readers (some really cool things have come from it!) Please email me at gullet.bokeh.7x@icloud.com