Asking 'Why?' without coming across as smug or unprofessional

Question

I am the most junior software developer on a small team. Having less than a year of experience myself, I naturally spend much of my time trying to learn as much as I can from my mentors.

However, I'm having some trouble determining proper etiquette in asking "why?" without appearing unprofessional. To clarify, this isn't my first office job, so it's not a problem of how to hold a conversation or email correspondence in a professional setting. Instead, it's more of the technical aspects of software development.

I assume most SO readers know that there is rarely only one implementation of code. Sometimes there isn't even a "best" way. But someone has to make the call. Whether it's a dev meeting, a code review, or even just me asking, one of the more senior developers will decide "let's do it this way." It's part of my nature to want to know the reasoning behind the decision, especially given the necessity of that knowledge for my own career development. But I find it difficult to asking for more information without sounding like I'm second-guessing, arrogant, or condescending. In most cases, I have no clue of the benefits one way or the other, but occasionally, they'll settle on a way which I'm under the impression is less optimal.

Stupid example:

Other Dev: "Okay, for this, we'll do if (string a == string b)."

Me:

• Why that instead of...?
• What about...?
• I once read a SO post from 7 years ago that recommended if (string a.Equals ...

I'm not about to suggest that I know better than any of them, but I fear I'm coming off that way. I should add that no one has made any comment suggesting this; on the contrary, I've received positive feedback praising me for voicing my opinions. But the manner in which I've done so sometimes sounds pompous TO ME. So are there any suggestions for diplomatically asking for rationale behind a decision without appearing to question someone's competence?

Answer 1

So are there any suggestions for diplomatically asking for rationale behind a decision without appearing to question someone's competence?

When you encounter this sort of situation, make it clear that you accept their suggestion, then also ask for the reasoning behind the suggestion.

They: Do it this way.

You: Okay, I will. Thanks. I'd like to ask a few questions about this so that I can better learn how to make the right decisions on my own. Is now a good time to talk about it?

Listen. Seek understanding, not necessarily agreement. Don't be argumentative. And sometimes accept that it's not always important to reach an optimal solution for everything. Many times it's more important to get to "good enough" quickly.

Answer 2

Just be honest. Your colleagues probably understand.

One of the most effective and admirable qualities of a critical thinker is the willingness to Ask Why. This is one of the most effective ways to learn, as well as the main way of leveraging the advantage of having a variety of different people with different ideas. It is useful both when you know better than others and when they know better than you, as well as when you're not sure of which is the case.

At the very least, you can present your questions as the type in which you do not know and wish to learn. However, you can probably feel more comfortable asking questions the other way than you might think. Your co-workers are likely not as judgemental as you might be thinking - they don't know everything, and they probably acknowledge this fact and value your opinion. Don't be afraid to put in your two cents; most people will not bite your head off for it.

Answer 3

Often phrasing can make it clear that you're trying to fill in gaps instead of challenging someone else's approach. It can help to start by declaring your confusion.

A PM I worked with early in my career would often phrase questions as, "Can you help me understand why we need to use ASCII mode for that transfer?". It made it clear that he wasn't thinking of himself as the expert and that he was trying to understand a topic or line of thinking. I loved this phrasing and still return to it from time to time.

Sometimes a simple declaration, like "I'm confused" or "I'm surprised", can give enough context. This is useful if you think the person made a deliberate choice. "I'm confused. I've always just used quicksort but we're using insertion sort here. Can you explain the reasoning?"

If you already have a theory then a binary question can minimize the interruption. "Did you use insertion sort because most of the input data is already presorted?" Optionally lead with, "Just to check my understanding" if you think the interjection is still too abrupt. This lets your colleague decide whether to give a terse answer or take time for a discussion.

It can be hard to ask about things that could have been arbitrary, but you can ask that too. "I've seen dot-equals a lot and I'm not sure if it's the same as double-equals. Is that a stylistic choice or am I missing something?" Again it lets others decide how lengthy of a response to give and doesn't force them to defend arbitrary decisions.

I'd avoid citing other training or workplaces unless it's needed to clarify your question. That's pretty rare so when it doubt just don't mention it.

Also give chances for others to bring the meeting back on track. "I'd like to know more about different approaches to sorting on embedded devices. Do we have time now or should we hold off until we've reviewed more of the code?" A good meeting coordinator will conclude the main topic, invite attendees to leave if they aren't interested in the sidebar, and then reopen the floor for your topic.

Answer 4

There are a few ways to deal with this, but for me I've found the best to be:

• Can you explain that to me?

• Can you quickly clarify what this part is for?

• Is the purpose of this line here to do XYZ? Or something else?

By framing questions like this, you're automatically putting your senior in a position of authority: you're not questioning why they're doing something, you're questioning how they're doing it. Asking why can (even if not intentionally) put them on the back foot, make them feel defensive. By posing the question like this, you're not challenging them. You will also appear eager to understand rather than arrogant, which is what you mentioned as your major concern.

Always put the stress on yourself learning rather than trying to analyse the code. If the developer can give a sensible justification for why they've done what they've done, thank them and move on. If you still feel that your idea is better, you can present it as follows:

• I see, thanks for explaining. Might it be better to do this instead?

• Okay, thanks for clearing that up. I've seen a different method used before, would that be a better choice, do you think?

Make sure you've got evidence, research and a very clear understanding of your question to back up any suggestions you may have. If the two justifications are clearly laid out, one should be able to make an objective decision about them.

But as Lilienthal says, it's very important to "read the room" in a sense. If you can see people getting frustrated or annoyed at your suggestions, speak to someone who you report to about how best to ask these questions, if at all. Even if you know a better solution, if you feel like it's going to put you in someone's bad books then in some cases it may be better to let it slide.

Final note: I am an intern with little experience, but I feel that by adopting these practices I've been able to make suggestions for changes to a system without appearing arrogant or condescending. It's important to recognise that your opinions are valid and can be used, but you are also still learning. By striking a balance between these two attitudes, you should not encounter any problems with a reasonable team of developers.

Answer 5

Firstly, accept positive feedback. If you're praised for something, with no caveats whatever, then keep doing it!

That said, the main thing you can do here to avoid causing offence or discomfort, is to be prepared for the possibility that the person making the decision doesn't really know why they prefer A to B, and might not care to be rigorously challenged on it. This comes up especially in cases where:

• A or B will both work, so neither can be immediately ruled out, and
• The difference between A and B is not so great that a detailed extended analysis of A against B is really justified, and
• The experienced developer has an instinct in favour of A, or is most familiar with A, or feels that A is most in line with current practice in the existing code, or that A follows some rule of thumb which is good in general but not relevant to this particular case, and
• The experienced developer is not easily able to precisely quantify this.

Sometimes it's good, as an experienced developer, to really break down these hunches and analyse what's behind the decision. Sometimes it's good, as a junior developer, to have it all laid out in front of you. Sometimes the junior developer's snippet of knowledge is more accurate and relevant than the experienced developers body of knowledge, and the decision ideally should be reversed. Sometimes the experienced developer has made a mistake of reasoning that the junior developer can correct. But it's still a waste of time to second-guess too many minor decisions. A good proportion of the "experience" that the experienced developer has, is making a confident call on a "good-enough" solution in order to avoid bogging down in bike-shedding and Burridan's ass-style situations.

So in cases where you're concerned you might come across as challenging the decision, and you don't want to come across that way, I suggest:

• Agree with A. Even if the discussion ends up choosing B after all, there's no need to reach that decision by adversarial debate.
• Present the alternative as "I've seen that sometimes people do B instead of A". Avoid "my opinion is that B would be better".
• Ask, "is there something that would mean B doesn't work here or is worse than A?" or "what are the conditions where B would be the best solution?". Avoid "what is your reason for choosing A?"
• If no satisfactory explanation comes forward but there's basically nothing wrong with A then end things on, "OK, so we're doing A because it's a solution we know will work". Avoid, "So B might be better than A, but we're doing A anyway because we can't be bothered to assess B properly?"
• Ask, "how in general do we decide beween A and B?". Avoid "How can you be so sure B isn't better here?"
• (Advanced use): ask what test case would be relevant to this situation, and should be added to the suite in order to chase out the practical difference between A and B. Beware this coming across as sarcasm, but sometimes the question "what's the test case" is precisely what's needed to formalise the difference, and it is at least a practical concern: what tests do we need?

In addition, you should be interested (and show interest) in the reasoning even when you agree with the decision. Sometimes the reason will be different from what you expected, or from your own reasoning, and you learn from this just as much when you reached the same conclusion as when you reached a different conclusion. If you also somtimes ask for the reasoning when you agree, then you demonstrate that what you most care about is improving your reasoning, not advancing your conclusions.

Of course, when you actually believe that the senior dev is seriously wrong and their decision needs to change, then you can be more challenging. This is for cases where that doesn't apply.

Finally, bear in mind that there are plenty of developers who in fact are happy with robust discussion from their subordinates. Especially if you're willing to accept "because someone has to make a call and that someone is me" as an answer, when that's all there is to it. If the person you're talking to gives every impression of enjoying the debate, you don't have to worry about it. If they look like they have a meeting in 5 minutes and need to get the heck out of the room, maybe that's not the best occasion to ask for a full justification of the difference between a == b, a.equals(b) and a === b.

Answer 6

People understand learning curve, they all went through it too. Some are grumps, secretive, or too impatient, but most will tend to understand and know that if they explain reasoning once, and you listen, they most things they will not need to explain multiple times. Most experienced people in fact want you to ask questions. They do not actually want you to just take their word for the way to do things, they want you to think about it.

Now, how and who to ask are real concerns. Who in the sense that you will learn that some people are less willing to spend time and others simply are too busy. The less willing, you just have to learn personalities on the fly. With the busy schedules, I have always found that a polite, "when you have time can we spend a few minutes and talk..." tends to work well.

Tactful wording, well, that has always been hard for me, I actually tended to learn that better being the mentor that when asking questions. When you are the one helping someone else, they you can hear how confrontational some people are. An experienced person usually will be open for ideas. We all still want to learn and frankly, when you reach the point that you no longer are learning it is a real boring job. But, a person does not want everything they say to be challenged either. An experience programmer has learned a lot of right and wrong approaches, and though they like new ideas, they do not want an entry level person telling them everything they do is wrong. For me, both asking and being asked, I found that something along the lines of "why do you find A a better way than B..." to be a good approach. The person may have a legitimate reason, and one very different in real life than what the textbooks say, of they may have never tried B.

One of the best mentors I ever had though would almost always answer that with "what do you think?" He would make me answer first because obviously I thought B was the better approach, and he wanted me to work why I thought that. Once I finished, he would often say something like, nice textbook answer, but in reality, this is why we do A. Other times, it was, meh, never tried that, let's try. He not only wanted my opinion though, he demanded it before he would answer because he wanted me to think about the options first, not just accept his answer.

Answer 7

If you're afraid of sounding too pompous, a simple solution is to "lower yourself" before hand.

My go to opening in such cases is something along the lines of :

"I don't quite understand - I've heard that x is also a good method, why is this one better?"

"I'm having a bit of trouble with this : could you explain to me how bad of a solution x is compared to this ?"

Answer 8

Maybe to soften it a bit "Why do you do it that way?" or "Why that way?" In 25+ years, I haven't met many devs who take offense to "Why?" no matter how it is asked.

You run into problem is when you aren't asking "Why?" so much as implying "You are doing it wrong." This is the difference between "Why do you do it that way?" and "Why don't you do it this way?"

Answer 9

I don't there's any harm in questioning why, i do think you need to think in if it's the right time to make the question.

State of mind / Crunch time / Stressfull sprint

If people are stressed out with work or very busy, unless is crucial to understand why, i would take a note and ask the question on a more appropriate time.

Relevance

Is it relevant to understand why ?

For instance, does it really important to understand why people use if(a==b) or if(a.equals(b)) ?

Can i dig though this later by myself ? Maybe you can look it up on your own time ?

In my opinion this is the key timing where people will look at you as unprofessional or smug because you might waste other people time with trivial things that could be locked by yourself.

Sometimes people do stuff because they have a particular reason, be it technical, a strong belief or just force of habit. Sometimes people won't give you a reson for a particular decision. It's just how it works.