DEV Community: Nina Ricci

From Frontend to Backend: How I Transitioned Across the Stack in a Real Product Team

Nina Ricci — Wed, 03 Jun 2026 06:14:04 +0000

From Frontend to Backend: How I Transitioned Across the Stack in a Real Product Team

I’ve always been more interested in backend engineering since the beginning of my career.

But for a long time, I didn’t really get the opportunity to work deeply on it.

There were a few reasons for that:

Frontend work was less “popular” in most teams, so I often got assigned there
The backend systems in earlier teams were already stable, so there wasn’t much need for hands-on changes
Team structure mattered. I was usually placed in frontend-focused squads

So even though I was curious about backend systems, I naturally ended up building frontend-heavy experience first.

That changed when I joined a product that was being built from the ground up.

🌱 Starting point: Building from scratch in a new product team

In this new setup, I was the sole frontend engineer.

We also had:

a sole backend engineer
a sole data engineer

It was a very lean team building an MVP from scratch.

At this stage, I still focused mainly on frontend delivery but I was already paying attention to how the backend was being designed, because I wanted to understand the bigger picture, and how backend decisions would shape the frontend.

🚀 The turning point: After MVP, the backend needed more hands

Once we shipped the MVP, the reality became clear:

We needed more support on the backend side.

At the same time, management explored whether someone could transition internally from other teams.

That was the moment I saw an opportunity.

Instead of waiting to be assigned, I proactively reached out to my manager and expressed:

my interest in backend work
my willingness to start small
my intention to gradually transition across the stack

I didn’t jump straight into backend ownership. Instead, I built trust through incremental steps:

taking small backend tasks
pairing with engineers when needed
asking for knowledge-sharing sessions
gradually expanding my scope beyond frontend

That was the beginning of my real transition.

⚡ Becoming intentional about cross-stack ownership

What helped me grow wasn’t a sudden switch, it was being deliberate about the kinds of tasks I picked up.

I actively sought exposure to different areas of the system, including:

API design and implementation
backend workers and async processing
third-party integrations
data-related tasks and debugging
alerts and monitoring setups
production issue investigations
documentation and internal knowledge sharing

Over time, I stopped thinking in terms of “frontend tasks” or “backend tasks”.

Instead, I started thinking:

“What does this feature need end-to-end to actually work in production?”

That shift changed how I approached engineering.

🛠 Expanding scope: From features to systems

As I grew more comfortable, I started owning larger and more complex modules across the stack.

I wasn’t just implementing parts anymore, I was responsible for making sure features worked end-to-end, from API design to frontend behavior to production readiness.

At some point, I also began contributing to backend evolution work, working with event-driven systems and message queues like RabbitMQ, as well as making decisions around database design and how we process and consume raw data into our system.

This phase pushed me to think beyond features and start understanding how systems behave under real production constraints.

✨ What stood out most in my transition

Looking back, I think the biggest change wasn’t technical, it was behavioral.

I stopped waiting for backend opportunities
- I actively created them by expressing interest and taking ownership.
I treated scope expansion as a process, not a switch
- Small tasks first → then gradual ownership → then full modules.
I looked for problems across the system, not just my area
- I started engaging with:
  - production issues
  - monitoring gaps
  - reliability concerns
  - documentation improvements

I also became more intentional about making my work easier for others to build on, whether through clearer documentation, better testing guides, or more predictable APIs.

🧠 Final thoughts

My transition from frontend to backend wasn’t really a “career switch”.

It was more of a gradual expansion of responsibility, driven by curiosity and intentional effort.

If I had to summarize it:

I didn’t become a backend engineer by switching roles.

I became one by continuously asking for more ownership across the stack.

And once you start doing that, the labels stop mattering as much as the problems you’re solving.

3 Communication Signals in Engineering Teams That Improve (or Hurt) Productivity

Nina Ricci — Tue, 02 Jun 2026 09:24:40 +0000

3 Communication Signals in Engineering Teams That Improve (or Hurt) Productivity

In engineering teams, progress isn’t always as clear as it looks.
What seems “on track” can quietly hide delays, misalignment, or unclear expectations.

And the challenge is—you often won’t notice these signals unless you know what to look for.

As an engineer, I’ve seen how easily these situations can be misunderstood, especially from the outside. This post is a way to surface a few common patterns and how to respond to them in a way that improves communication and team alignment, rather than creating tension.

1. Underestimating and Overpromising

You might hear something like:

“Yeah, this should be quick. Probably just a day or two.”

…and then it ends up taking much longer.

This usually isn’t intentional. It often comes from:

Underestimating hidden complexity
Pressure to give a fast answer
Not fully seeing edge cases or integration work upfront

💡Instead of calling it out directly—especially in a team setting where it can create tension or make someone defensive—try asking:

“What could potentially slow this down?”
“Are there any risks or unknowns we should consider?”

This keeps the conversation open and helps the team build a shared understanding of what “done” actually involves, without putting anyone on the spot.

2. New Bugs After Every Release

Every release having bugs is normal. No system is perfect.

But if every release consistently introduces noticeable issues, it might signal:

Rushed or incomplete testing
Gaps in QA or review processes
Pressure to ship quickly over shipping safely

💡Instead of pointing it out in a way that feels like criticism, try opening the conversation:

“How confident are we with this release?”
“What parts of the system feel risky right now?”

Framing it this way helps the team reflect together on process improvements, rather than focusing on individual mistakes.

Over time, this can lead to more stable releases and better engineering practices.

3. “I’m Almost Done”

This one shows up everywhere 😅

You’ll hear:

“I’m almost done.”

But “almost done” can sometimes stretch much longer than expected.

This often happens because:

The remaining work is more complex than expected
The final details weren’t fully accounted for
“Done” isn’t clearly defined yet

💡Instead of calling it out directly—especially in a way that might create pressure or tension in a team setting—try asking:

“What’s left before this is fully complete?”
“Is anything blocking you from finishing this up?”

This helps clarify what’s actually remaining and reduces misunderstandings around progress.

Final Thoughts

The goal isn’t to catch people doing something wrong—it’s to improve how the team communicates so issues surface earlier and everyone can work more smoothly together. These are also worth revisiting in tech team retrospectives so improvements happen on both sides.

I’m curious—if you’ve worked in a team before, which of these have you seen the most? And what’s one thing you think makes communication in teams work really well?

How to Trigger React Error Boundary with React Developer Tools

Nina Ricci — Sun, 17 Jul 2022 11:46:16 +0000

What is a React Error Boundary?

According to react.js documentation, Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them. (Read more)

Use case

We want to test how our application handles error states. Using the React Developer Tools, we won't be needing to manually force an error state in our code for each component we want to test. Instead, we can just select a component from the tool and force it to be in an error state.

Prerequisites

React Developer Tools chrome extension
- installation
A working React App with React Error Boundary

Demo

Start your React Application and open it on your Google Chrome web browser. (make sure you already have React Developer Tools chrome extension installed)
Open your Chrome Developer Tools and navigate to Components tab.
```
shift + CTRL + J (Windows/Linux).
option + ⌘ + J (macOS)
```
Select a component within the Error Boundary in the tree.
- Notice the (!) icon. Hovering it should show a help dialog "Force the selected component into an errored state"
Click on the (!) icon
- This will force your app to be in an errored state

Git Conflicts; Fixing it with Git Rebase

Nina Ricci — Mon, 07 Feb 2022 09:43:48 +0000

Getting past the basic git clone, commit, add, pull and push, I have learned a few good to know git commands over the years because of repeatedly common problems I've faced when doing version control. I'm planning to create a series for this topic in hopes that this can also help you.

Here's a very short story of how a Git conflict can happen and how to fix it with Git rebase.

Git Conflicts

Usually, these problems are faced when the team gets bigger and a lot more devs are contributing to the same project on the same file.

2 devs working on the same file.

This is very common and it's okay, so don't worry! What I usually do is to plan ahead with the other dev so we know both of us are working on this specific same file. To minimize merge conflicts and efficiently fix them, we want to always rebase from develop whenever there are any changes so we always have an updated version of the base branch.

DAY 1 🌞

dev 1 creates and works on feature A

git checkout develop
git branch -b feature/feature-a
# work on file A

dev 2 creates and works on feature B

git checkout develop
git branch -b feature/feature-b
# work on file A

in between the day, dev 2 who was working on feature B asks for a code review and merges their branch to develop. dev 1 who is working on feature A git add and commits all their changes for the day.

DAY 2 🌞
since, dev 2's branch (feature B) was merged to develop and we know that both devs had worked on the same file, dev 1 (feature A) will now rebase from develop branch to have an updated copy on their current feature branch and fix the conflicts.

dev 1, feature A rebases from develop and fixes conflicts

# don't forget to git add and commit your changes first
git checkout develop
git pull origin develop
git checkout feature/feature-a
git rebase develop
# by this time, git will write your commits on top of develop 
# and you will be seeing the conflicted files

go to the conflicted file and if needed, consult with dev 2 and make sure you save the file where both changes are written.

# resolve conflicted file/s
git add path/to/file
git rebase --continue

git rebase interactive should be done after you finish fixing the conflicted file and you are good to go. 👍

Notice that Feature A now is on top of both develop and Feature B that was merged the day before.

Thank you for reading all the way here! I hope you've learned something new and that this can help you on your productivity and collaboration with your team 🤝

How honesty can improve team productivity

Nina Ricci — Thu, 07 May 2020 13:46:28 +0000

How can being honest actually improve your team's productivity? Let me share with you a few scenarios where you may find yourself in and what you can do and why you should do it.

When you are stuck with your code for more than the usual time it will take to fix something.

Be honest and tell your team you're stuck but make sure you've done your part in trying to fix it. With this, you're likely to progress faster if someone helps you. In fact, it's possible that someone from your team has already encountered it and the time you'll invest for like 1-2 hours could be lessened to a single question.

When something broke and you know it was you who broke it

Be honest and volunteer to fix it. You'll probably take lesser time to fix it rather than someone who has little idea of the cause.

When you don't know the answer to a question

Be honest and tell the person you don't know but try to find the answer after. It's better to tell upfront that you don't know rather than assume something and cause a misunderstanding.

If no one has been honest yet, be the first one

Other members can feel comfortable being honest themselves if someone within the team continuously do so. Everyone would feel that they can trust each other. The feeling of not being discriminated of not knowing or of making mistakes can improve the team's communication. Anyone could learn a thing or two just by someone saying "I don't know" or "I'm stuck. Can someone help me?". And without you knowing it, honesty has become one of your team culture.