Story of Overcoming Complexity in the Codebase: A Reflection

The last few weeks, I’ve been working on a particularly complex area of our code base. It spans both the back end and the front end, with multiple layers of complexity on each side. I’m still building confidence in the back end, so struggling there wasn’t unexpected. But on the front end, where I usually feel at home, things didn’t click as quickly as I expected, and that felt unusual.

At first, I blamed fatigue (we’d just moved into a new home). But even after a good night’s rest, I still couldn’t visualise the chain of events. On day three, I hacked together a partial solution, which gave me hope, but it didn’t fully work because I still didn’t understand the bigger picture.

I want to note that I wasn’t working in isolation. I have a wonderfully supportive team. This was just my solo time to gather context before pairing. I also shared that I was struggling, and my team validated that this part of the codebase is indeed complex. Still, after a few days without visible progress, I started questioning my ability. It’s a place I try not to visit often, but sometimes it sneaks in, especially if you’re from a marginalised gender in tech. You know the drill.

In our regular 1:1, I raised this concern with my manager, who was very supportive. They asked thoughtful questions that helped me step back and consider different approaches, both technically and from a process perspective, and encouraged me to connect with more people about this issue.

After a week of persistence (and a bit of stubbornness), things slowly began to make sense. The scattered pieces I’d been collecting started to connect, and I could finally think about maintainable solutions instead of quick fixes.

I also shared this experience in our team retrospective. I knew I wasn’t the only one who found this area challenging, but something still felt off. What surprised me was hearing that some of our most seasoned teammates agreed the code was not just complex, but overly complex, with premature optimisations, a lack of meaningful comments, missing domain examples, and overly abstract design. During the discussion, we also learned that the code started as like a prototype and was never properly reviewed.

The conversation we had in our retro was very productive, no finger-pointing, just a shared focus on making things better. That’s what healthy team culture looks like 💜 Yesterday’s discussion really left a mark on me, and that’s why I wanted to write about it.

Here is what I’ve been reminded from this experience:

• Healthy teams prioritise improvement over blame. Complexity here wasn't a personal failing; it’s just a shared challenge that we can tackle together.
• Self-doubt is very common, and never* fully leaves you 🫠 For marginalised genders especially, it’s easy to think the “problem” is you. No, it’s not.
• Retrospectives are gold. Sharing struggles, big or small, is really powerful.
• Prototypes need to be re-visited. Otherwise they’ll bite later.

*: It could, with a good amount of therapy and self-work. But that’s a different story for another day.