Three months into a new project, our builds were taking 12 minutes. Everyone complained. Nobody investigated.

“That’s just how it is with large codebases.”

A new teammate joined. Day two, she asked: “Why does this take so long?”

We shrugged. She didn’t. She spent an afternoon digging. Turns out we were bundling dev dependencies in production. One config change later: 3-minute builds.

Twelve months of collective frustration, solved in an afternoon—because one person refused to accept “that’s just how it is.”

🚫 The Phrase That Stops Progress

“That’s just how it is” is the most expensive sentence in software development.

It sounds like acceptance. It’s actually resignation.

I’ve heard it everywhere:

• “Deployments always break on Fridays.” (They don’t have to.)
• “The staging environment is always down.” (There’s a reason.)
• “This feature is too complex to test properly.” (Probably not.)
• “Our standups always run long.” (They shouldn’t.)

Every time someone says “that’s just how it is,” they’re drawing a line. On one side: things we can change. On the other: things we’ve decided to live with.

High-performing teams don’t have that line.

🔍 The Nadia Makarevich Approach

Nadia Makarevich did something most React developers don’t do: when everyone said “React is slow,” she didn’t just accept it.

She investigated. She measured. She dug into the actual bottlenecks—not the assumptions, not the conventional wisdom, but the real technical reasons behind performance issues.

And she found the truth was more nuanced than “React is slow.” It was about how people were using React. About unnecessary re-renders, about component architecture, about understanding the actual mechanisms at play.

That’s the difference. Most people stop at the surface answer. Great engineers keep asking “why?” until they understand the system.

I learned this the hard way. Early in my career, I accepted so many things as unchangeable:

• Our code reviews always took three days. (Because we didn’t have a process.)
• Our API responses were slow. (Because nobody looked at the queries.)
• Our bug count kept climbing. (Because we weren’t tracking patterns.)

None of these were inevitable. They were all solvable. But solving them required curiosity—and permission to question the status quo.

🎯 What Curiosity Actually Looks Like

Real curiosity isn’t just asking questions. It’s being willing to investigate when everyone else has moved on.

• Surface level: “Why is this failing?”
• One layer deeper: “Why is this condition triggering?”
• Actual root cause: “Why did we structure it this way?”
• System insight: “What does this tell us about our architecture?”

I remember a bug that kept appearing in production. Every time, we’d patch it. Every time, it would come back in a slightly different form.

Finally, someone asked: “Why does this keep happening?”

Turns out our error handling was masking a deeper issue—a race condition we’d been dancing around for months. We’d been treating symptoms. We needed to understand the disease.

Once we saw the pattern, the fix was obvious. But we’d been too busy firefighting to step back and ask “why?”

🧠 Code Matters When It Solves Problems

Here’s something that took me too long to learn: code only matters when it solves customer problems.

You can write the most elegant, performant, beautiful code in the world. If it doesn’t help a user accomplish something, it’s just expensive art.

I spent days once refactoring a component to be “perfect.” Clean, reusable, well-tested. I was so proud.

Then in a user session, I watched someone struggle with the feature it powered. The refactor didn’t matter. The core interaction was confusing.

All that beautiful code was solving the wrong problem.

Great engineers don’t just ask “why is this code slow?” They ask “why does this code exist?” and “what problem is this actually solving for users?”

That shift—from “code works” to “code matters”—changes everything.

🛠️ Building a Culture of Curiosity

Here’s what I’ve learned about fostering this mindset in teams: curiosity isn’t an individual trait you hire for. It’s a team behavior you cultivate.

Make it safe to question things

In toxic environments, “why do we do it this way?” sounds like criticism. In healthy teams, it’s an invitation to improve.

I remember asking “why” in a meeting once and being told “that’s above your level.” That shuts down curiosity instantly.

Now when someone on my team asks “why,” my response is: “Great question. Let’s figure it out together.”

Reward investigation, not just solutions

We celebrate the person who fixes the bug. We should also celebrate the person who digs into why it happened and documents the pattern so it doesn’t happen again.

Create space for exploration

“Just ship it” culture kills curiosity. If everything is urgent, nobody has time to ask why.

Document the “why,” not just the “what”

Our best pull request descriptions don’t just say what changed. They explain why it was necessary, what we learned, and what alternatives we considered.

That context helps future developers (including future you) understand the decisions—and question them if circumstances change.

Ask “why does this matter to users?”

In refinement, before we dive into technical details, someone should ask: “What user problem does this solve?”

If nobody can answer clearly, we dig deeper. Sometimes we discover the feature request was based on an assumption, not an actual user need.

Curiosity about the problem is as important as curiosity about the solution.

🔄 The Curiosity Checklist

Here’s what we ask now when something feels off:

Before accepting “that’s just how it is”:

• Have we actually investigated why this happens?
• What assumptions are we making?
• What would it take to change this?
• Who benefits from things staying this way?
• What would a new teammate think if they saw this?

Before starting work:

• Why are we building this?
• What user problem does it solve?
• How will we know it worked?

After shipping:

• What surprised us?
• What would we do differently?
• What patterns are emerging?

These questions sound simple. But asking them consistently changes how teams work.

⚡ What Changes

Teams that cultivate curiosity don’t just ship faster—they ship better.

They catch issues early because someone asked “why is this structured this way?”

They prevent tech debt because someone questioned “do we really need this complexity?”

They solve real problems because someone pushed back on assumptions about what users need.

And they attract great people—because curious engineers want to work with other curious engineers.

✨ Your Turn

Look around your codebase, your processes, your team rituals. What have you accepted as “just how it is”?

Pick one thing this week. Ask why. Dig one layer deeper than you normally would.

You might find nothing. Or you might find the thing that unlocks the next six months of progress.

What’s one thing your team has accepted as “just how it is”—that maybe shouldn’t be?

I write about building better development teams at Beyond Commit. Free 15-minute coaching calls available for developers and leads working through team challenges. 10% of everything supports tech education nonprofits.

webdev #teamculture #leadership #engineering

Want to dive deeper into building these skills?

I wrote From Hello World to Team Lead for developers navigating the messy reality between junior and leadership—the parts bootcamps don’t teach you. It covers the frameworks, templates, and mindset shifts I wish I’d had earlier: how to give feedback that doesn’t crush people, build systems that support growth, handle burnout, and lead without a title.

Right now it’s 40% off, and 10% of every purchase goes to tech education charities (TechMeUp, SheSharp, GirlCode, HackYourFuture).
Grab your copy here and start applying these ideas tomorrow!