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 === b.