The Ruthless Pursuit of Why 💥

A framework for building software that actually solves the problem

In our field, asking “why” should be second nature. But when you're the one constantly asking it—especially in rooms that value velocity over direction—you can start to feel like a problem.

I’ve been called contentious, adversarial, even combative, simply for pushing back until we have a shared understanding of the problem we’re solving. And honestly? I'm okay with that. Because the alternative is building the wrong thing beautifully.

While I focus here on developer tools—because that’s what I build—the same mindset applies to any software built for humans. Internal or external. Technical or non-technical. Solving real problems means first understanding what those problems are.

Good Idea. Wrong Context. 💧

Let’s say someone comes to you with an idea:

“We should give developers water.”

You ask why.

They respond with,

“Because it’s good for you. Keeps you hydrated. Promotes a healthy lifestyle.”

And while all of that may be true, it still doesn’t answer the real question:
What problem are we solving?

Because without knowing the problem, we can’t weigh alternatives, identify flaws, or evaluate the solution at all. We’re just reacting to the idea, not the need behind it.

Here’s why that matters. Let’s say the real problem is:

• They’re thirsty
• They ate a really spicy pepper
• They feel nauseous
• They need something to swallow a pill
• They’re choking

“Give them water” might help with the first. It might make the second worse. It might do nothing for the third. It might help with the fourth—but only if it's not carbonated. And in the last case? Giving them water could literally be dangerous.

So even if water seems like a great idea, it’s not a good solution without context. “Water” isn’t the problem. It’s someone’s proposed answer. And until we know what they’re trying to solve, we’re just guessing—and possibly making things worse.

Tasks Don’t Deliver Value. Solving Problems Does. ✅

This happens all the time in software. A user says they want X. We implement X. We ship X. Everyone checks the box.

But value isn’t in the shipping. It’s in the solving.

We forget: effort doesn’t equal impact. Work isn’t valuable just because we did it. It’s valuable when it changes something. When it makes someone’s work better. When it removes pain, adds clarity, unlocks speed, or avoids error.

So the job isn’t just to build fast. It’s to build the right thing—and be willing to rewrite or throw it out if it’s not landing.

Stop Making Sandwiches for Yourself 🥪

When someone makes you a sandwich, they’re not making it for themselves. At least—they shouldn’t be.

A good sandwich maker asks questions. Toasted or not? Mayo or mustard? Any allergies? What do you like? If they skip all that and just make what they’d want—a spicy triple-decker Reuben with pickles and jalapeños—you might be impressed… until you realize you hate rye bread and can’t eat dairy.

That’s what happens when we design solutions around our own preferences instead of the needs of the people we're building for.

Developer tools are no different. As engineers, we bring a lot to the table—experience, opinions, patterns that worked before. But our users live in a different context. They have different habits, workflows, and constraints. If we build something based on what we think is best without understanding their reality, it might look great to us—and be completely useless to them.

If we want our work to matter, we have to stop making sandwiches for ourselves.

My Kids Helped Me Learn This the Hard Way 🎮

I think about the time I built a sky base in Minecraft for my kids. I knew them well—or so I thought—so I designed what I assumed they'd love: clean layouts, matching blocks, perfect symmetry.

My daughter immediately started adding random colors. At first, it drove me nuts. But then I realized: she was showing me what she liked—color-coded zones, playful mismatches, visual storytelling. So I adapted.

My son? Total chaos. Carefully designed rooms meant nothing to him. He preferred open spaces where he could experiment, knock things over, and rebuild. So I made space for that, too.

What I thought was “perfect” didn’t matter. What mattered was how they wanted to play. The only way to build something meaningful for them was to stop assuming and start observing.

As engineers, we need to approach building developer tools the same way. Don’t guess. Watch. Ask. Adapt.

Stories Should Have Happy Endings 📖

User stories aren’t requirements. They’re invitations. They’re moments to ask what success really means—and how we’ll know if we’ve delivered it.

Too often, we validate a feature by pointing to its inherent value: “Well, it’s a dashboard,” or “It supports filters now.” But that only matters if those things help the user do something better. If not, they’re just features in a vacuum.

It’s easy to say, “Well, we built the water. It’s cold. It’s fast. We’re done.” But maybe what they really needed was Gatorade. Or a milkshake. Or just someone to ask if they’re okay.

One of the most common pitfalls teams face is validating a feature by the feature itself, rather than by whether it effectively solves the user’s actual problem. A feature can be polished and clever and still be pointless.

Don’t just write stories. Write stories with happy endings. Solve the problem. Deliver the outcome.

Be Contentious. Be Curious. Be Kind. 🧠

When you question assumptions, push for clarity, and challenge the default, you might get labeled as difficult. But asking “why” isn’t about being right—it’s about getting it right.

This is how we get better. This is how we deliver real value. This is how we build tools developers actually want to use.

So yeah—be contentious. Be adversarial. Be combative in your pursuit of why.

But do it with purpose. Do it with humility. Do it in service of the people you’re building for.