u/MiserableLime5289

I keep seeing this pattern in programming discussions — developers who know multiple languages (Python, JavaScript, Java, etc.), sometimes even quite well, but still struggle when it comes to actually solving problems or building systems from scratch.

What makes it interesting is that language knowledge looks like progress on the surface. You can switch between syntax, frameworks, and tools… but the underlying struggle often remains the same.

Some common patterns I’ve noticed:

• they can write code in multiple languages, but struggle when the problem is open-ended
• they’re comfortable following tutorials, but get stuck without step-by-step guidance
• they know “how to code” in different syntax styles, but not how to structure solutions
• the same confusion appears again, just in a different language
• switching languages gives a sense of progress, but not necessarily better thinking ability

It almost feels like the bottleneck isn’t the language at all.

Which raises a bigger question:

Are most programming struggles actually about language knowledge, or about how developers think, break down problems, and approach unfamiliar situations?

So:

• have you seen developers hit this kind of plateau?
• does learning multiple languages actually improve problem-solving ability, or just expand familiarity?

This is something I keep seeing in React Native apps — and it feels more common than it should be.

Image-heavy screens (feeds, product grids, galleries, profile lists, etc.) often work perfectly fine during development… but once the app hits production usage, they become some of the most unstable parts of the app.

What’s confusing is that it doesn’t always fail immediately. Instead, it usually shows up as:

• random crashes after scrolling for a while
• sudden lag spikes on certain devices
• memory pressure issues that are hard to reproduce locally
• UI freezing when multiple images load at once

A few things that seem to contribute to this pattern:

• image decoding + memory usage stacking up quickly on mobile devices
• too many high-resolution images being rendered at the same time (especially in lists)
• inconsistent caching behavior across Android and iOS
• components not cleaning up properly when navigating away
• re-renders triggering multiple image reloads unintentionally

What makes this even harder is:

• it often doesn’t reproduce in dev mode
• it depends heavily on real device memory limits
• production builds expose issues that are invisible during testing

So it raises a real question:

Is this mainly a performance optimization problem, or is it more of an architecture problem in how we design image-heavy screens in React Native?

Because in many cases, even small UI changes (like adding more images or increasing list size) can suddenly make a stable screen start breaking under real-world usage.

Curious how others have handled this:

• what actually caused image-heavy screens to crash in your React Native apps?
• did you solve it through optimization (caching, lazy loading), or by changing architecture?
• is FlatList + images still reliable at scale, or do we need different patterns altogether?

I keep noticing a pattern in React Native apps where navigation issues are hard to catch during development, but start appearing once the app is in production or used in real environments.

In dev mode, navigation usually feels smooth and predictable:

• screen transitions work as expected
• routes are easy to trace using dev tools
• issues are often reproducible and visible immediately

But in production builds, things sometimes behave differently:

• occasional navigation glitches that never appeared in dev
• race conditions during fast screen transitions
• deep linking or initial route issues that are hard to reproduce locally
• problems when the app is resumed from background state
• edge cases triggered by real device performance or timing

What makes it confusing is that the navigation logic itself hasn’t really changed — only the build type and runtime conditions.

I understand that release builds are optimized and behave differently from development builds, but the inconsistency in navigation behavior can make debugging difficult.

For developers:

• Why do navigation-related issues tend to appear more in production than in development?
• What are the most common underlying causes (timing, state, lifecycle, build differences)?
• How do you usually debug navigation issues that don’t reproduce locally?

There’s a pattern that keeps showing up in real projects, writing new code often feels much easier than working with existing codebases.

When building something from scratch, everything is clear:

• the structure is in your head
• the decisions are yours
• there’s no hidden dependency or unexpected behavior yet
• you know exactly why each piece exists

But maintaining old code feels like a completely different job.

Even small changes can turn into a long process because you first have to:

• understand why something was originally written that way
• trace logic spread across multiple files or services
• deal with older decisions made under different requirements
• figure out hidden dependencies that are not obvious at first glance
• work around missing or outdated documentation

What looks like a “small fix” often becomes a process of understanding the system before actually changing anything.

It sometimes feels like:

>

So the question is:

• Why does maintaining old code often feel harder than writing something from scratch?
• Is it mainly a design issue, a scaling reality, or just how software naturally evolves over time?

A lot of things in programming only really make sense after working on real production systems, not while learning through tutorials or building small projects.

One of the most common realizations is that writing code is usually not the hardest part of the job.

In real-world development, the harder challenges tend to be:

• understanding why something works locally but breaks in production
• dealing with edge cases that were never part of the original design
• debugging issues where logs don’t clearly explain what actually happened
• maintaining and modifying code that was written long ago (sometimes by multiple people)

Another thing many developers realize later is that “clean code” in theory often looks very different in practice, where trade-offs, deadlines, and business constraints matter more than perfect structure.

Over time, a lot of the work shifts toward:

• reading and understanding existing codebases
• tracing how different parts of a system interact
• figuring out the reasoning behind older design decisions

In hindsight, these skills often end up being just as important—if not more important—than writing new features from scratch.

So the question for developers:

• What’s something most developers only learn too late?
• Was there a moment that changed how you think about programming or software development?
• What’s a skill you wish you had focused on earlier?

I keep running into something strange while working with React Native — debugging in development and production builds feels completely different.

In dev mode, everything feels straightforward:

• errors are easy to trace
• logs are immediate and detailed
• performance issues are more visible
• debugging tools make it easier to understand what’s happening

But in production (release) builds, things feel very different:

• some bugs completely disappear
• new issues show up that never appeared in dev
• crashes are harder to reproduce
• logs are limited or not very helpful
• certain UI or performance issues only appear on real devices

What’s confusing is that the code is the same, but the behavior changes enough that debugging becomes a completely different process.

I understand dev mode adds extra tooling and overhead, but in real projects the difference sometimes feels big enough to affect how you even approach debugging and testing.

For developers working with React Native in production:

• Why does debugging behave so differently between dev and release builds?
• What are the most common reasons bugs only show up in production builds?
• How do you usually debug issues that don’t reproduce in development mode?

We had this assumption early on that once we “get the right people in,” execution would naturally improve.

Like, if we hire smart, capable people, things will start moving faster, smoother, more predictably.

But after going through a few hiring cycles, that assumption didn’t really hold up.

What we noticed instead was that even after bringing in good people, execution issues didn’t disappear, they just changed shape.

1. Sometimes things got slower because coordination became harder.
2. Sometimes priorities were still unclear, just now across more people.
3. Sometimes work was happening, but not in the direction we actually needed.

It slowly became obvious that hiring alone doesn’t fix execution problems.

The bottleneck wasn’t always talent — it was clarity, ownership, and how decisions actually flow inside the business.

So,

• Did hiring more people actually improve execution for you?
• Or did the same problems just scale with the team?
• What actually made execution better in your case — people, systems, or leadership changes?

I’ve been working with React Native for a while, and one thing I still can’t fully wrap my head around is this:

Even in 2026, debugging React Native issues often feels more painful than debugging either pure web apps or fully native apps.

On paper, it should be simpler — one codebase, shared logic, faster iteration. But in practice, small issues sometimes turn into long debugging sessions.

Some examples I’ve personally noticed (and I’m curious if others feel the same):

• A bug that only appears in release builds, not debug mode
• Layout issues that behave differently between iOS and Android
• Performance drops that don’t show up during local testing
• Errors that don’t clearly point to whether the issue is JS, bridge, or native side

What makes it more confusing is that React Native sits in the middle of multiple layers — JavaScript runtime, native modules, platform-specific behavior, bundling, etc.

So when something breaks, it’s not always obvious where to even start looking.

Compared to web or native apps, debugging there often feels more “direct” — fewer abstraction layers.

Maybe it’s just the trade-off of cross-platform development, but I’m wondering:

• Is React Native debugging actually improving with newer tooling?
• Or is this still an inherent limitation of the architecture?
• What’s your go-to strategy when something breaks in production RN apps?

Whenever React Native comes up, someone eventually points out that companies like Meta use it across products such as Facebook, Instagram, Messenger, and Meta Quest. Microsoft has publicly used it in apps including Teams, Outlook, Skype, and Xbox Game Pass. Shopify has also shared how React Native became a key part of its mobile development strategy.

On the surface, that sounds like a strong argument for choosing React Native.

But those companies also have massive engineering teams, custom tooling, and resources that most startups will never have.

So I've started wondering whether we're drawing the wrong conclusion from those success stories.

Have you found React Native to be a great fit because of the framework itself, or because success depends much more on the engineering practices behind it than the technology?

I'm at a stage where I'm thinking about how software startups build their engineering teams as they grow.

When you're a solo founder or a very small team, you usually need people who can do a bit of everything and move quickly. But I imagine the hiring process changes as the company grows and the stakes become higher.

For founders who've already been through that journey, I'm interested in what actually worked in practice—not what's written in hiring guides.

If you've grown from a solo founder (or a very small team) to 20+ people, how did your technical hiring evolve?

• What hiring approach consistently brought in your best engineers?
• At what stage did you stop looking for generalists and start hiring specialists?
• Is there one thing you now look for in technical candidates that you completely ignored in the early days?

One decision I've seen many founders struggle with is whether to outsource Android development or build that capability in-house.

On paper, outsourcing can seem like an easy way to reduce costs, move faster, and access specialized talent without making long-term hiring commitments.

But I've also heard stories from founders who ran into unexpected challenges around communication, product ownership, development quality, and execution speed as their business grew.

For entrepreneurs who have actually outsourced Android development, was it ultimately a competitive advantage or a source of challenges for your business?

We’re at the stage where we need to decide where to put our effort first—building the product properly or trying to get users early through marketing and distribution.

Android keeps coming up in that decision.

Part of me feels like having a solid Android app early could be a growth advantage because that’s where a big chunk of users are. But at the same time, I keep hearing founders say they spent too much time perfecting mobile apps before they even knew what users actually wanted.

And I can see both sides.

If you build too early, you might waste time building the wrong thing.
If you delay it, you might miss out on real user feedback and momentum.

So now I’m honestly stuck trying to understand what actually matters more in the early stage.

For founders who’ve been through this: did early Android development actually help you grow—or did it become something you wish you had delayed?

We’re in the early stage of building a new product (currently validating the idea and planning our MVP). Our goal is to move fast in the next few weeks without overcomplicating the initial build.

At first, the decision seemed straightforward: hire a strong full-stack developer so one person can own the entire product and help us iterate quickly.

But after talking to a few founders and engineers, I’m getting mixed advice and I’m genuinely unsure what the right approach is.

Some argue that a full-stack developer is ideal early on because:

• Faster development cycles
• Less coordination overhead
• One person can make end-to-end decisions

Others say this becomes a bottleneck quickly and that:

• Specialized roles (frontend/backend) scale better
• Full-stack ownership can slow down complex builds
• You often end up restructuring the team sooner than expected

What’s confusing is that both approaches seem to work depending on the startup.

So I’m trying to understand real-world experience rather than theory.

For founders or engineers who have gone through early-stage product builds:

• At what stage did you choose full-stack vs specialized roles?
• What worked better in your case, and why?
• If you were starting again, would you make the same decision?