Attila Olbrich.

A Fresh Start, Fresh Opportunities

The pandemic era brought new ways of working and new beginnings. After a successful interview, I joined a growing fintech company, still working remotely like many others during COVID. Remote work had proven itself and was becoming the industry standard.

The interview process was memorable. The CTO was attentive and observant. During our Zoom interview, he noticed the guitars on my wall, and we had a brief exchange about my outside interests. Typically, companies ask about hobbies as part of the script, but this interaction felt more genuine. To my surprise, when my MacBook Pro arrived in the post, the personal icon had been preset to a guitar. It was a thoughtful touch, creating a great first impression.

Welcoming Onboarding

My first day was remote, as expected. I met my colleagues and got to know the company’s structure. It was a small but growing fintech focused on personal loans and ISA investments. The onboarding process was surprisingly good.

Every new joiner was assigned a "buddy," someone to guide them during the early days. My buddy was a senior developer, approachable and kind. The buddy system was carefully designed—buddies were of a similar level to the new hire, ensuring approachability and comfort without hierarchal barriers. It was a strong framework, and I appreciated the effort put into it.

However, I quickly learned my buddy was soon leaving the company. This left me as the senior hire overseeing a team of junior developers under the CTO’s direct supervision. The team seemed young and full of potential, though they had been with the company for some time.

The Tech Stack

The platform's tech stack showed promise. Laravel powered the backend, with some Vue.js on the frontend. They also had a Node.js API, and the infrastructure ran on Kubernetes. My focus would primarily be backend development, so I wasn’t overly concerned about Vue.js, which wasn’t my favorite.

The First Task: A Troubled Report

My first challenge was to address a failing report generation feature. As the database grew, the report system would run out of memory and crash. This issue had been flagged for some time, and prior attempts to fix it had been unsuccessful.

After analyzing the code, I discovered the problem. The report system loaded the entire dataset into memory before paginating it—a solution that worked initially but broke as the company scaled. I reworked the approach, optimizing the query for pagination, introducing a buffered database query, and applying the generator-iterator pattern.

The result was a report system that worked efficiently, regardless of dataset size. While addressing this, I also noticed the codebase relied on a single class and function to handle all reports. It was a web of hard dependencies and deeply nested loops—a true spaghetti jungle.

I decided to create a clean, modular implementation for this report, adhering to the single responsibility principle. The new code went into a separate repository, away from the chaos.

The business was thrilled with the result. Testing on a production-like environment showed excellent performance, and my work was even recognized during the company’s all-hands meeting.

The Code Review

Submitting my code for review was an eye-opener. The junior developers swarmed the pull request with comments. While some feedback was constructive, much of it wasn’t. For instance, there were requests to revert to the original paginator—the very cause of the memory issues—or to place the new implementation back in the spaghetti jungle "for consistency."

I tried to explain the importance of scalability and the benefits of adhering to SOLID principles, but I met resistance. Faced with a tight deadline, I conceded. I moved the code back into the jungle and adjusted the paginator, sacrificing some speed for functionality.

Understanding the Resistance

Reflecting on this experience, I recognized the juniors’ resistance likely stemmed from their situation. They had worked hard at the company for years but remained juniors without clear opportunities for growth or promotion. When an outsider was hired above them, it must have felt like a blow. I could empathize, as I’d faced similar feelings in previous roles.

However, there was another surprising discovery. The company tracked developer performance by the number of pull request comments, and bonuses were tied to this metric. This explained the barrage of redundant comments—they were incentivized by the system, not by a desire to improve the code.

A New Perspective

To address the root issues, I ran a PHP metrics analysis on the codebase. The results weren’t flattering. The report highlighted numerous areas for improvement, with cyclomatic complexity and SOLID violations starkly visible. The graphical representation of the codebase was dominated by red, signaling critical issues.

I compiled the findings into a report and shared it with the CEO, offering suggestions for improvement. Unfortunately, I never heard back.

Deciding to Move On

The company was embarking on an ambitious project—a website to provide the fastest loan eligibility assessment. With my buddy leaving, I was expected to take the lead. But by then, I had decided this environment wasn’t for me.

The metrics-driven culture, resistance to change, and lack of constructive collaboration weren’t aligned with how I wanted to work. I secured a new job within two weeks, just before my probation period ended.

When I resigned, I kept my message simple. I thanked the company for the opportunity and moved forward. Every experience, good or bad, is a lesson. I took this one as a reminder to focus on communication, adapt to new team dynamics, and choose environments that support growth and collaboration.