Am I broken?

By Kaze • 7 minutes read •

That’s a question I have been asking myself a lot lately. Around the month of April 2025, I decided to take a leap of faith, and leave my comfortable career as tech lead to go to a smaller company. When doing the interviews, the engineers mentioned working with a monolithic piece of software, but directors and VPs denied having such thing in the code. That was intriguing to me, but I believed the engineers more than the management layer. It intrigued me, as it seems like a nice challenge to break the monolith and modernize their platform, so I joined in!

The introduction

I went through the onboarding process and this is where I got my first taste of this new company. The onboarding process was lengthy, complex and fragile. It rely heavily on deprecated tools and Ruby scripts to configure your computer. At first it seems like a good idea, a simple script to run and configure your workstation, but in reality, the scripts were not maintained properly (and broken on Apple aarch64 CPUs) and made uses on tools that are considered as bad today. I had to do a lot of work to make the script work in the end, and I discovered my first ā€œred flagā€. The script was used to deal around the complex setup process. It does not address the root issue of having a complex setup, it tries (poorly) to make it easier. What happens when the complex setup changes? The scripts breaks, and no one notice unless someone new runs the onboarding process. Okay… there’s solutions for that, I can work on simplifying that!

Then the ā€˜real’ code

I wasn’t ready for this. Everything is in a single repository. It might work for Javascript stuff, but for Java backend software, it is not a good idea. Alright, maybe I’m acting in bad faith, after all, this is new for me so maybe I should give it a try first. After working in it, no it’s not a good idea. It almost an hour to build and run tests. Everything is complicated, think building, dependency resolution, pulling the repository, creating Docker images. Not only that, but the repository host a lot of Java, but also the entire codebase of the Ruby application. And everything is badly decoupled also. Things are organized in modules, but those modules cannot live on their own, and are not representing real concepts within the company. It is really bad.

How it got so bad

I started to ask questions around me. Why is the code in such a bad shape, especially since it’s the bread-and-butter of the company? The main application was written in Ruby/Rails in the early 2000s and never went away. Never the product owners or the management saw the issue in having increased complexity in a Rails application. It took an hackathon to create the skeleton of a new Java in React. Despite having this new frontend, the transition has never been completed. So right now, we have a Rails application that runs on the JRuby runtime (yeah, that’s used in prod) interfacing with Java libraries and interact with React code, all that in a single application. Apply this absence of will to the entire stack and you get bad and old code, being patched to get around the always-incoming new feature requests. When I ask questions about state of things? The general answer I get is ā€œProduct tossed away tech-debt tasksā€. I can imagine that it started with one task being pushed back, and product never got any backlash from that so they kept doing it again and again.

The thing that broke me

Lately, I implemented a feature in the codebase. It went through code review, it was deployed on a test environment and then finally got merged. Only after being merged, QA mention that some parts of the application is broken. Sure enough, my unrelated feature is the culprit. So I investigate the issue. Of course, it looks like a Jar Hell situation, with a mix and match of Spring/Jackson versions. A classic on older Java codebase. One thing kept bugging me. Why was there no tests covering that part?

Oh but there is tests! They are just @Ignored, or course! The engineer that marked the tests also indicated the Jira ticket that led to this. The ticket mention that the tests were flaky and they disabled them. I was furious seeing that.

How do you think ignoring failing tests was the chosen solution? I know exactly why…

The Whys

And now the questioning part

Then it begs the question. Do I still enjoy programming? Or is it that programming now means settling for bad code and just do what products asks us to do? I really don’t enjoy spending hours trying to fix Spring dependency. I really don’t enjoy waiting 5 minutes for the server to run. I think I still love creating, I still enjoy seeing two piece of software works together in an efficient way. But I do not enjoy working in old crusty tools knowing that no one wants to invest in improving it. Does that makes me unemployable? Is it that ā€œI care too muchā€ as I’ve been told in the past? I believe that if the code was old, but well designed I wouldn’t have so much issues with it. I feel like an artist that cannot work until the conditions are perfect. I know very well that this represent (maybe not to that extent) the majority of IT companies, but I also saw/heard such companies fall because they neglect their main product. Does that mean I will never find satisfaction anywhere? Combine that with the really bad labor sector these days (with AI and stuff). Maybe I should ā€œgive upā€ on programming (at least professionally) and seek more managing roles? Or even something entirely different? What if I was just unlucky or desperate and I went to one of those ā€œbadā€ companies. I really don’t know, but it drains my energy a lot. I don’t find joy anymore (or I find joy when I’m not working in the mono-repository), I have trouble waking up and finding motivation to get through the day.

What’s next?

I don’t know. I’m tired of fighting/hoping. It takes a toll to push a company to improve their practices, even more when there’s resistance. I want to leave, but life makes it complicated.

Banner by Timon Reinhard on Unsplash