Transitioning To Frontend Developer @ AgileSoDA

Starting Out: Data Analyst

This was my third and final job as a data analyst—and the stepping stone that led me to become a web developer.

Roughly half of my time here was spent on projects attempting to predict stock price movements. Unsurprisingly, we failed pretty hard—our models hovered around 50% accuracy, a glorified coin toss 👍. In hindsight, we leaned too much on modeling without truly understanding the data or domain—and honestly, even the modeling itself wasn’t that deep. We, including the lead analyst, treated a sophisticated algorithm like XGBoost as just another function call, blindly tweaking hyperparameters and hoping for the best.

It baffled me how some professionals could hold advanced degrees yet treat complex models like black boxes without making an effort to understand what’s going on under the hood. This project felt like a failure from the very start.

When the data doesn’t contain any meaningful signals, no amount of modeling or data processing will improve the outcome—in other words, garbage in, garbage out. And what we often mistook for a “signal” turned out to be noise or even errors in the data processing pipeline.

That’s ultimately why I started losing interest in data analytics. I was frustrated by how much the quality of a data analyst’s work depended entirely on the quality of the data—and high-quality data was rare in the projects I was on.

On the other hand, I found myself far more engaged in the peripheral IT work that was nonetheless essential for data analysts to get things done: Linux shell scripting, cron jobs, process management, SSH tunneling—not to mention distributed big data technologies like Hadoop and Spark.

So I was lucky when I got involved in a project that required migrating client data from Oracle to our analytics cluster, which ran on HDFS. I used Sqoop to move entire databases into Hive tables, and manually rewrote complex Oracle SQL into HiveQL.

This kind of hands-on experience—and my growing curiosity for engineering—paved the way for a role change that would shape the rest of my career.

Switching Tracks: My First Engineering Role

After repeatedly showing my interest and aptitude for engineering work, I was finally allowed to transfer to the development team. Our product was a B2B analytics platform targeted at fellow data analysts—so I brought in the unique advantage of having once been the user myself.

I was optimistic. Maybe even overconfident. I thought my background in R, Python, and Linux would help me ramp up quickly. What I didn’t anticipate was the sheer scale of the stack I was thrown into:

• A backend in Java (with Vert.x),
• A frontend in React,
• MariaDB as our database,
• Deployed on Docker and Kubernetes—despite the fact that a single-node setup probably would’ve sufficed.

I spent months working 3-4 extra hours every night just to catch up. Reading docs, debugging unfamiliar codebases, failing and learning repeatedly. But slowly, things began to click.

Eventually, I was building major features independently. But as I got more familiar with the system, I also started questioning architectural decisions:

• Why Kubernetes, when a simpler setup could’ve worked?
• Why not Docker Compose for container orchestration?
• Why choose Vert.x over more conventional frameworks?
• Why use GlusterFS when we didn’t need distributed storage?

These questions felt important because they directly impacted our productivity as we tried to build a real product—and we were constantly bogged down by the friction these technologies introduced.

I didn’t always find clear answers, and the more aware I became of the issues, the more frustrated I felt—in hindsight, this growing frustration probably planted the seed for me to look for a better engineering opportunity.

My frustration actually peaked with the state of the frontend codebase. The React app was bootstrapped with this now-defunct boilerplate, meant for isomorphic rendering. But we were only doing client-side rendering—meaning we didn’t need all the overhead of Node.js and SSR and a simple static hosting would have sufficed, yet we still had a complex server and bloated architecture. I gave an internal presentation just to express my concern.

Finally, a Greenfield Frontend Project

I was fortunate enough later on to be asked to build the UI for a brand new product from scratch. I was thrilled. Finally, I could:

• Use modern React with hooks (no more class components)
• Pick sensible libraries (while keeping the dependencies minimal) such as:
  • Blueprint.js
  • TanStack Table
  • ECharts
  • styled-components
• Avoid unnecessary complexity.

But as excited as I was about hooks, I quickly ran into issues with useEffect(). Some effects grew so convoluted that I had to sprinkle in console.log() just to understand their runtime behaviors. I admit I overused them due to my limited understanding of the React rendering model, and in the end, some of my own useEffect()s were so fragile I was afraid to touch them.

That pain stuck with me—and it was the beginning of my journey toward writing better, more maintainable frontend code. In many ways, it also marked the true start of my identity as a frontend developer.