From Backend to Frontend and Back Again

Chapter 1: The Backend Years

I got in touch with the Java programming language back in school. My teacher introduced us to this — at the time — new and object-oriented language, and something about it just clicked. That early spark stayed with me through my studies, where I continued to work with Java in various small projects.

My first job came during this time — as a junior dev at an agency building software for a public transport authority. We were creating some of the first web applications in that space, along with personalized solutions for passengers. Web development at that time was mostly HTML paired with Java, and so I naturally went with it.

After finishing my studies, I moved to Hamburg to take on what felt like my first "real" job. It was with a company that worked closely with the same agency and had just launched a mobile ticketing solution for the local public transport provider. I joined as a backend developer, responsible for the internal logic around ticket booking and data management.

As smartphones took over the world and iOS and Android became dominant, frontend and backend naturally began to split more clearly. That’s when I really doubled down on backend development — using Java, Spring, Spring Boot, and diving deep into databases and system design.

Over the years, my responsibilities grew. I took over core processes like payment management, banking integrations, and the ticketing logic itself. In the end, I was functionally responsible for all payment and settlement workflows across multiple ticketing solutions — mobile, card-based, and more. I also helped define and integrate a wide range of fare models for public transportation systems.

Chapter 2: The Big Shift

At first, my decision to leave the company I had worked at for over a decade wasn't driven by technology. It was personal.

I had been there since 2009, invested deeply, and was always ready to give more than just my time — I gave energy, ideas, and loyalty. But over time, cracks appeared. There were differences in how long-term commitment and experience were acknowledged and valued. That was tough to swallow. Eventually, it became clear: it was time to move on.

But after almost 15 years in one role, I didn’t want just a new company — I wanted something entirely different. Staying in the same sector didn’t feel right anymore. That’s when a friend told me about an interesting opportunity outside of public transport.

Frontend development wasn't entirely new to me. I had been toying around with it in my free time, experimenting with pet projects. So the thought crossed my mind: why not give it a real shot?

The role was a hybrid at first — a mix of new frontend tech and the familiar Java backend. That made the transition smoother. But it didn’t take long until I dove fully into the frontend world, picked up React, and began to explore everything that came with it.

Chapter 3: Learning Curve

I wasn’t completely new to React. I had played around with React Native before, so I had a rough idea of how components and props worked. But stepping into a full professional frontend setup — especially with React and Next.js — was a whole different story. The learning curve was steep.

The first days (and weeks) were full of trial and error. I could only manage simple steps. Everything felt unfamiliar — not just the tools, but the expectations. Suddenly, I wasn’t just implementing logic. I was working with detailed, pixel-perfect UI specs, following UX designs, matching colors and margins with precision. That was new territory.

And once I thought I had a grip on layout and styling, I realized that frontend wasn’t just about making things look good. It was about making things work well — for users and for search engines. I dove into topics like SEO, accessibility (A11y), Google Core Web Vitals, and performance optimization. Every day brought something new.

And just when I was proud of finishing a feature, with passing unit tests and everything seemingly in place, my experienced frontend colleagues would gently (and sometimes painfully) show how it could’ve been done better, cleaner, more idiomatic. Those moments were frustrating. But I listened, and I learned.

A few weeks later, something shifted. I was building complete frontends for new products. Customers were happy. Code reviews came back without critical remarks. And for the first time in this new role, I felt a deep sense of pride. I wasn’t just trying to keep up anymore — I was contributing.

Chapter 4: Finding Flow

What really stuck with me was the sense of impact.

We were a small team — six developers — building a brand-new product from scratch. Every line of code we wrote mattered. You could literally see the product grow day by day. It wasn’t just theoretical progress buried deep in some system; it was visual, tangible, real. This tangible progress was a refreshing change from the backend's often unseen contributions.

And people noticed. Colleagues, stakeholders, even customers — they could see what we built. They were excited. That was a big contrast to my backend years. Of course, backend code can be elegant, well-structured, even beautiful — but most of it lives in the shadows. Unless you're another developer, you'll never see or appreciate it.

Frontend was different. We were building interfaces that people actually touched.

And what surprised me most? How fast I got into it. After the initial bumps, I quickly found a rhythm. Writing React components, tweaking behavior, watching things come to life in the browser — it was more enjoyable than I expected. There was a real sense of flow.

Chapter 5: The Return to Backend

Interestingly, the decision to return to backend wasn’t entirely my own.

One day, our CTO approached me with a question. The company had a shortage of experienced Java developers — and I had history. He asked if I could imagine switching back. It wouldn’t just mean returning to Java, but also joining a completely new team and diving into a completely different domain.

I wasn’t unhappy with frontend work. Not at all. But deep down, I knew how far I still had to go to reach the level of my frontend colleagues. It was a long and steep road, and while I enjoyed the journey, this offer felt like a chance to go home — back to the world I once mastered.

So I took it.

But coming back into backend after two years in frontend changed my perspective. It was impossible to unsee how different the rhythms were. Frontend development moves fast — new frameworks, libraries, paradigms popping up almost weekly. In backend, it was still Java. Still Spring. Still structured and stable. It felt… slower. More deliberate.

Not worse — just different.

Honestly, at times it feels like coding in slow motion. But with that slowness comes depth, and predictability, and stability. And this time, I’ve brought something new with me: an understanding of the full picture — how backend decisions surface in the UI, how API shape influences user experience, how performance isn’t just a database concern anymore.

Chapter 6: Lessons Learned

Looking back, this journey wasn’t just about switching from backend to frontend and back again. It was about learning to work differently.

Each change — be it in team, framework, language, or domain — forced me to stay sharp. I had to pick up new terminology, grasp new expectations for quality, and adapt to fresh perspectives on what makes software great. And that kind of disruption is healthy. It keeps you learning, honest, and humble.

One of the biggest shifts happened in my perception of frontend vs. backend. As a backend developer, I often thought of the backend as the real engine — and the frontend as just “putting the data in the right spot.” But once I stepped into the frontend world, I quickly realized how far off that was.

Frontend is so much more than pretty visuals. It’s UX and UI design that shape how people feel using your app. It’s accessibility for users with impairments. It’s building for both users and crawlers. It’s performance, perception, and emotional response — not just function.

So here’s my deepest takeaway:

Only by working on both sides can you truly understand what makes an experience feel complete.

That’s what makes a full-stack developer. Not just writing code across the stack — but thinking across the stack.