The Most Powerful Question: 4 Rules to Help Developers Ask "Why?"

There's a new guy on my team, a guy we just recently hired straight out of college. He's pretty smart, quick on the uptake, and generally been a valuable addition to our team. Best of all, because of him I suddenly find myself on the defensive.

He's peppering me with questions like "why did we do this thing this way" and "what purpose does this serve" and making me defend my decisions. And I consider it a high honor that he does so.

Sponsored by #native_company#
#native_desc# #native_cta#

To be fair, a small part of me is rather annoyed at him. Part of me, that worst part of me, wants to tell him: "Dude, stop with all the questions, you'll learn them eventually; you just got here, sit down, shut up and code."

But the rest of me, most of me, is grateful. The rest of me knows that I need this, that I need the new ideas and new philosophies and new questions. I need people to ask me "why?"

A road sign labeled "Question"

That's the most powerful question in the world: "why?". Why does this behave that way? Why do languages choose to be strongly-typed or not? Why do frameworks include this feature and not that one? Why do babies come from mommies's tummies and not daddies's? (That was a real question from my five-year-old). Why does anything ever work?

That question, "why?" has untold powers. It explains progress, propels science, causes depression, starts arguments, stirs debate, kindles passion, forces negotiation, brings out the best ideas and the worst. It powers all facets of the human experience. You could even argue that the ability to ask "why?" is what makes us human.

It's a small wonder then why some people want to shut it down.

The question "why?" is an unspoken threat, unintentional but a threat nonetheless, to people who already have power, to people who are in charge. It forces them to examine their behavior, their decisions, their actions, to think about the reason they are doing something and reckon with the idea that maybe, just maybe, it wasn't the best idea in the first place. Being asked "why?" forces people to inspect their own faults and insecurities, and they don't always like what they find.

But, if you are in a leadership position, you need people to ask you why. Unless you are infallible (and if you are WTF are you doing here?) you will not always have the perfect idea, the right direction, the appropriate response. There will be times when you are wrong, when you have incomplete information. It is in those times when you have to ask "why?"

A neon sign displaying a question mark
Photo by Emily Morter / Unsplash

The tricky part is ensuring that others feel comfortable enough to ask "why?" when they need to. As a leader, it is our job to ensure that junior-level developers in particular feel comfortable enough to ask "why?" This is not an easy thing to do.

So, let me try to make it simpler. Here's are four rules I've been quietly implementing at my workplace for my team. Even by just applying these rules to myself I can already tell that my team feels more empowered to ask "Why?" than they have before. I'll bet they'll help your team as well.

  1. Don't disparage the asker. Ever. There is no faster way to create a toxic environment than to tell people they're stupid (or lazy or any other form of "not good enough") for merely asking questions. Unless you want to a) have your teammates secretly resent you and plot your eventual downfall and b) miss out on all their potentially-brilliant ideas.
  2. Don't disparage the question. This is totally separate from not disparaging the speaker; I've seen a lot of people in power take great pains to not put-down a person (often in the name of an "inclusive environment") but instead mercilessly mock the question itself for being too dumb, too simple, too easily Googled for. If the speaker feels a need to ask, assume until proven otherwise that they have tried to find the answer already, but don't have the information or experience necessary to do so effectively. You can infer or suggest that they Google a bit before asking next time, but there's no need to be harsh about it.
  3. Always assume best intentions. It is entirely possible, even probable, that the asker simply has no idea how to even begin finding the answer they are searching for. Keep in mind one of my favorite adages, Hanlon's Razor: "Never assume malice for what is adequately explained by ignorance."
  4. Ask them questions. Model what you want them to do. Have them defend their decisions (gently). Point out areas of concern, corner cases, situations they may not have accounted for. By proposing these sorts of questions to them, you force them to either explain the plan they've already got to handle them or learn a bit about what to plan for.

Programming is a team sport. Individuals succeed when the team succeeds, and a team succeeds in a welcoming, inclusive environment. Creating that environment is the job of the leaders, the managers and leads, the people who set the tone. My job.

If you're in a leadership position, it's on you to create that welcoming environment, one where juniors and seniors alike are free to ask questions without worrying about being made out to be stupid, or lazy, or not good enough. A good environment is worth far more than a high salary, and you can create that environment.

Just watch out for inquisitive five-year-olds with questions about babies. Or don't. After all, sometimes being on the defensive is when we learn, and teach, the most.

Happy Coding!

Matthew Jones

Matthew Jones

I'm a parent, a husband, a geek, a web developer, and a speaker, in roughly that order.

Read More
The Most Powerful Question: 4 Rules to Help Developers Ask "Why?"
Share this