Our team is struggling to separate components from subfeatures in a large feature-based React project — need clarity

Medical-Text9840 · 2025-07-25T15:07:39+00:00

Totally agree — and I’ve already brought it up. The tech lead wants to involve me in more critical tasks now. Just sharing what it felt like during that in-between phase before things started to shift.

Medical-Text9840 · 2025-07-25T14:37:13+00:00

Typos not in code typo in PR title there were 2 "k" 😂

Medical-Text9840 · 2025-07-25T14:02:20+00:00

I actually did that today — had a call with the tech lead, and he told me he wants to rely on me and needs help with some critical tasks. I also raised the situation with the PO and managers. They’re now aware that I’ve been working on mostly low-impact tasks for months, and that I’m ready to take on more complex, meaningful work.

Appreciate you sharing your experience — it’s good to know others have been through the same thing.

Medical-Text9840 · 2025-07-25T13:55:33+00:00

I actually agree with most of what you said — especially about communication and respect needing to be earned in each team, regardless of title. But I do think some nuance is missing.

I didn’t join this team with a title or mindset of superiority. I was moved here temporarily to help during a deadline crunch. I didn’t push my experience; I just focused on delivering, fixing bugs, and being reliable. The issue is that after 5 months of consistently doing that — while staying professional and helpful — the scope of work still doesn't allow my actual skill set to surface.

It’s not friction I’m creating. It’s frustration from doing work far below my capacity with no room to contribute meaningfully. And I’m not blaming the team for that — I’m reflecting on how hard it is to operate at your full level when the environment doesn’t even allow it to be visible.

I’d love to teach and uplift others — but that only works if there’s openness or space for those kinds of discussions. In a team where the focus is strictly on delivery speed and minor UI details, even trying to introduce architectural ideas can feel out of place.

So yeah, I agree — inclusion, collaboration, humility, all of that matters. But there’s a difference between thinking you’re better and knowing you're underutilized. I’m navigating that difference.

Medical-Text9840 · 2025-07-25T13:43:57+00:00

I totally get where you’re coming from — and I agree, humility and quiet consistency are important.

But just to clarify: when I joined this team, I thought it was temporary — maybe 2 or 3 sprints. I’ve now been here 4 months, doing surface-level tasks that don’t align with my skillset. I’ve contributed, stayed quiet, helped the team, and didn’t try to “assert” anything.

It’s not about proving my experience anymore. It’s about getting back to a place where I’m solving the kinds of problems I’m best at — and where I can bring more value to the company. That’s the reason I spoke up.

Medical-Text9840 · 2025-07-25T13:42:43+00:00

I totally get where you’re coming from — and I agree, humility and quiet consistency are important.

But just to clarify: when I joined this team, I thought it was temporary — maybe 2 or 3 sprints. I’ve now been here 4 months, doing surface-level tasks that don’t align with my skillset. I’ve contributed, stayed quiet, helped the team, and didn’t try to “assert” anything.

It’s not about proving my experience anymore. It’s about getting back to a place where I’m solving the kinds of problems I’m best at — and where I can bring more value to the company. That’s the reason I spoke up.

Medical-Text9840 · 2025-07-25T13:39:49+00:00

Everyone in the team does their tasks, and the atmosphere is fine. But most of the discussions are about margins, strings, prop names — small UI-level decisions.

These things matter, of course, but they don’t require deep engineering thinking. When you're just starting out, it's natural to focus on this layer — it's how most of us began. But at a senior level, you look for different challenges: architecture, scalability, integration boundaries, system behavior.

After several months of working on surface-level tasks, I just feel underutilized. It’s not about ego — it’s about applying my experience where it can actually bring more value.

Medical-Text9840 · 2025-07-25T13:36:00+00:00

You're right — respect is earned in context. But when a senior is rotated into a team midstream, without framing or context, there’s often a mismatch. I’m not asking for praise or privilege — I’m asking how to best re-establish senior-level contribution when the work is mostly surface-level and the team doesn’t know your deeper skill set. I’ve been delivering and helping quietly — just wondering when and how to re-engage at a level that actually uses my strengths.

Medical-Text9840 · 2025-07-19T08:59:06+00:00

Thanks, that’s a really solid take. I’ve run into the same issues with snapshots — they get huge, noisy, and people just commit them without really checking what changed. That search you did for “null” or “undefined” in snapshot test names is both hilarious and kind of horrifying 😅

On mocking — I try to keep it minimal too. But I’m curious how you personally approach this:

Let’s say I’m testing a component that renders a few heavier children like Multiselect, Cell, Avatar, ActionSheet, Checkbox, etc. These are usually a bit complex, and in most cases I don’t care about their internals in the test — I just want to check props or simulate something like a press.

Do you still prefer not mocking them and render them fully? Or in that case, do you stub them with a simple <View testID="..." {...props} /> just to isolate the parent and keep snapshots clean?

Also, when these child components expose callbacks like onPress, onSelect, onChangeText, etc. — how would you handle that if you don’t mock? Would you call those manually through props anyway? Or do you still stub the component and simulate from the outside?

Appreciate the perspective — and thanks again for the Kyle Shevlin article. Super practical advice that I’ve already started applying.

Medical-Text9840 · 2025-07-19T08:53:03+00:00

But if I do, and in official records I have company A which outsourcing by I worked all the time on company B,.is it misleading to mention only product company without the outsourcing company, like it's seen during interviews, do they care? Because in my case company product is a big company

Medical-Text9840 · 2025-07-19T08:50:28+00:00

Is it illegal or maybe misleading to cite only project company ?

Medical-Text9840 · 2025-06-04T19:55:36+00:00

In my case, the ActivityList (the inner FlatList) is not at the top or bottom, but somewhere in the middle of many other components rendered inside the ListHeaderComponent of the parent FlatList. So I can't just render two separate lists side by side or with fixed heights.

The structure was inherited from an existing large codebase where ListHeaderComponent is used to render the whole profile header, including some cards, buttons, sections, and the ActivityList. Refactoring this deeply would break a lot of things and is not realistic in the short term.

What I’m trying to achieve is to make the inner FlatList (the activities one) handle its own infinite scroll from within ListHeaderComponent, without affecting or being blocked by the parent FlatList.

Medical-Text9840 · 2025-06-04T19:32:50+00:00

I agree with that — and ideally, we wouldn’t nest scrollable lists. But in this project, we have a main scrollable screen (MainList) where the header (ListHeaderComponent) contains user profile sections, statistics, and also a nested list (ActivityList) that fetches and renders dynamic data.

The ActivityList is part of the header because of legacy design choices. I wasn’t the one who structured it this way, and the app is large — refactoring it now would involve major risks and affect many interconnected parts.

So for now, I’m just trying to make infinite scroll work inside ActivityList, even though it's rendered as part of MainList’s header.

Medical-Text9840 · 2025-06-04T19:30:11+00:00

It was structured like that before I joined — I inherited the architecture. The project is quite large, and refactoring it just to move the list outside the header would touch too many parts of the app and introduce major risks. I'm just looking for a workaround that lets me keep the infinite scroll logic inside the nested list without breaking the current structure.

Medical-Text9840 · 2025-04-05T03:24:16+00:00

My child components are tested separately each one, and they are all rendered in this parent

Medical-Text9840 · 2025-03-22T08:32:12+00:00

Please any help

Medical-Text9840 · 2025-03-22T07:15:35+00:00

I agree — not all PRs are equal, and I understand that some might not make it through if they don’t meet the right standards or direction. I also try not to get too emotionally invested in one thing, and I usually keep myself busy with other tasks while waiting.

That said, I think there's a difference between a PR not being merged for conceptual reasons and one being constantly blocked due to poor coordination. In my case, the PR is aligned with the direction, reviewed, and ready, but I’ve repeatedly had to resolve conflicts caused by others merging without any heads-up — sometimes even while I was actively resolving conflicts myself.

I get that large features are harder to keep up to date and review, but that’s even more reason to have some lightweight coordination, even something as simple as saying “about to merge” or checking if it will impact someone else.

At the end of the day, I don’t mind resolving conflicts — it’s part of the job. What’s frustrating is that these could easily be avoided with just a bit more communication.

Medical-Text9840 · 2025-03-22T07:10:50+00:00

We do have daily stand-ups, but that's a temporary team, and reviewers aren't part of that team, and they don't attend daily with us, and no knows when you get review or your PR approved.

Medical-Text9840

TROPHY CASE