Help me ask why you didn't just - <AUTHOR> https://blog.plover.com/tech/why-dont-you.html <comment><USER4> My take from personal experience:

Removing the "just" obviously makes it less condescending:

=> Why didn't you use sshd?

Removing the "you" could make it less personal:

=> Why was sshd not used here?

Removing the past-tense makes it more forward looking (the past can't be changed, but people often defend their past decisions especially because they are unchangeable, the future however is less threatening):

=> Could sshd be used here?

And to further open it up to criticism and add humility (which is important, since sometimes the obvious standard solution doesn't scale/work/apply to the use case):

=> Would there be any tradeoffs using sshd here?

This IMHO is the least-threatening and not too elaborate way to formulate this sentence.

But one thing can make this even less threatening. Don't write in on the code review for everybody to see, tell it to the person 1:1 in private and give them a chance to look good to their peers. The old adage "Praise in public, criticize in private" is still one of the most important things IMHO when relaying criticism.

<comment><USER5> Personally I hate it when my PRs come back like this. I made a PR so my code and my decisions could be reviewed and critiqued. If you have some criticism, just tell me what it is and why you think that. I have learnt so much from highly critical PRs, I hate to think where I'd be without them. Personally I think it's much more productive to create a culture where criticism is made openly and without being taken as a personal offence. Rather than dressing it up in a way that can often just come across as condescending, and without always even providing the benefit that critical feedback would have to begin with.

<comment><USER6> I'm aware of an unofficial convention in some US government departments - <USER2> you have a small round green sticker on your pass, then you are opting in as someone who can handle un-sugar coated discussion.

It's a great system - you occasionally see someone pause momentarily to check that everyone in the group has a sticker before saying "well, that was a clusterfuck wasn't it".

<comment><USER7> I think on my sub, it was just assumed that everyone had a green sticker :)

</comment></comment></comment></comment><comment><USER8> My go-to would be "Do you know if sshd would work?" To me, framing it directly as a knowledge question, and to not appear as if you're coming from a place of authority (unless you know both their problem and your solution both well enough to solve it without running into edge cases, and how often does that happen?). They either know or they don't, or potentially have a reason for not trying in the first place. If they don't know and don't have a reason, it's a simple "well, that's what I'd try next, it could make things easy if it works" to get your suggestion out there, but you let them solve their problem ( _if_ it works...)

<comment><USER9> Why not also explain why you think sshd could work, though? The recipient might not understand the connection you're trying to make between the proposed solution and their problem.

<comment><USER10> Sometimes it's just a hunch, a feeling that maybe sshd or whatever would work - the hope is they've already figured out that hunch and will be able to clarify your thoughts before you have to.

I'd probably phrase it 'did you consider using X here?' sometimes prefaced with 'maybe I'm missing something...'

</comment></comment></comment><comment><USER11> The last two proposed options — "Naïvely, I would think that sshd would work for that" or "So, I probably would've tried using sshd here. Would that not work out?" — sound pretty reasonable to me. It makes it clear the implication is that the questioner assumes that the problem is likely more complex than is obvious on the surface and is curious, as opposed to passive-aggressively implying the author is an idiot.

I used to work in infra at $LARGE_TECH_COMPANY, and while it's true that _sometimes_ people meant the type 2 "I genuinely am curious" question, there was often a deluge of type 1 "you're an idiot why didn't you do X" for specific decisions that we'd made that made sense at the scale we operated at, but where the problems we encountered with the "simple" approach wouldn't show themselves at small scale (and thus most engineers wouldn't encounter e.g. in side projects or if they'd worked at smaller companies) — especially because these kinds of questions often arose when someone was frustrated and having issues with something we built or maintained. It's not so much that maintainers are overly sensitive with the "just do X" type questions; it's that maintainers pattern-match against the large number of "you're doing it wrong" versions of the question and the few genuine ones have a hard time differentiating themselves. Either of the last two do a good job differentiating themselves from the noise, I think.

</comment><comment><USER12> I would feel offended if anyone would feel the need to go easy on me, just say what you think. And if you are right I will be eternally grateful for being taught a new efficient trick. Do I look like such a weak person to you that you feel like you have to handle my self esteem with silk gloves? Thanks for the insult.

And what is it with this 2 intentions? The third is the obvious correct one where I'm not familiar with sshd or I just didn't think about it. Please educate me. What kind of toxic culture propagates pieces like this text as something of value?? Just say "Why didn't you use sshd?" Anyone mentally pasting some kind of assumption behind that small sentence to bash themselves was just raised wrong. I'm sorry this whole thing just annoys me. Making things up in your head and getting offended by them. argh..

<comment><USER13> > I would feel offended if anyone would feel the need to go easy on me

"go easy on me" means "condescend", so you're essentially doing the same as the people mentioned: feeling offended because they perceive condescension from the speaker.

> Do I look like such a weak person to you that you feel like you have to > handle my self esteem with silk gloves?

> Making things up in your head

The phrase he came up with doesn't actually state that he is treating you with silk gloves; that's an implication you're deriving (in your head), just like those people are deriving another implication from the original phrase.

<comment><USER14> I thought his first paragraph was just being illustrative. Like look how crazy this gets.

I suppose now I'm deriving meaning in my head.

<comment><USER12> It's not illustrative, it's how I would feel. Maybe it's a cultural thing. Something to take into account if I would ever work in the US. It would be nice to have some kind of rule book then, I mean if people don't just assume I mean well but get mad when I use the wrong wording means I would have to be educated very well to function in such a group. I imagine such a culture is pretty unwelcoming to other cultures.

</comment></comment></comment></comment><comment><USER15> It's not only a phrasing thing.

The revised phrasings are better, but if someone's spent "a week or a month or maybe years" on a problem, consider asking what _they_ think are the tricky tradeoffs and so on and give them a minute or a few sentences or an email or whatever to tell you before you launch into anything about your idea.

Not for politeness, but because if they're knee-deep in the problem they probably learned something you don't already know about it. It may illuminate why your idea wouldn't've made sense before you ask. You may get another, better informed idea. You may still have the same idea but learn something on the way there. It's a gamble worth taking if possible.

And, sure, if there's no time for that kind of convo, there are ways to politely offer your intuition that X might have worked, and that can be a shortcut to finding at least one thing that wasn't in your mental model of the problem. But, if you think they understand the problem much more deeply than you do, offering them a more-or-less open-ended chance to give you a download of what they've learned is a smart move.

<comment><USER16> Completely agree. All of the phrasings he proposes presuppose that the thing he's suggesting makes any sense at all. Why not let the person take you through the design/thought process and then, and only then, if you're still left wondering why they didn't do X, ask. I guess in many cases you'll hear the reason why they didn't pick it while they're taking you through their thought process.

</comment></comment><comment><USER17> "I'm probably missing something - why didn't you just do X?"

And honestly I think phrasing isn't that important - if you know someone for months or years and aren't usually a dick - people won't automatically assume the worst.

Also this may be cultural. I've worked with English people and with Germans and the level of acceptable criticism and required disclaimers was very different. My own nation (Polish) seems to be somewhere in the middle but closer to Germans.

<comment><USER18> > "I'm probably missing something - why didn't you just do X?"

I like to use basically this, combined with brlewis's suggestion to take _them_ out of the phrasing, when I'm erring on the side of being approachable. So maybe "I think I'm missing something here - why not use sshd?". If it's awkward to take them entirely out of the equation, there's the royal company "we" \- e.g. "why don't we use sshd?"

Some of Mark's rephrasings are rather over the top. "I'm not clever enough [...]" whoa there, that's a bit much. You're either being sarcastic, or beating yourself up way too much. "There must be a good reason why you [...]" whoa whoa, they might not, and that's fine! There might be a good reason... there might be a bad reason... there might be no reason... and all of those are fine! I ain't judging! I've probably had worse reasons! I just want to understand the problem space.

"I think I'm missing something here" admits to an extremely minor, low stakes, inconsequential "mistake" on my part - the kind that we all make frequently enough in passing as to not even really think of them as mistakes per se. I'm not admitting to some moral failure, just implicitly asking for a minor bit of assistance from my conversational partner to get over a momentary blind spot. It's not judging either of us, the problem, or the solution.

Which all hopefully helps set the tone - for if they feel like _they 've_ made a mistake because they didn't think of sshd and realize in retrospect that "they probably should've". Because, like all of us, sometimes they _have_ overlooked the obvious... but that's perfectly OK - because, like I said, it happens to all of us.

> And honestly I think phrasing isn't that important - if you know someone for > months or years and aren't usually a dick - people won't automatically > assume the worst.

Also agreed.

</comment></comment><comment><USER19> A good way to get out ahead of this I didn't see mentioned is to just assume the person actually chased down the path you're proposing, and ask them about what happened when they did so. So for the example, "what happened with sshd?"

If the person considered sshd, this question will connect because it shows that you grok their problem solving process, assume they are at least as competent as you are, and you want to learn what surprises they encountered that neither of you would have realized beforehand. If they didn't consider sshd, this question doesn't seem to be likely to offend them since they will respond by inquiring why you think that was a potential solution and hopefully be prepared to learn.

</comment><comment><USER20> > What's the advantage of "this" over something like "sshd"?

I would typically phrase it this way, especially if "this" is something which sounds like it'll be a lot more work than "sshd".

This is probably going to get you an answer closer to what you wanted to know anyway. ie. you have already ceded that it's likely that "sshd" is too simple of a solution, and now you want to know how this new solution (which you don't know much about) is going to be better.

</comment><comment><USER21> The final suggestions are good, much better than "why didn't you just". The problem comes when your initial thought is actually a good idea, and your colleague could actually have saved some time. This happens a lot in the interaction between senior and junior engineers. For those situations, it's not great to be asking for an explanation on the spot, because then the explanation is just "I'm an idiot/ignorant of that tool".

What's missing, I think, is a question that is not seeking explanation, but improvement. You are not seeking justification of actions, you are identifying an opportunity. This opens up for both an answer starting with "Aha, you might think that, but actually..." and the question "Huh? What is X? How could it be used here?"

Hence, I like

> Could it be made simpler by using `sshd`?

and

> Did you try `sshd`? This seems like it might be a good fit.

<comment><USER22> In interaction between senior and junior engineers those type of question are made often and juniors should take it as how to grow themselves, but I agree with you that asking about their decision first would make the discussion better.

</comment></comment><comment><USER23> Here's the suggestion: don't ask! What are you going to do with the information? If you ask and the answers are _reasonable_ , then ... so what? What have you meaningfully learned? You've learned that an existing solution does not completely solve a problem.

Now you understand the problem a little better, and you understand the shortcomings or deficiencies of a pre-existing solution a little better, but you're signalling to the person you're asking that you're looking to second- guess their judgment or wisdom before you even understand the problem that was trying to be solved. Why didn't you wait until you understand the problem well enough such that you'd be able to see (along with them) why an off-the-shelf solution wouldn't work? Asking why a specific off-the-shelf solution wasn't chosen is a way of signalling to someone else "hey, I don't understand the problem very well but I'm sure that I have a better solution". So don't ask why a technology wasn't chosen; ask questions about the problem domain until you understand why - WITHOUT asking.

Here's the other scenario: you know for a _fact_ that an off-the-shelf solution would've been a better choice than what someone else did. In that case - guess what? Don't ask: tell. Don't patronize someone by saying "why didn't <software> work here in a case where it obviously was a smarter choice"; instead, have the courage to say "I think that a better use of time would've been doing research and seeing if <software> was usable." Because if you're trying to tell someone that they made a mistake by reinventing the wheel, asking them why they reinvented the wheel rather than telling them they did so will probably be seen as patronizing or dishonest.

Either understand why the first thing that popped into your head doesn't work without having them tell you why that's the case, OR be so certain that the first thing that popped in your head does work that you're willing to declare that. Anything else is inviting people to believe that you're trying to "stump-the-chump", so to speak.

<comment><USER24> On large projects, it becomes impossible for anyone to understand how each line of code works and what the best solution should look like. In such a complex area, assertive code review comments could be counter-productive.

In most cases, showing curiosity and asking questions in code reviews goes beyond educating yourself: it's also about providing "self serve" context for future developers who need to understand why a specific decision was made.

This context can also, for example, prevent future developers from trying to refactor or rewrite entire pieces of a program to follow "what first comes to mind".

I'm curious to know about the kind of projects you work on and how you've seen the approach of asking fail there.

<comment><USER23> In the linked article, the quote that starts it is the following:

"Whenever you look at a problem somebody's been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you're also making it crystal clear to people what you think of them and their work."

So let me ask _this_ \- do you believe I'm responding to the case of tiny code reviews that happen daily with pull-requests, or do you think I'm responding to the scenario the article proposes - which is when someone asks why an off- the-shelf solution wasn't used after the implementors worked on their new solution for "weeks or months or years"?

I am responding to the question in the article (or at least what I understood it to be) and not to the more-common instance where this probably comes up which is in daily code reviews. There is a difference in asking why someone didn't choose X option when the amount of time they spent on a problem is one day versus one month. I am responding to the one month scenario. I believe code reviews happen more than once a month.

Is my response an understandable one?

<comment><USER24> Thanks for answering, I see other folks had concerns similar to mine regarding your comment.

I understand better where you're coming from.

(Where I work) I find there is something to be gained by showing interest and asking about the parts of the code I don't understand or would have approached differently.

(my favorite thing is when folks preemptively comment in their own pull requests to explain tradeoffs and design decisions before being asked about them, or write comment blocks in the code to add useful context)

</comment></comment></comment></comment><comment><USER25> I don't know about you, but if I talk to someone about a problem, the "why didn't you just $FOO" suggestions are exactly the ones I'm looking for.

Because the tech environment has become so complex that there is probably a simple API I could have used but I wasn't aware of it.

How about we stop assuming people are out to hurt us, and start assuming everybody is well-meaning but they have social issues just like me? Just like every other nerd in tech!

<comment><USER26> There's a simple but subtle difference in "why didn't you just x" and "did you try x".

The first one has negativity associated with YOU in it and feels like it focuses on your past. The latter is neutral and it feels like it does not care about the past, more like a suggestion for the future.

</comment></comment><comment><USER27> I don't mind the phrasing "why didn't you just" too much, but the phrase "why don't we just ... X" drives me crazy. The passive assumption that "just X" is obviously better and simpler than the current idea under discussion is insulting. Part of the problem is it lazily puts the onus on everybody else to explain why the proposal is a bad idea at zero intellectual cost to the proposer. eg:

 _Why don 't we just use a jsonb column and put all the attributes in there instead of inventing a complicated table structure?_

My take on this is always: if you so lack understanding of the problem space that you can't understand why everyone is discussing something complicated, stop proposing solutions until you do. When you do understand that, come back with your reasoning:

 _Although a relational structure is a better way to do this in general, I think in this situation it isn 't necessary because the format of the data is intentionally client specific and opaque to our code. We might be able to simplify things a lot by storing it as a jsonb field_

<comment><USER28> > Part of the problem is it lazily puts the onus on everybody else to explain > why the proposal is a bad idea at zero intellectual cost to the proposer.

This sounds like "ask vs guess culture" is at play.

As with the OP, I think context matters a lot. I can imagine environments where it should be okay to ask questions without thought, or environments where some understanding or consideration is expected before asking a question.

What you describe does sound annoying: guessing a simple solution without putting effort into understanding the problem (which everyone else understands). And the opposite extreme would be only 'asking' questions only for confirmation/verification of an answer.

</comment></comment><comment><USER29> My suggestion:

 _" My first thought would be to use X. What do you think of that?"_

It seems, to me, humble and asking for clarification if there are obvious reasons for not using. An invitation to be teached. At the same time, if it is a good idea it would be recognized as so (maybe with some awkwardness)

</comment><comment><USER30> "Why wouldn't sshd do the job here?" Take "you" out of it. The question is about the problem and the solution, not the person.

<comment><USER31> A slight twist to this approach:

"What if _we_ tried using sshd here?"

I think this would make it sound like you are on their side/on the same team, and that you are trying to help, not trying to mock them.

<comment><USER32> There's two parts to the problem. You don't want to sound mocking, but you also don't want to come across as a doofus who thinks their ten seconds of thought is automatically insightful, even as you're the twentieth person to suggest turning if off and on again.

When someone has been working on something for a week or more, a naive "What if we tried using sshd here?" fails that latter test pretty hard.

<comment><USER31> Perhaps.

But if I'm the proverbial twentieth person to ask the same question, it's probably a hint that it should be documented/explained prominently - maybe in a README, maybe as a comment in the source code, maybe some other suitable place.

And maybe it's just me. I'm a team lead and I have constant impostor syndrome. I was airborne into an existing team of junior devs who had no real team lead, but some of the devs know their stuff better than I do. E.g. I don't know modern ES, TypeScript, or React. I can't write CSS for the life of me. I'm mostly a back end Python/Django geek/Linux graybeard. I have since learned to not be afraid to sound like a doofus. I just ask away when I'm reviewing code and I don't understand something in modern ES/TypeScript/JSX/TSX/etc.

Like, if you are generally a nice guy, people you work with will eventually (and rather quickly) figure out that's just how you ask questions and don't mean any mockery.

<comment><USER32> > But if I'm the proverbial twentieth person to ask the same question, it's > probably a hint that it should be documented/explained prominently

If you're joining a project, or it's published, sure.

If you're just having a conversation you don't start off by skimming a dozen pages of documentation. So put in a tiny amount of effort with your wording, to show you realize they might have thought of this already.

</comment></comment></comment></comment></comment><comment><USER33> Either they tried sshd or they didnt. If they did try it, then they have a good response ready to go no matter how you ask. The issue here is if they did not try it. The longer they have worked on it, the more gently I would make the suggestion towards sshd. If they have worked on it for their whole life, I wouldn't provide any help unless asked to and only limited to what they have asked me to do. If they have worked on it for 10 seconds, it would seem to be ok to quickly suggest sshd. For everything in between just be gentle. Maybe consider pondering and prodding as to what they have tried and maybe do not suggest sshd but some sort of encrypted TCP based protocol maybe one that is readily available.... maybe they'll discover it on their own.

<comment><USER34> I've gone to this strategy of just not saying anything to avoid the problem, but I know I have benefitted immensely when others have dropped a pearl of wisdom straight from their fresh perspective so it saddens me.

I think the key thing is to establish a supportive and collaborative environment where people feel safe enough to take a suggestion, knowing that their good faith effort over the last several months is valued as a part of the process that led to the mature and stable strategy of using sshd. If it was worth it to spend 3 months plus 10 seconds across two developers to find the best solution, and the best solution was found, declare victory and celebrate that good outcome. A lot of times, you won't get the good outcome no matter how you try.

If you don't have that, you're going to be spending more and more time creating elaborate ways to suggest things by inception, and that's not good for anyone.

PS like the author, I also use the word just to connote "solely or simply" rather than "merely or trivially". I have learned others feel it has some negative connotations, so I have restrained my usage of it.

<comment><USER35> _> I know I have benefitted immensely when others have dropped a pearl of wisdom straight from their fresh perspective_

Others who had worked with you extensively enough to have useful suggestions? Or random strangers off the street? I'm guessing it's the former, since you say:

 _> I think the key thing is to establish a supportive and collaborative environment where people feel safe enough to take a suggestion_

But if all this is the case, the author of this article agonizing over what to say and how to say it makes no sense. If he has already worked with these people long enough to have established a "supportive and collaborative environment", then he already knows how to make a suggestion to them that (a) might actually be of value, and (b) will be taken in the spirit it's given. But then why is he writing an article asking for suggestions on how to do this?

In other words, while I agree with you that in the specific situation you describe, making suggestions from a fresh perspective can be helpful, the situation you describe can't be the situation the article is describing.

<comment><USER34> The author appears, to me, to be looking for a solution to a symptom of a problem rather than at the problem itself.

The original question posed is basically innocuous, and is only made a problem by the environment.

If one gets to the point of wondering how to offer help without setting off a spiral of despair and insecurity, there are deeper issues that need to be rooted out. I also claim, anecdotally, to have seen this sort of improvement happen and think it is generally a thing that is possible to do, and isn't some core part of the human condition (at least to the degree described in the article).

</comment></comment></comment></comment><comment><USER36> Have you tried "Have you tried x?"?

This follows naturally from "What have you tried?", from the "information to include when asking for help", on which Q&A sites seem to agree.

It's rather innocent at face value and it leaves the door wide open for the person to explain what went wrong when they tried, or why they opted against it without trying, etc., without implying anything negative --except to a really frustrated and/or rough-edged person who is determined to receive everything in a negative way.

Yes there are a dozen mentions already for "did you try/have you tried" so here's my grain of sand on that pile.

</comment><comment><USER37> Last year I was on a project where we couldn't get something to work despite all efforts. Pretty much all managers walked by some weeks in and asked "why don't you just do X?". Whenever I heard the J word I pretty much stopped listening and told them "no problem. here is the code. Here is the server. Just do it.". It's incredibly disrespectful to walk up to people who have worked on something for months and then you use the word "just" in your advise.

<comment><USER12> I think you would be a difficult person to work with if you get offended by that one little word. I understand that it can be annoying to be asked repeatedly but just work on an elevator pitch to explain why you didn't use X. You might even earn some respect in the process. The way you act now will "just" (sorry!) make people feel like that have to walk on eggs around you and handle your brittle mood with silk gloves. Next time they will ask someone else.

<comment><USER37> I am usually pretty patient with people and generally don't get offended. In this particular case we had worked very hard on that problem for a long time. This project was highly visible so everybody knew what's going on.

I think people (I tend to do that too) should think twice before giving unsolicited advice and make sure they have thought about the problem for a while and have something of value to offer. Otherwise it signals a lack of respect.

<comment><USER12> Respect is such a culturally dependent thing though. I think it is more productive and nice to just assume the other person only has good intentions.

</comment></comment></comment></comment><comment><USER38> "What was your reason for not using sshd?"

That's my go-to phrase. It implies that I am looking to be educated, and not that I think they messed up.

<comment><USER32> It also makes them look like a giant idiot if they actually made a mistake by not considering it. Maybe not the best thing to risk.

<comment><USER39> But that is kind of unavoidable. When I do screw up, I rather find out by an honest question, where I can be the one answering, "duh, I should have thought of that!", instead of gradually realising that the only one that doesn't know that I'm wasting my time is I.

<comment><USER32> It's partly unavoidable, but you make the embarrassment far worse if you act like it's so obvious that they clearly must have tried it, you don't even need to ask.

</comment></comment></comment></comment><comment><USER40> I'm just thinking about how in Medicine, lots of people would suffer if the helpers had trouble asking the basic questions.

"Did you submit cultures?"

"Why did you choose to ignore the liver enzymes in this case?"

"Did you ask about a family history of X?"

To a large extent, becoming professional is about becoming less sensitive to being wrong.

<comment><USER41> > To a large extent, becoming professional is about becoming less sensitive to > being wrong.

I agree, but there's nothing to lose in trying to become a better communicator, you're not responsible for other people's sensitivity, but you are definitely in control of what and how you communicate.

<comment><USER40> Yes but in this discussion it's quickly become obvious that the listener is responsible for assuming good faith on the part of the questioner, because any phrasing can be interpreted as "I'm smart and you're dumb." Being professional is having the maturity to listen to answers when you ask questions.

Now, in the case of unsolicited advice, it may just be the questioner showing off. There's no phrasing that will help make a person feel good that they were used to stroke someone's ego.

</comment></comment></comment><comment><USER42> Some programmers will ask you "why didn't you just" questions about something you've worked on for weeks, months or years, not because they think they're smarter than you, but because they never think about anything for weeks, months or years.

<comment><USER43> If I am that interested in the problem/solution I am also interested in discussing it. Answering the question straight and assuming good faith is a good way to open up that discussion. Even if they don't understand, there is still the chance that explaining it gives me a new perspective.

If I don't value interacting with that person, then I've already lost before I start. Communicate for its own sake. Enjoy the journey or don't bother with the destination. Expectations of being understood or being judged favorably just confuse the issue.

I understand why this becomes an issue, but I don't think it is productive to concern ourselves with such peccadillos. If these things become important, we might be starting from the wrong place.

</comment></comment><comment><USER44> When someone is not insecure, they won't take offense even if the speaker meant "response 1" and if they are, even "response 2" would cause them pain. In the end, one interprets other people's intentions based on what they actually think (or fear) about themselves.

Because of that, if you are a sensitive person, working around other people's insecurities is a difficult thing. I think that if you are trying to take care not to cause the other party to take offense, then "including a ridiculously long and pleading disclaimer before what should be a short question" is not such a bad idea. You're treading potentially dangerous waters, who said you should be able to go fast?

I often would say something like "I don't mean to be rude but I'm curios, why does sshd not work here?" with a non-confrontational tone and a genuinely- intrigued expression.

</comment><comment> d--b The problem here is that the author assumes that the person he is addressing is a total moron for not using sshd, so he is afraid that his question is going to be badly taken.

Most people when asked "why didn't you just xxx" would answer in 3 ways:

1\. Oh shit, you're right, I'm such an idiot... oh well...

2\. Because yyy

3\. I don't know xxx, can you show me?

The issue is that people feel the intention behind your question because of context (mostly what your relationship to that person is)

<comment><USER45> I think it just depends on the person asking. I have known people who could call you an idiot to your face and still come off as the nicest human in the world, and people who could ask you to pass the salt and you would think that they didn't know if you were capable of it. Some people just have a hard time not coming off as condescending, but that says nothing of their intentions.

</comment></comment><comment><USER46> So how should I phrase a question or concern when I _don't_ think the other party has already anticipated using sshd?

It's easy for even very experienced engineers to get sucked into a solution that they don't realize is the wrong path until they've talked it through with someone else. And that's not a sign that they're incompetent nitwits. It might just be that no one ever told them about Obvious Solution X because everyone assumed they already knew it. Is there a good way to basically say "why didn't you consider using sshd and if you didn't because you just blanked or you don't know what sshd is, that's cool, let's talk about it"?

</comment><comment><USER47> Ask an open question, preferably one that doesn't involve the "why".

For example,

> What made you realize that sshd wasn't going to work for you?

Or,

> I've used sshd for similar tasks; what's your advice for me to get familiar > with the differences?

This kind of question helps shift focus on the answerer and enables them to tell their story. It's unlikely for them to feel insulted if you convey some degree of genuine, honest interest in what they have to say.

</comment><comment><USER48> How about "Why does sshd not work?"

You are hinting that it doesn't. You are not suggesting that you know it should, or why, even if _they_ can't give you a good answer. You are also not assuming that they don't know.

It's easy enough for the other party to come up with some mediocre reply to save face. That allows you to further assess how perceptive the other party is to receiving assistance. For example some version of "I tried that at some point, didn't work" would probably lead to me backing off respectfully. Any "why/how" question and we can take it from there.

</comment><comment><USER49> "have you tried xyz?"

The problem with the other approaches is that they imply that you are judging the person. This one only implies something that they may have missed.

<comment><USER50> Unfortunately, if "xyz" is one of the approaches they _did_ already try/dismiss, it still comes across as patronising.

<comment><USER49> Really? I've never considered it patronising.

"Have you tried x?"

"Yes, that's the first thing I tried."

"Hmm, how about y?"

"That too."

"Well that has me beat. Unless maybe you tried something crazy like z..."

"Actually, with a slight modification that might just work well enough for this!"

</comment></comment></comment><comment><USER51> Or just don't get offended so quickly, this is just how people tend to speak sometimes. Don't implicitly add bad intent or insults when none were explicitly made.

<comment><USER52> I think it's OK to expect that people in the workplace take responsibility for improving their own social skills, which is really what this boils down to.

To be honest though, many times I think this kind of situation can be avoided by talking through the problem with others at the beginning.

</comment></comment><comment><USER53> "Can you walk me through what you've tried so far?"

<comment><USER54> Open-ended, as opposed to a leading question (one where the solution is pre- supposed).

</comment></comment><comment><USER55> My general approach has been to use someting along the lines of "is there a reason for not using sshd here?"

Also, quite recently I had an experience where I used a quick solution without thinking about alternatives; a colleague simply said "I worked on a similar thing some time ago, and we did XYZ", which was not only better than my solution but also prompted me to think about alternative solutions. In the end I went for a third, arguably best solution, which I would have never thought of if there wasn't for the colleague's comment.

<comment><USER56> I like this quote from a colleague. Talk from personal experience and just state what you did or saw done. Add a value judgement on the past -- like " It was very stable." \-- if you want. The suggestion to use X here is builtin and you aren't claiming to know more about the specific application than you do.

</comment></comment><comment><USER57> I think this is one of those things that is going to vary cross culturally, and trying to come up with a single perfect phrase that works well for all situations, for all people, from all cultures is going to be impossible.

Plus how did you come to offer help? Requested, vs told to help by a manager, vs offering your opinion off the cuff, vs have asked if they are interested in your ideas. There's a difference between offering your help as a favor, and requesting of them if you can share your thoughts too. That's all going to impact your best approach.

One thing that might work is to ask them to talk you through what they've tried, and pay attention. Even if nothing helps you help them, you are showing that you value their thoughts and effort.

I might use "we" language.. "What if we tried sshd?"

I might even restate the problem to get agreement but without stating the solution, and then build on that agreement "It sounds like you want to be able to access this machine remotely in a secure way that lets you input commands, right?" "Yeah" "So maybe ssh could work?" "Well it's behind a firewall since it's an internal server so you can't ssh in" "What if we could log in securely to a server behind the firewall with ssh from outside, and then ssh from there to the machine you need to access?" etc etc. Getting people to agree predisposes them to keep agreeing.

</comment><comment><USER58> I'm acutely aware of this, and my pattern for phrasing things when I'm new to a scenario I'm trying to help out with is:

"What happens when you try x?"

What very often comes next is a clear explanation of why this obvious solution won't work, and often directs you right to the heart of the problem.

Every once in a while, you get an "Oh. I didn't think of that."

It's respectful, it assumes that person is smart and competent, and usually gets you where you need to go to start thinking about the hard problem at hand quickly.

</comment><comment><USER59> My usual would be "the first thing that comes to mind is X". If they have tried it, they know that I'm just throwing out ideas rather than calling them stupid, and if they haven't tried it, it's a gentle enough nudge towards a potential solution.

</comment><comment><USER60> Framing the question in a proper way is interesting. By the way, I think there's another common pattern, especially in the corporate/enterprise world: the proposed solution is ACTUALLY better and simpler than the super-complex- version that somebody is proposing; but:

\- At a certain point, the original problem was forgotten. Maybe the original problem was "execute some commands on N machines". But initially, those machines were a mix of operating systems, some of which would not offer an ssh daemon. And another path was pursued. But, after a certain time, all non-ssh- offering OSes were pulled, but the pursue of a different path remained.

\- Technology evolved in the months-or-years while pursuing a certain solution, and the original pursuer either didn't know that, or he would not be ready to abandon his efforts (sunk cost fallacy)

\- Sometimes, just looking from outside is a good way to find a good solution.

\- Sometimes, just trying to solve a problem for months or years lets the solver to properly frame the problem, and enunciating a problem in a good, concise, comprehensive way goes miles towards finding a solution.

So: sometimes people who ask things that way actually think that the solution is stupid. But they shouldn't think the people trying to solving it are stupid.

</comment><comment><USER61> For me, one question like this isn't too bad. Ten are. Then it becomes a botched kind of Socratic dialog. In a true Socratic dialog, the _teacher_ (who presumably knows best) controls the flow of explanations. In "why not just" the learner wrests that control away while still expecting the teacher to do all the work. It forces the explanation to take the form of an (unsought) argument. I have several friends who routinely use this method to learn a new area. One of them does it so consistently and aggressively, even after I've called him on it, that he's now an ex-friend.

The killer combo IMO is "just" (setting up a default position) and "you" (associating an initially assumed-inferior position with a person). That's why phrasings like "why doesn't ssh work here" aren't as bad. They keep things collaborative rather than adversarial. This becomes particularly clear with repetition, with a series of "why don't you just" bearing a stark resemblance to a legal cross-examination. It's better to avoid those two markers unless you know that's what both parties are after (which is fine when it happens BTW).

</comment><comment><USER62> It's funny reading all the debate about different wordings because it totally misses the point. The wording doesn't matter, only the delivery does. The recipients's interpretation of the question depends on who is saying it and how they say it. Whether or not they include the word "just" is irrelevant. Any single one of the phrases mentioned can be delivered in a way that causes offense or doesn't.

<comment><USER63> Came here to say a similar thing. The reaction can say a lot about the person's opinion/impression of you. It might be too much to try to correct for other people's insecurities; however, if you find that a large portion of people get upset by your phrasing, then it might be worth it to consider how you present yourself in general to others. It might just be you.

</comment></comment><comment><USER64> I like to say "I'm curious why you didn't use ______". Curiosity comes with an implied humility and a willingness to learn new information.

</comment><comment><USER35> The article leaves out the most important question: why do you want to ask why they didn't just...?

Even assuming that your intentions are entirely good and you totally intended only the author's response #2 and there was no element of response #1 at all (yes, you can see I'm skeptical of such claims--why will appear in a moment), the mere fact that you feel so compelled to ask why they didn't just... implies exactly the opinion of them that response #1 makes explicit. Obviously your own curiosity is so important that it outweighs anything else, and obviously your curiosity must have some basis, and so on and so on.

In other words, the correct answer to the question the author asks at the end--"What to do?"\--is: NOTHING. If they want your advice, they'll ask for it. If they don't ask, then keep your trap shut. It isn't about you.

(I note, btw, that the article by Mike Hoye that this article links to makes exactly the same point I just made--which raises the obvious question of why this article's author apparently didn't grasp it.)

<comment><USER65> Someone may be genuinely interested in feedback. In such cases, you want to be polite and respectful while still communicating that "This is my first thought." It gives both parties room to maneuver and save face. That framing makes it possible for them to reject the feedback without suggesting anything negative about you (like "No, _you 're_ the idiot here!").

You may be genuinely trying to understand it yourself, in which case it's going to be easier to comprehend what's going on if you can relate it to the existing framing in your mind without offending them. It takes a lot of time and energy to mentally move from "My first thought is X" to "How do I say this in a way that elicits information without me sounding like I'm judging...etc?" There isn't enough time and energy in the day for every single social interaction to meet the standards for some kind of international diplomatic mission, but you also don't want to just excuse outright rude behavior. It's reasonable to explore your options if you as an individual run into a particular social thing repeatedly so you can handle it not horribly without being at the top of your diplomatic game every nanosecond of the freaking day.

Last, if you have enough education/experience related to X, you may actually have a better answer at first glance. They might actually be interested in improving it and open to your suggestions -- again, if you can share that information without unduly stepping on toes.

Sometimes trying too hard to be polite and respectful and perfect is actually antithetical to any kind of meaningful communication. Good social practices have to be tolerant of a little friction while seeking to lubricate it so it doesn't rub people the wrong way to an aggravating and problematic degree.

This is counter-intuitive. To genuinely connect socially/intellectually, there will be _some_ friction. If there isn't _any_ friction, you aren't actually connecting with people. But you don't want it to be excessively rough because that's counterproductive.

<comment><USER35> _> Someone may be genuinely interested in feedback._

 _> You may be genuinely trying to understand it yourself_

 _> if you have enough education/experience related to X, you may actually have a better answer at first glance. They might actually be interested in improving it and open to your suggestions_

If any of these things are true, you will either know them well enough to know how to talk to them about it, or they will ask you explicitly for your input. In either case, you will not need to write an article asking the entire Internet for suggestions on how to talk to them.

In other words, I am not saying the things you describe cannot happen; I am saying that the fact that the author of this article had to write it at all means none of the things you describe are happening in the case he describes. If they were, he would know it and wouldn't have had to write the article in the first place.

<comment><USER65> Not everyone is equally socially astute. Some people aren't good at inferring such things. Such people need to work at it to make their life work.

Even if you are innately good at it, you may not automatically know how to handle it well if it's a new context in some way. This can include being a foreign national or facing other cultural barriers.

The most socially astute people aren't simply "born with" such talents. They work at it on top of whatever natural talents they are fortunate to have.

<comment><USER35> _> Some people aren't good at inferring such things._

And my advice to those people is exactly what I said: if you're not sure how to communicate what you think is a good suggestion, or how to ask a question you're curious about, without giving offense, because you don't know the people or their work well enough, then _don 't do anything_. That uncertainty you feel is a clue: it means you shouldn't be doing anything at all. Heed it.

<comment><USER65> For many people, such advice boils down to "Just be a prisoner of your limitations and don't ever try to overcome them or grow as a person."

I cannot fathom why you have such a big problem with someone using a blog post to crowd source suggested wording to try to explore how to do X better.

<comment><USER35> _> For many people, such advice boils down to "Just be a prisoner of your limitations and don't ever try to overcome them or grow as a person."_

You are seriously misinterpreting what I said.

What I said applied to a very specific scenario, the one described in the article: you have something you want to tell or ask people when you don't know them or their work very well, and you aren't sure how to say it or ask it without giving offense.

If you don't like the fact that the best thing to do in that situation is nothing--don't tell or ask them--then you have an obvious way to change the situation so that's no longer the only good option you have: _get to know the people and their work better_. In other words, _connect_ with them, exactly as you describe. Once you've connected with them, you will either know how to tell or ask them what you wanted to tell or ask them, or you will have found out that you don't need to tell or ask them any more, because you have found out the information you originally wanted without having to.

I understand that connecting with people like this is very hard for many people, particularly techies. It's hard for _me_. But that doesn't mean you should try to avoid it, and I never said you should.

 _> I cannot fathom why you have such a big problem with someone using a blog post to crowd source suggested wording to try to explore how to do X better._

Because he's doing it backwards. He's trying to tell or ask something potentially offensive to people he doesn't know well, without trying to get to know them better first. In other words, instead of asking how to do X better, he should realize that he needs to do Y first, before even thinking about doing X.

</comment></comment></comment></comment></comment></comment></comment><comment><USER66> Avoid "why." Instead ask about "how" and you'll get lots of "why" for free.

"I'm trying to visualize doing this without using sshd and am drawing a blank. It's probably something really basic I'm missing; would you mind telling me how you did it?"

Key here is to be genuinely interested. If all you want is to slap the other developer around they will know.

</comment><comment><USER67> I've been in this situation many times before. The way to to it is to not only ask, but suggest a possible reason:

"What's the issue with sshd? Does it not have an option to do x?"

By following with the potential issue, you are not saying "Are you retarded?", either by omission or directly. You are leading the tone of the conversation down the productive path.

</comment><comment><USER68> I think it is best left unasked.

If you care to know, you can take a day to think about it. If it is not worth you thinking about it, then let it go. But if you care enough - Learn about what they did, scan the source code, look at how the tool is used.

If you come to the conclusion that they made a bad decision - ok - keep that to yourself. If you come to the conclusion that their solution actually is better, mention it to them enthusiastically and build a bit of trust with them by showing that you are willing to think and inspect, not just ask drive-by questions.

If you see someone constantly re-inventing the wheel, then look for an opportunity to discuss solutions before the next project begins. If you are showing up only during presentations, then you are too late to apply your knowledge. If the goal is to improve things and you are knowledgeable and clever, you need to be in the brainstorming business, not the "embarrass this guy during presentation" part.

</comment><comment><USER69> I'd say "Hmm, what about sshd?" or "Hmm, what do you think about sshd?" I'd also say it's more about how you say it than what you say. If I were to use the aforementioned questions, I'd come from a place of self-doubt and I think which is exactly what "Response 2" in the article says it is.

<comment><USER70> I agree. I use "What about?" almost daily. It can either be a gentle suggestion, or a request for information. Neither is aggressive, so it works out both ways.

</comment></comment><comment><USER71> The problem is the prescriptive nature, i.e., being very tied to force the "sshd" into all of these examples. You need to ask more questions leading up to figuring out if sshd suggestion would even be applicable, and if you get the point where you've done that, and you haven't heard sshd mentioned yet as something explored, then that's the time to bring it up.

And I'll add, it's not condescension that's the big issue here, it's that suggesting technologies before you fully understand a problem suggests a specific level of naiveté that people are on the lookout for. I can exactly place a person's technical problem-solving maturity level by how quickly they get to throwing out technical solutions, because people that have been around the block may have these ideas in their head, but they also know the questions to ask to ferret out where the complication lies.

</comment><comment><USER72> If it's that sensitive, I'd probably start by spending extra time, trying to figure it out without asking.

If it's a code review, then it's expected that hard questions be asked. I'd remove the "just," and watch my intonation.

Chances are better than even, that it ain't that important, and not worth my extra time.

If the engineer isn't that good, it will show itself in more obvious ways, sooner or later.

I've come to value team cohesiveness. When you have a team of high- functioning, self-confident, highly-intelligent, motivated people, it won't be a smooth ride. Passions abound, and people will disagree; sometimes vehemently.

Respect and cohesiveness are EARNED. If someone knows that I respect them, then I can be a real jerk, and it won't damage our relationship (as long as it isn't chronic).

I managed just such a team for a long time. When we finally disbanded, the engineer with the least seniority had ten years.

The current tech industry is hyper-competitive. Everyone is competing against everyone else. It's not enough to be "as good as" someone else. We have to be BETTER than everyone else.

When the average stay at a corporation is 24 months, people don't get that invested in a team. They are there for a fairly quick job. In and out. Don't make eye contact. Don't lower your shields.

One of the important things about working in a team, is that other members of the team watch how we treat others. If I'm mean to Joe, then Bob will assume that I'm mean; even if I'm right, and Joe was in error. The emotional impact will impart the lesson; not logic. He won't remember Joe as wrong; just me, as mean.

There is no solution that can be achieved by a simple change in wording.

But that's just me, and my experience. YMMV.

</comment><comment><USER73> I ask this kind of questions rather often, and rarely have the problem of it being interpreted as #1. Thinking about it, I think there are two things the author missed:

\- tone of voice. Any of those can sound really snarky or very interested, depending on intonation.

\- history of your interaction with that person. My colleagues (hopefully) know of my tendency to brainstorm out loud, and that I am quick to accept seeing limitations in my proposals. If you have an history of not saying much and not accepting criticism, the initial sentence will come across very differently.

Plus sometimes, the first idea of someone else _really is a good idea and was not considered_ . This happens quite a lot where I work, where people have very diverse backgrounds. Having people avoid saying "obvious" things is really dangerous in multidisciplinary teams.

</comment><comment><USER74> My go to for this is "My first thought would be to use sshd here. I assume you've tried that?"

<comment><USER75> Yeh or "I'm guessing 'obvious solution' didn't work?" Either way any phrasing that implies you view them as an intelligent person who may have slipped up vs you just assume they are dumb will work fine?

</comment></comment><comment><USER76> "What's the motivation to not do x?" is my personal favorite way to be asked this, because there typically is a reason, and it's typically where the thorniest parts of the project lie. It's a good softball question to get to the non-obvious problems.

</comment><comment><USER77> I like the way the author tries to dismantle this phrase, but it seems to me there is no magical way to phrase the question and have it not be interpreted however the other person percieves it. Ultimately, communication is a two way street. One has to assume that the other party is working in good faith- if you are 6workin in the spirit of cooperation, the phrasing doesn't matter that much anymore, the positive meaning will come through.

That said, I liked the last phrasing in the article. It shows perfectly what the question is: "this was my first idea, I can't see why it wouldn't work. Do you want to try this, or have you already thought of it and is theres a reason it's not working?"

<comment><USER78> What is interesting is that communication is at the heart of many things unless you are alone — and many are completely unaware of this. E.g. driving your car in traffic is quite definitly communication, as others have to "read" your behaviour and interpret it. Good drivers are very concious about what they communicate in which situation, bad drivers communicate completely without knowing about it and are bad at reading others communication.

I think you should always think a little bit for the person opposite: Did you give enough context? Is it ambiguos? etc.

</comment></comment><comment><USER79> You can put a lot of effort into crafting a way to ask a thing, and it'll probably work in that specific instance, but it doesn't solve the broader problem.

My working theory of "how to answer questions" is about making my thought process transparent. And, especially, explicitly stating what information I'm lacking.

"I'm looking at your requirements, and I see X and Y so my immediate inclination is that I'd simply use sshd.

And if that doesn't work for you, knowing why can probably nail down what would work."

The transparent thought process gives them an insight into why you're saying the things you do.

And explaining what I need helps them move the discussion forward. It avoids me being a brick wall of incomprehension.

</comment><comment><USER65> "At first glance with what little I know about the project, my first thought would be sshd. Please fill me in on the background here so I have more context and can better understand the problem space and chain of logic."

<comment><USER80> Yes! I've looked through these responses exasperated. This is the only one that I agree with. The people who say "why didn't you just" often have a very limited understanding of the new thing, and naively reduce it to a problem they do understand.

<comment><USER81> To me, both responses are the same.

Orwell's "Politics and the English Language" comes to mind. You're saying exactly the same thing but in a bureaucratic form.

Reading other posts here the message I get is that a lot of people work in dysfunctional environments in which everyone's at each other's throat or something.

My default assumption would be that obviously my colleague isn't being an asshole...

<comment><USER80> The majority of times people have said "why don't you just..." to me the answer is that if they understood what $thing was trying to do they wouldn't have asked the question. They're not being "assholes" they're just headed toward it from a wrong assumption (they're assumption is that they understand what $thing does, but they don't.) so my advice to anyone suggesting just do $x is that they need to try to understand what they don't understand about $thing, don't even worry about $x.

<comment><USER81> Sure, so the answer is 'because I'm doing $thing and $x doesn't work'.

They're literally asking _why_.

If you take it as a statement i.e. 'just use $x' then that's a completely different matter.

<comment><USER80> It would've been easier to explain $thing without having to stop and consider $x. Effort was expended for no gain.

</comment></comment></comment></comment></comment></comment><comment><USER82> "What benefits does your project offer over sshd?"

I use this because 90% chance the person has an answer ready for the exact question. "sshd is more difficult to deploy in blah blah situation", which is an emotionless answer.

</comment><comment><USER83> "Did you consider using sshd?"

"Would sshd have worked here?"

"I've seen sshd used in cases like this in the past–was that an option?"

Why didn't you just use one of these phrases?

<comment><USER84> Did you consider using one of these phrases?

Would one of these phrases have worked here?

I've seen these phrases used in cases like this in the past, was that an option?

<comment><USER83> That was the joke.

</comment></comment></comment><comment><USER85> There's no reason to be jumping straight in with "why" in this situation at all, one can perfectly reasonably ask "have you tried using sshd".

Why doesn't the author just try putting it that way?

<comment><USER40> He mentions that there are complaints about even that approach.

<comment><USER85> Where does he mention that? I don't see it.

</comment></comment></comment><comment><USER86> The problem appears to me to be around the _assumptions_ that we make when we use the phrase "Why didn't you just use x?"

Consider "Did you try x?". It's matter of fact. It offers them the benefit of doubt whilst simultaneously giving them the the opportunity to be oblivious x, without assuming one way or the other. Much easier to begin a conversation with.

Speaking about facts makes conversations easier. In tech we're told "don't just give your opinion, bring evidence" \- evidence are facts. The same works here too.

<comment><USER87> Actually the problem in this kind of conversations is often the lack of the "standard litany" initially:

[https://jdebp.eu/FGA/problem-report-standard- litany.html](https://jdebp.eu/FGA/problem-report-standard-litany.html)

if - from the start - either:

1) sshd was mentioned as tried (detailing exactly how it was tested) but not working

OR

2) sshd was not mentioned among the (several) attempts made

it would become perfectly acceptable to not reply mentioning ssh in case #1 or "Did you try sshd? in case #2.

What commonly happens in real life is that sshd was actually used, in a wrong way, and not mentioned, so when you - after having thought a bit on the problem - propose the "Did you try sshd?" you are perceived as either "obvious" or "condescending" anyway and you get a reply like "Sure I tried it, it didn't work!", without any detail on how exactly it was used, so you also exclude it as a valid possible solution even if (used correctly) it would work.

</comment></comment><comment><USER88> "Coming into this with fresh eyes, my first thought would be to use sshd. I'm thinking that might not have solved your problem though. Did you try that and it didn't work out?"

</comment><comment><USER89> He starts out presuming the problem is with the receiver or the words. He never considers it could actually be him in a way he doesn't yet perceive. This is evident as he doesn't even appear to get the gist of the mhoye blog post that triggered his question.

> _" The more self-effacing I make it, the more I try to put in that I think > the trouble is only in my own understanding, the more mocking and sarcastic > it seems to me and the more likely I think it is to be misinterpreted."_

His trying so hard to be "self-effacing" brings to mind Shakespeare's line, "The lady doth protest too much, methinks."

He considers the TEN different phrasings, yet never the straightforward and humble "Did you ever try sshd?". All ten reflect a patronizing attitude, the assumption that his immediate intuition is correct by default. The "naïvely" one comes off to me as obnoxiously pseudo-humble.

Complex wordings aren't random. They reflect something of the speaker's mind or attitude.

There is a good reason why many people love the way very young children put things so simply, without mask or artifice. WYSIWYG.

I believe the author, Mark, has good will. But good will is not the same as humility, nor does it give one self-awareness. Like a man who believes he isn't sexist because when he, a man who's never been in a woman's shoes, looks in the mirror he doesn't see any sexism.

</comment><comment><USER90> "For every problem there is a solution that is simple, neat — and wrong."

I start with the basic assumption that the person I am talking to has spent more time thinking about the problem than I have, which is a good one because I have just walked in. Therefore, if they did not do the Thing Which Is Obvious To Me, there must be a reason for it. I try to work out what that is and volunteer _that_ as "I'm guessing $reason played a factor?"

Once you begin treating a person as someone you have something to learn something from, everything changes. It has been difficult to do this at times but it pays off so frequently I have little reason to recommend against it. If I have to ask someone on a help line for something, I will briefly explain myself and ask, "If you were me, what would you do?" I watch in amazement as someone who has been used as a speech-recognition front-end for a flowchart brings expertise, insight, and judgment to the situation.

The reason I do this is because I have been asked "why didn't you just ..." so often by people who are looking for the simple solution every time and exist in this constant welter of disappointment that the world might be slightly more complex than plugging things together tend to look at you in this resentful, exasperated manner as if you, personally, are withholding the Easy Way Out. I just do not want to do that to other people, having been on the receiving end of it myself so often.

You will run into people who have overlooked the obvious but that will be much rarer than you would imagine.

</comment><comment><USER91> I say "what was the problem with sshd"? This gives the other person the benefit of the doubt, and also compliments them on being rational actors who obviously evaluated this already and are now going to report their findings. If they haven't considered it, they usually just say so, and if they have and their concerns have workarounds or are incorrect I address the concerns without making it personal. Or they might just right, and know something I don't.

</comment><comment><USER92> I agree that all of the versions the author listed are no good; they do sound just as condescending or maybe even worse than the original.

For myself, in a similar scenario, I tend to say "Can we just...?" Granted it's not enormously better, but I feel like using "we" (as a rule of thumb in any work conversation too, not just in this scenario) always lightens it up and makes it more like we're on the same team (which we are) instead of me vs you. (And if you want to be even more neutral, omit the "just", and say "Can we use sshd?")

Digging a little deeper though, the issue of whether someone takes you more lightly or more aggressively comes down to how they perceive you as a person (your personality) and what they already know about you. If you come across as a friendly and funny person every day (through lots of other things you can do), when you say "Can we just...?" it becomes easier to understand you as well-meaning and saying in a tongue-in-cheek way "I'm an idiot, here's a simple straightforward suggestion, probably won't work?" instead of "You are an idiot, here's a simple straightforward suggestion, why didn't you think of it".

</comment><comment><USER93> I had the exact same issue with my wife, my theory is that people with an inferiority complex will suppose response 1, and I think that has to do with them frequently exposed to people with superiority complex supposing 1 when they give them feedback.

My take on this is to target the inferiority complex by lifting them up, i now usually say:

I see you used X instead of Y, knowing you, I suppose this was not accidental / was deliberate and I'm now curious

</comment><comment><USER45> I like "what would happen if you used sshd"? (Not "tried sshd", that's important). They will either tell you the outcome of what they already tried or will be lead to the solution.

The only way I can think of this being misconstrued is "what would happen if you used sshd? Or are you an idiot and you haven't even tried it yet?" But that's a bit of a stretch. The reason I think this is different from the other phrasings is that it presupposes that the person has already tried the solution more than not. At the same time, it makes your ignorance clear - <USER3> cannot say "when you used sshd" because you don't know if they have tried it yet, but you ask them for the outcome knowing that they might've.

The downside is that for sometimes people might not pick up on what you're saying if they don't know much about the solution because it's so indirect, but that's the trade-off for favoring the other side of things. I think that once you know they haven't tried it, you can be a bit more direct as long as you're not condescending. Not that this is easy.

</comment><comment><USER94> What seems to work for me is specifying exactly _which part_ of the solution you might want to replace and _why,_ phrasing it like a brainstorm idea rather than a fully thought-out proposal: "Would it be easier to frobnicate if we replaced the blarter with sshd?" This should make it clear that a) you're not suggesting that the blarter feature set overlaps exactly with sshd, which would be an astronomical coincidence, and b) you're focusing on frobnication to the exclusion of every other axis along which you might measure the usefulness of the blarter.

In my experience the responses are always productive - most of the time they are happy to explain why the blarter is better at frobnicating or why some other useful feature of the blarter trumps sshd. And once we have a dialogue it's easier to introduce other brainstorm-y ideas. Conversely, in the rare case where they realize that sshd is actually a good alternative they simply hadn't considered they often instantly volunteer three other reasons why it's more useful than the blarter.

</comment><comment><USER95> "Would we be able to use a simpler method - could sshd work?"

\- "We", rather than "you", puts the question / phrase into a team context - ie. you are there with the other person to help, not to point fingers.

\- Asking the question at the end indicates that you are unsure whether you are correct or not, while leaving yourself open to criticism, thereby displaying humility.

</comment><comment><USER96> just assume they considered your suggestion and ask as if they did and must indeed have a reason why it didn't work:

"so what was the issue with using sshd?"

you're assuming competence, and if they say "oh I never thought of that" then you can prompt them to consider it - "might be worth a shot" or something like that. Comes across less accusative I think.

<comment><USER97> Yes I agree. A 'what is the problem with using sshd?' or similar seems valid to me. It gives them a way to actually explain if there is a problem and if not, oh that might work.

</comment></comment><comment><USER98> "Why can't you just" is a huge pet peeve of mine.

"Why can't you just" is particular frustrating when someone interrupts a deep conversation. What they're really saying is "can you please stop your conversation and focus your full attaching on catching me up to all the issues you discussed 2 hours ago?"

Here's an alternative:

"Can you tell me about your problem?" Then shut up and listen.

And here's a slightly longer form:

"You've thought about this way more than me. I'd love to brainstorm with you. But I'll need to catch up. <Listen. Listen more.> So why doesn't sshd work? Ok, and why can't you foo? Oh damn. What happens if you bar? Dang. I don't have an answer yet, but I am starting to understand your problem".

Odds are decent that someone will solve their own hard problem by using you as a rubber duck. Odds are very, very low that you'll solve someone else's hard problem by offering up the very first thing that comes to mind.

</comment><comment><USER99> The fundamental problem with the "Why didn't you just <solution>?" format is that implies the other person knows less than you. Going down the self- effacing route just goes from "I think I have the answer" to "even though I don't know a lot about this, I still think I have the answer". It's actually _worse_.

Instead, I prefer approaching the discussion as me catching up to the current state of affairs. "What options have you looked at? Why haven't they worked?" followed by "Ok, have you considered/tried <my solution>?" Both fixes the subtext problem while actually giving you more information to work with — you can now choose to offer the "obvious answer" or not depending on their response, and potentially have a stronger argument for why it's a good fit and/or some caveats about why it might not be a great fit (but still worth trying)

</comment><comment><USER100> I disagree; "Why didn't you just use sshd?" is a valid question and can be answered as such. Of course the answer might be "I don't know", but also there might be an answer, and maybe they do know the answer and have a good reason to don't use sshd; I don't know. That is why I ask. Then you can learn.

<comment><USER101> Unless the person you're asking has specifically asked you for questions you shouldn't approach every situation as an opportunity for you to learn. Sometimes the situation is about other people, their work, and accepting what they've done as a valid use of their time. Asking a question that could potentially invalidate the effort they've put in, even if you think it's a reasonable point to raise and you think you could learn from it, is just incredibly selfish.

A key skill in communication is anticipating what the potential outcomes of what you say might be in a particular situation. In this case, the question _can_ be valid, but it can also be _completely_ the wrong thing to ask.

<comment><USER102> Thank you for pointing this out - after reading the OPS article, it is the first thought to mind. Maybe I missed it, but the premise of the article is contextualized on the response rather than the originating presentation of the problem. If the person isn't asking for your help, it can come off as offensive when hearing remarks/responses like this; and as many point out in the comments - there is no easy way to say it. This just leads to that person internalizing in the future and less likely to seek actual help. This isn't an insecurity, NO ONE wants their work invalidated. (and so many wonder why workplace burnouts are common)

While the proverbial "There is no I in team" applies here, the real lack of social skills is on the OP, not the person presenting the problem.

Re-phrasing aside, a simple, "Hey, that's an interesting problem. I may be able help if you'd like" before stating the obvious solution will go miles in the conversation and re-enforce the relationship between both parties.

</comment></comment></comment><comment><USER103> "My first instinct is to use sshd. Have you tried that already?"

I use phrasing like that and "My knee jerk reaction is..." etc. intentionally because (a) it's accurate context and (b) it allows the person to wave it away casually if it's irrelevant. In any case, I find that the conversation remains both polite and productive.

<comment> r-w Why give anyone the opportunity to wave away your ideas? :) I don't think the other person should be respected at your own expense.

<comment><USER103> I mean "wave away" in the context of "Yes, I already tried that."

</comment></comment></comment><comment><USER104> Shortest version: "Could you use X?"

Three advantages: First, studies show people like to say no more than yes. This fits a no, perfect for the knee-jerk denial, but most would follow up with a reason. As the reason is formulated, one may realise the initial assumption is wrong. However, at this point the person is discussing with himself. This is exactly what you want: The asker is out of the picture; the parades are down.

Second, an answer in the negative does not reflect poorly on the asker, as the question does not speak to preference. He may already be inclined towards a no, but just want the reason for X not being the better choice. Hence, less chance for a follow-up justification leading to a discussion.

Third, it merely establishes if X is feasible. Higher chance of finding common ground when discussing feasibility without preference.

Lastly, it doesn't get much shorter than this. Less words is less skin in the game.

</comment><comment><USER105> I guess I don't see this as much of a negative question as others seems to. I'm one of those people that likes to work on more obscure solutions to things just because they interest me. Might or might not end up with a better solution than the common method, but I gain insight that I can maybe leverage on some other problem. So the question "why didn't you just..." usually ends up with me stating why I thought that solution was interesting and what I've learned by avoiding the obvious solution. Of course, sometimes I simply didn't think of the obvious solution, but you can't put yourself out there without a little risk.

I don't tend to assume ill intent for questions like that. Someone saw the problem, and proposed an obvious solution. That's just being helpful, even if they start off thinking you're an idiot.

</comment><comment> luka-birsa What about:

\- Asking them why did you pick X? (here you might get an answer why you didn't pick Y) \- Telling them that you tried Y and it worked for you.

So it's understanding their process and sharing your experience. I think in the end you should have the engineer decide on his own.

In the end they might go with X anyways, so you'll need to react to that.

I've had an engineer going for X for 14 days, but every time we had a discussion I've asked additional questions about X for me (and them) to understand why going for X is a better approach. In the end he figured it out that Y is a better approach. While it took a while, the engineering person in the end figured it out and took the solution for his.

I've also had cases where this didn't work out, but in those cases I've put my foot down saying you need to use Y to the person. It's also the case that person is not with us anymore.

</comment><comment><USER106> Anyone ready to interpret the question as response 1 woud seem to me about as unbearable to work with as a person asking the question and actually meaning reponse 1. That's a very sad working environment and my Gordian knot solution would be to try to avoid those collaborations altogether.

</comment><comment><USER107> The whole angle of the author is wrong.

If you don't want the other person to take it harshly, tell them exactly what you think. Talk about yourself and don't ask for an answer that you don't know.

 _I wonder if you 've considered using XY. It seems it might be a good fit thanks to the ZZZ property of XY._

</comment><comment><USER108> I sometimes start it with "I'm curious; why didn't you use sshd?" I think that does a decent job of clearing up your intentions.

I also believe, as a general rule; don't use the word You. Compare "Why didn't you use sshd" and "Why was sshd selected for this".

<comment><USER109> I was about to suggest "I'm curious: what about sshd?" And maybe follow up with a reason to use it or doubt it, such as "You could run remote commands through it..." Which naturally leads to "but it doesn't pass as easily through firewalls as SSL, and key exchange is harder than a URL encoded secret..." Essentially, take your suggestion and expand on it slightly, inviting further conversation?

You could also just bring it up generically, such as: "In the sprit of an FAQ question like 'What about X?' I'd be interested to hear your thoughts on how this approach compares to sshd?"

<comment><USER70> I agree. I use "What about?" almost daily. It can either be a gentle suggestion, or a request for information. Neither is aggressive, so it works out both ways.

</comment></comment></comment><comment><USER110> I find a general version of this to be hard. Someone with expertise who you respect says something that seems idiotic. Intellectual humility suggests you keep an open mind, but they essentially said "1+1 != 2." Maybe it's a Chesterson's fence kind of thing and you shouldn't refute it before you figure out why they said it instead of the obvious alternative. Or maybe you are sure they're just wrong but want to tell them so without talking down to them. It's very hard. "Doesn't 1+1=2?" "Have you considered that 1+1=2?" "Why aren't you just using standard grade school arithmetic?" "JFC. 1+1=2 ya nincompoop."

Even being socratic (my preferred slow as hell approach) can sometimes border being patronising.

</comment><comment><USER111> I disagree with the article premise.

If I say, "Why don't you just X?"

It's short hand for:

\- This is the first solution I thought of

\- I am sure you already tried this

\- Since you probably already tried it, why didn't it work?

It's about learning. I don't think most people are so fragile and insecure that you can't ask them about their problem space.

<comment><USER6> That's your (and my) shorthand for those meanings, and my intention in the conversation, but based on a large sample over the years, that _isn 't_ how a large percentage of people interpret it.

If 0.1% of people interpret a statement in a way that I didn't mean, it's probably their fault. If 40% do, then that's my fault.

</comment></comment><comment><USER112> "What options have you already looked through?"

If you were expecting sshd, and they mention it and rule it out because of reason X, you now have the start of a constructive conversation. "Oh wow, I didn't know that" or "Ah, hang on, I fixed something similar once, want me to see if I can dig out my notes?" are nice.

If you were expecting sshd and it doesn't show up, you could then offer "Had you considered sshd or ruled it out at all?".

Also, ask them for the problem they were trying to solve, and offer alternative takes on the problem, sympathise, and only go into alternative solutions after asking them to describe the solutions they've tried.

This is really hard, and I'm still trying to get better at it after 20+ years in industry.

</comment><comment><USER80> "This looks like a situation where I've used 'sshd' - but I might be missing the big picture here."

</comment><comment><USER113> I can paraphrase the vast majority of answers as "why don't you just remove the word 'just'?"

The _real_ issue is that if you don't know how to smile and be friendly and respectful in your body language, minor rephrasings won't help.

</comment><comment><USER114> Really, let's be honest; we want to show off how _we_ would have done it. That's all. How about:

> That's an interesting solution! I don't know whether I would have thought of > that. My first thought was to use sshd. Can I show you something?

<comment><USER24> It's possible that this would be an okay tone to use toward a junior developer or an intern. Could it sound patronizing toward a peer, or a more senior developer?

<comment><USER114> Sure, if one needs to suck up to a superior, then one should suck the dick:

> I would have used sshd, because I am inexperienced and don't understand your > approach. Could you help me understand?

</comment></comment></comment><comment><USER115> I usually start with the statement that I'm having trouble understanding the code. "I don't get it". But either way, it _is_ a criticism of the code if I don't get it.

Because truly, that in itself is the failing. If there's an obvious fix for the problem, and it's not obvious to the reader why an alternative approach was chosen, then the developer either failed to use the obvious tool or failed to make it obvious why they chose the alternate tool.

Because the next guy who has to fix bugs in this code might throw it out and use the obvious tool, and if so the code needs better comments or other explanation why that doesn't work here.

</comment><comment><USER116> > Whenever you look at a problem somebody's been working on for a week or a > month or maybe years and propose a simple, obvious solution that just > happens to be the first thing that comes into your head, then you're also > making it crystal clear to people what you think of them and their work.

I've been successful with a different approach.

Ask "What happened when you tried X," where X is a simple option, instead.

It implies that you think X could have been tried, and opens the door for an explanation for why it didn't work.

If X wasn't tried (and I am surprised how often it was not), then you find out. No chance for misunderstanding, except from the most defensive types.

</comment><comment><USER117> "What problem does this solve that existing tools don't?"

Something that gives them an opening to explain why they went down the path they went down. Bonus - if they didn't actually think of using sshd, this can lead to a gentle way of bringing it up.

<comment><USER117> Or maybe just "what was wrong with existing tools?"

</comment></comment><comment><USER118> I kind of like "why didn't you just (use simple and obvious solution that doesn't work for some reason?)" If there's a simple and obvious solution that doesn't work and the reason it doesn't work isn't apparent, it's nice to know why.

On the more malicious side of things, one of the more effective ways I've seen people blast something to oblivion is "I don't understand how (your stupid system) solves (intractable problem created by your stupid system.)" Occasionally someone will twist the knife by prefacing it with "Maybe I'm missing something here, but...."

</comment><comment><USER119> "Could sshd have solved this?"

The phrasings listed seem to bring in the other person's choice and thereby create an oppositional/contrastive/comparative dynamic in to the statements.

I write this having struggled with this sort of thing.

<comment><USER19> It's hard to ask this way without coming off the way a teacher comes off to a student. If you're in a mentoring situation, this clearly works, but if you are a peer or a superior, it's dicey without perfect tone and body language.

</comment></comment><comment><USER120> 1\. "just" is less of a problem, "you just" presents more problem because it asking about the person's motivation, and not the code/technical solution. "Why didn't `sshd` used here?" will is a better question.

2\. Asking this question doesn't tell people what you really think. Better question if it also followed by, "why" you think you can use `sshd`. "Why didn't you just use `sshd`? From my experience/quick judgment/limited understanding `sshd` is better/simpler compare to <suggested approach>, because of bla bla bla"

</comment><comment><USER121> It is not what you say but how you say it. People are emotional and tend to remember based on how something make them feel, not the phrasing of the conversation.

You could hypothesize a scenario where the poorest and even offending wording is used and as long as the person talking shows empathy, mimics and finds common ground through it's body language and most importantly, regulates its tone to avoid sounding judgmental. The receiver will find it easier to digest and accept the message in contrast to hearing the perfect phrased message.

</comment><comment><USER122> After reading this, Its killing me not knowing what they built, used, or implemented instead of using sshd. It would add much more context.

Is the author a Lead? Manager? Architect? On the same team, or department? A direct peer?

All of this matters in order to better answer the main question presented in the article.

Why wasnt more than one dev involved in discussing a design or possible solutions before the work was performed? If that was the case, where was the author when that happened?

Why didn't you just already know they weren't using sshd?

</comment><comment><USER123> The problem with the phrase is the inclusion of a presumed technology choice. My topical approach is to dig into the details of their approach to the problem. This gives there other person a chance to be the expert.

It also gives me enough information to determine if the knowledge gap lies with me or them, in a fashion that makes it clear I am interested in their point of view specifically. I don't think you can reword the single phrase in a way that won't sound offensive in certain contexts.

</comment><comment><USER124> "What are the limitations that prevent us from using sshd?" This has the best chance of being interpreted as Response 2, allowing the person to provide this information.

</comment><comment><USER125> "Why didn't you use [proposed x]": high risk of seeming like the beginning of a tiring argument.

"I never thought about using [used y]": maybe not true, but sometimes it's more important to be humble than right. You invite them to explain why they used it, or ask what you would use instead.

The difference is the first comes with implications, while the latter beats implications over the head with a shovel and invites the askee to help you bury the body.

</comment><comment><USER126> The problem isn't the asker. It's the answerer. The solution is to not to talk to such answerers. Most people I worked with would phrase that "Why wouldn't using just sshd not work?" And most people would answer that with "Yeah, we thought of that but it won't because X" or "Oh shit, that might be it" or "What's sshd?"

Well, it won't be sshd because everyone knows that. But you get it.

</comment><comment><USER127> "Did you consider using `sshd`? Why didn't it work for you?"

</comment><comment><USER128> The more self-effacing I make it, the more I try to put in that I think the trouble is only in my own understanding, the more mocking and sarcastic it seems to me and the more likely I think it is to be misinterpreted.

I think this a textbook example of the four sides communication model [https://en.wikipedia.org/wiki/Four- sides_model](https://en.wikipedia.org/wiki/Four-sides_model)

</comment><comment><USER129> > I was thinking about [the problem] and was wondering if sshd would also work > [because of X benefit], what do you think?

I would probably phrase it something like that. State why you're bringing it up (I'm trying to solve the problem, not just criticise your solution), assume they have already considered it, ask what they think about your idea instead of just offering advice about theirs, both options are still on the table.

</comment><comment><USER130> The approach I would use also works in the related situation where you're trying to help someone fix a problem and you want to be sure they've tried all the obvious things.

"I'm going to sound like a tw@t* saying this, so I apologise in advance, but I have to ask anyway. X"

where X = "Did you try ..." or X = "Why didn't you use ..."

* change the expletive to whatever's appropriate given whom you're addressing.

</comment><comment><USER131> Okay, I have a question for the author:

Why didn't you just use a website layout which was easy to navigate and understand for people using screen readers? Is it because it's not a topic you've ever considered, or did you do research into it and just find the documentation and available resources lacking? There is only a single heading on the entire page, for instance. Happy to hear thoughts by email (in bio).

</comment><comment><USER132> "Can you tell me more about the problem?" before proposing a solution offers the humility lacking in the original question. Any rephrasing of the question "why don't you just X?" still leaves you in the position of being arrogant enough to assume you've come up with a better answer without learning the context, so (to borrow a phrase) why don't you just learn the context?

</comment><comment><USER133> Wow, this seems like there's a lot of insecurity going on (on both sides), if we're putting this much thought into simply asking

"Did you try sshd?"

</comment><comment><USER134> To avoid the ambiguity between the two primary intents, I always phrase the question as "I assume there was a reason you didn't [x]?" That puts any possible idiocy on my end for not immediately seeing the reason [x] wasn't done, while also giving them a chance to explain their thought process. And it also gives them credit through implication that I assume they thought of it.

</comment><comment><USER135> You see someone struggling while trying to solve a problem, and you know that –in your opinion– there's an obvious solution to that problem called [𝓍]. The thing you're after, is whether they have considered using this solution.

Just ask them:

=> "Have you considered using [𝓍]?"

Either you will learn something new (why [𝓍] is not suitable for this situation), or they will (there is [𝓍] that solves their problem).

</comment><comment><USER136> I tend to use "How come you you didn't use x?" Or even "how come X didn't/wouldn't work?", and let my body language and facial expression indicate genuine curiosity,and maybe even perplexion at the scope of problem. I don't feel Author considered the non verbal ways of communicating intent.

"How come" feels slightly lest antagonistic then simple "why" but that may well be regional differences

<comment><USER137> "How come" and just "why" coupled with fairly direct phrasing are a lot better than most of the rest of the suggestions elsewhere in the thread as of this posting, most of which seem highly passive-aggressive.

</comment></comment><comment><USER138> I don't think the answer lies in phrasing; the best approach I've found is to say little and ask questions _around_ it.

</comment><comment><USER139> I try to approach every technical conversation using an Assumption of Competence approach. This means I assume (a) the person you are speaking with has a greater domain knowledge than you,(b)knew what they were doing when they did it, and (c) applied that knowledge successfully.

I then ask questions accordingly. For example, "What would happen if we used sshd here?"

</comment><comment><USER140> Initially, I thought this was going to be a post about an internal dialogue leading the OP to a more straightforward solution than they might have moved towards. A way to K.I.S.S.

The lesson of _that_ article would be to pretend a coworker was to ask "Why didn't you just ___?" and fill in the blank on your own. Repeat as needed.

</comment><comment><USER141> I would just say "why can't you just use xxx". If they are moderately competent, they will instantly say "xxx doesn't work for this because the abc can't be compiled on this hardware", they'll have thought of it too, because it's probably not just obvious for you, and now they have helped you get up to speed on this complex problem.

I don't think you can use magic phrases, or avoid magic phrases, to manipulate people into feeling one way or another about you. You aren't insulting them by asking obvious questions, you need to hear the answer. If it took them 2 weeks to get stuck and ask for help, it's going to take you at least a few days to figure out why this is actually a harder problem than it seems. Avoiding the 'obvious question' because you think your colleague is too fragile to answer it and think nothing more of it is far more condescending.

What if they didn't think of it? Either they are very inexperienced, so they shouldn't be insulted by an expert providing expertise, or they are experienced and will slap themselves on the head and laugh about it, or they are an intolerable jerk, and who cares what jerks think of you?

<comment> r-w > who cares what jerks think of you?

I do, as their coworker who has to put up with them!

</comment></comment><comment><USER142> Replacing 'why' with 'how come' turns a seemingly judgmental question into a curious one.

I prefer to ask what they've already tried so far, though, instead of jumping to an immediate diagnosis. At least then your 'how come' question can point to a novel solution they may not have considered. Because you know what they already have tried.

<comment><USER125> They read like synonyms to me.

</comment></comment><comment><USER143> Ask "what have you tried already?"

If their answer doesn't include sshd, give them the benefit of the doubt anyway and ask "what happened when you tried sshd?"

To avoid any likelihood of sounding like a jerk, phrase your inquiry in a manner that makes it clear you assume the other person is as smart as you.

</comment><comment><USER144> "what happened when you tried sshd?"/"what went wrong when you tried sshd?"

<comment><USER145> This, but present tense, is my favorite. "What happens when you try x?" If they haven't tried it, they can say, "hmm, I don't know. Let's see." If they have, they can say, "it errors out" or "it sorta works but..." or whatever. In my experience it comes across as curiosity rather than judgement.

</comment></comment><comment> r-w Honestly, @carlmr's answer is the shortest & sweetest of them all. The most important thing is to avoid associating your idea with yourself and their implementation with themselves. As soon as that happens, you're opening yourself up to a territorial interaction.

</comment><comment><USER146> Why didn't you just make that a poll or survey?

But seriously, we all might learn how to phrase that question better if we knew which phrasing was generally preferred. I'd pick the last one myself: I probably would've tried using sshd here. Would that not work?

</comment><comment><USER147> This about the non verbal communications of tone and gesture.

No amount of rewording will substitute for a smile.

<comment> r-w Not everyone knows how to use non-verbal communication, either. Hopefully most of the people discussing this get that non-verbal is Plan A; and careful re- wording is Plan B, for when Plan A falls through.

<comment><USER113> Not a chance, I reckon. My evidence is just the whole setup/scenario on the blog post, and the fact that Ctrl-F "smile" only gives one result.

</comment></comment></comment><comment><USER81> I don't agree that the original question / statement is insulting or snarky as the author seems to feel.

_Of course_ sometimes I'm going to miss something blindingly obvious; and other times I just won't know a tool exists. You will experience this too.

</comment><comment><USER148> Honestly, if they aren't asking for help formulating a solution, they also aren't asking for your suggestion to an alternative (even if you try to couch it in terms of a question). So just don't ask and you won't have the issue.

</comment><comment><USER24> Here's how I have approached it lately. Would love to know what people think:

>My mind goes towards using X to achieve this. Curious to know if it's something you've explored and how it might not be the best fit for this use- case.

</comment><comment><USER149> I ask for the design document, and scroll to "Alternatives Considered" (usually the juiciest part).

If it's not there, I'll say something like "I noticed you didn't discuss X here, what was your thought process?"

</comment><comment><USER150> My go-to here is pretty simple: "I assume X didn't work?"

This puts yourself in their shoes, imagines that they tried X and it failed and you're not sure why without having to say all this "not clever enough" stuff.

</comment><comment><USER151> "sshd may also work for that"

The trick is to turn question into a constructive suggestion.

</comment><comment><USER152> To better remove the criticism, add some honesty and objectivity...

"One of the first things I would think of, when trying to solve a problem like this, would be sshd. But, I may not understand the full scope of your problem."

</comment><comment><USER153> Avoid the whole question of why they _didn 't_ do something; that's where the criticism is coming in, and nobody actually gives the slightest shit about that answer. Just say "Did you try...?"

<comment><USER154> Nobody cares if they tried it either. Just say, "what about sshd?" or something like that.

</comment></comment><comment><USER155> "I assume X didn't work?"

This assumes the problem is more complex than it first appears, implies that you're still searching for another solution along with them. And in the unlikely case it is the right answer, you can both laugh.

</comment><comment> r-w I love how this conversation is becoming a model of itself! People proposing solutions in contrast to others, some taking their own advice and others falling into the same trap O.P. brought up in the first place!

</comment><comment><USER156> You'd think this guy works in an adult daycare center, either that or I'm an asshole. Why didn't you just ask the question and not worry about how it comes across instead of writing an article about it? :P

<comment><USER157> I'm happy somebody pays this much attention to what emotions they cause in others. Communication with humans is hard, and people get it wrong every day. The people who don't realise this are either natural born communicators, or rough to be around, in my experience. People accommodate rude colleagues but it's rarely pleasant. For the rest of us, this much introspection is what it takes to decrypt the codex.

If you find yourself thinking this article is over the top, either you're lucky, or your colleagues are not :)

<comment><USER158> Just making an observation here that I haven't seen elsewhere in the thread -- this subject is more tricky in written communication and for people who are less sensitive to body language.

If you're communicating in person and are above-average sensitive to others' reactions, you'll be very likely to immediately pick up whether your "did you try sshd?" was interpreted as criticism. Most people will react with a slight tensing or a particular a change in facial expression or body position if they interpret something as criticism. Then you can just follow up with "this wasn't meant as criticism; I'm just curious".

If no reaction, then don't say anything; your intent came through fine. And if they genuinely hadn't considered sshd and feel stupid because of that, that would be the kind of almost-inevitable interpersonal discomfort that any healthy adult would be expected to deal with in stride. If appropriate and you wanted to be unreasonably sensitive, you could soothe the situation with "I'm not familiar with the details of doing this in your domain, there's of course the possibility there might be some unknown gotcha there".

Most socially sensitive people wouldn't articulate or think consciously about this when it happens in person, it's just an inherent part of the unexpectedly complex and quick back-and-forth of conversation.

Written communication is a subject in itself, many dimensions of communication are lost when there is no tone of voice or body language. I almost think people should be encouraged from childhood not to apply a tone of voice when reading written communication, or ask if they're unsure.

</comment></comment></comment><comment><USER159> Rephrasing slightly can get across almost the same suggestion with much less chance for condescension: "sshd has some features that may be useful with what you're wanting to accomplish."

<comment><USER160> To me that actually sounds _more_ condescending. The statement form suggests not only that I thought of the right way to solve your long-term problem in 5 minutes, but also that I'm confident you didn't know about it. The question form depends a lot on tone, but at least it admits that you might have considered the idea.

</comment></comment><comment><USER161> The one I often go for is: "What is the reason you're not using sshd?"

It implies that I understand there is a reason, that I don't know the reason, and that I'm ready to be surprised if indeed there is no good reason.

</comment><comment><USER162> Saying something like "Why can't you do/use X?" would be simple, direct, and assumes the person thought of it and that there is a reason that they "didn't just...".

</comment><comment><USER163> For the listener it's a good idea not to base your own sense of being or not being a blockhead on the opinions of people who don't know you past one or a bunch of ideas you contributed.

</comment><comment><USER164> I like to use "what happens when you use sshd?".

If they've tried it and there is an obvious response, that's what they'll say and there was no faux pas.

If they haven't tried it they will say so and the phrasing still holds up.

</comment><comment><USER165> "Why" is inherently accusatory and should be avoided. The question seems insulting because of "why" and "just".

Try saying "what is preventing us from us Hong sshd?". It is less accusatory and more inclusive.

</comment><comment><USER166> I'd probably go with something like "I'm not as involved with the problem domain as you are, but sshd came to mind for me. Could it be an appropriate way to go here?"

</comment><comment><USER167> I would just argue to not question why they haven't done something and rather ask 'Have you tried sshd? sounds like something you could use, but maybe i am missing something.

</comment><comment><USER168> I usually go with one of the following: "Is there a reason you didn't do X?" or "Could you use X here?" or "Have you considered using X?"

</comment><comment><USER169> I'm not sure on what context you have all these meetings but maybe one radical thought it this: you're having these issues because maybe your updates with these folks are at a very abstract level. Coming from an academic background, the reason for such an interaction would be the inability to comprehend the complexities of the problem due to the level of abstraction it's being presented at. If you lower the level of abstraction, you might have fewer such cases. Though it's doesn't entirely answer your question, it might help you with your conundrum.

</comment><comment><USER170> Can you add "why not sshd?" to the FAQ please

</comment><comment><USER171> Add another sentence. Preface with your actual reaction. The subtext can be avoided better being explicit than being clever with your wording.

<comment> r-w I mostly agree. But I think making it explicit that sshd is _your_ idea and the implementation is _their_ idea does a lot to make both parties territorial and perhaps oppositional.

I also prefer taking the altruistic approach in most cases. But it occurs to me: if the obvious solution were the best one, would there even be a problem to discuss? ;)

</comment></comment><comment><USER172> I go with "is there any reason you didn't choose X?" Or even better when the context is appropriate: "Is there any reason WE didn't choose X?"

</comment><comment><USER173> They say communication is X% non-verbal. Googling just now I got 93%. So maybe, intentionally or not, it is more than just the words used.

</comment><comment><USER174> Ask if they want feedback or to brainstorm new ideas before giving it. Don't try to bake the feedback into the question itself.

</comment><comment><USER175> "I would probably have tried using sshd for this, do you think that would have worked?" Is how I would have phrased it.

</comment><comment><USER176> > _Naïvely, I would think that sshd would work for that._

> but again I think that suggests sarcasm

That's coming from that snooty little diaeresis.

</comment><comment><USER177> 'Is there a reason for not using sshd? It seems to be a great tool for the problem you're trying to solve.'

</comment><comment><USER178> I'd add my 2-cents here, but this comments section appears to have turned into a bike-shedding/dog-pile..

</comment><comment><USER179> in philosophy we say:

"Standardly, XYZ, but if I understand you, you're saying ABC, are you not? What motivates this difference?"

Key points:

-identify that you are making an explicit formal comparison to a usual solution

-convey a charitable attempt at understanding ("the Principle of Charity"), and how far it took you

\- attempt to comprehend the problem being solved

<comment> r-w But is the contrast between what is "standard" and what is actually used? Or is it between what's been informed by practice and what's being suggested in theory?

Perhaps presenting the listener as being "out of line" with some form of expectation isn't the best way to put them at ease. In fact, ideally neither person should feel out of line in a mutual interaction like this.

<comment><USER179> Perhaps, but I don't speak for myself -- I'm describing a practice that is well understood, like rules of the road.

</comment></comment></comment><comment><USER180> Have you considered sshd?

I think this has an element of tact because asking if it has been considered means it may not have been.

</comment><comment><USER181> Is it, really, that hard? I'm not sure why the OP can't get "himself" out of the conversation.

> Did you use sshd?

Simple.

</comment><comment><USER182> "Is it possible to use something like sshd"?

"Would it also work if we used sshd"?

"Have you tried using sshd"?

</comment><comment><USER183> "Not knowing too much here, sshd comes to mind as an option. Is it worth trying out?"

</comment><comment><USER184> "You probably tried sshd, could you share what problems you ran into?"

</comment><comment><USER185> "Is there a particular reason that sshd doesn't work for this?"

</comment><comment><USER186> "I'm obviously coming at this afresh. Could using _X_ work?"

</comment><comment><USER187> 3\. Why didn't you just use sshd? Now I have to learn something new.

</comment><comment><USER188> Why don't you just ask "Have you tried using sshd"?

</comment><comment><USER189> "Have you considered using sshd in this case?"

</comment><comment><USER190> "Wait, why couldn't you use sshd?"

</comment><comment><USER191> Oh, I feel like I know this one:

"What happened when you used X?"

</comment><comment><USER192> Would _" Would sshd work?"_ work?

</comment><comment><USER193> I would have tried sshd. What's the catch?

</comment><comment><USER194> "How did you try to solve this?"

</comment><comment><USER195> "How does it compare to sshd?"

</comment><comment><USER196> "Did you consider using xxx?"

</comment><comment><USER197> "Sshd didn't work?"

</comment><comment><USER198> "Can you use sshd?"

</comment><comment><USER199> Assuming you eliminated sshd…

</comment><comment><USER200> "ssh?"

<comment> r-w i.e., "Or not?"

</comment></comment><comment><USER201> Was sshd considered?

</comment><comment><USER202> Related comic relief: [https://xkcd.com/1831/](https://xkcd.com/1831/)

</comment><comment><USER203> I'm reminded of Keep Your Identity Small[1].

As a society it seems like we're moving more and more to a model of conversation where the onus is on the speaker/writer to communicate in the most obsequious manner possible to avoid offense, while the listener/reader is allowed to interpret what is said/written as offensively as they want.

It's certainly a kind thing to ask "Could we use SSHD here?" instead of "Why didn't you just use SSHD?" But if someone says, "Why didn't you just use SSHD?" I think the person hearing that question has some responsibility to take the question at face value, and not read an insult into it.

Ultimately, the speaker/writer and listener/reader are supposed to have the same goal: to solve the problem in the best way possible. Maybe SSHD is a better solution, and if it's a better solution to use SSHD, then we should use SSHD. That's the entire point of asking the question in the first place: to try to discover if SSHD would be a better solution. But if the person hears "Why didn't you just use SSHD?" and concludes "They must think I'm an idiot", then how are they going to handle hearing "We should use SSHD instead."? I think it's reasonable to expect adults to be able to take this sort of criticism without feeling hurt or getting defensive.

Someone so married to their own work/ideas that they take polite criticism of their work/ideas as a personal attack can't be an effective member of a team, and since they'll always feel under attack for every mistake they make that gets corrected, they will be miserable to boot. This thought process doesn't represent reality: just because you used the wrong tool doesn't make you a stupid person or a bad engineer, and just because someone thinks you used the wrong tool doesn't mean they think you're a stupid person or a bad engineer. I'd go so far as to call this a mental disorder; it certainly fits the DSM IV definition[2].

Smart people and good engineers make mistakes: a big part of what makes someone smart and a good engineer is that they actively seek out people who catch their mistakes.

So sure, strive to communicate in a kind, compassionate way. But also strive to be confident enough that you can take criticism of your ideas and work without taking it as an statement about you, or your value as a person or worker.

[1] [http://www.paulgraham.com/identity.html](http://www.paulgraham.com/identity.html)

[2] [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3101504/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3101504/)

</comment><comment><USER204> My go to for this is to say "I'm guessing $solution didn't work." Because then you're supposing a solution that most likely the other person did already, and you're communicating that you'd assume they'd already thought of it, and in the odd event that they didn't, they can just say "Oh, I guess I didn't think of that."

That said, whenever I walk into a scenario where someone's been plugging away at a problem for a good length of time, especially when it's someone I trust and know to be competent, almost invariably the answer is yes, they did try it, but asking in this way often then illicit the person to explain what went wrong. And after a few rounds of it we've eliminated a number of the more obvious solutions that didn't work, and I'm now up to pace and can try and provide better ones.

</comment><comment><USER205> "You should have used ssh." In a friendly tone, of course.

If the people you work with are triggered by this and don't push back in an equally friendly tone - you have bigger problems than linguistic ones.

</comment><comment><USER206> "I banged my head on the same issue before for weeks/ months/ years and ended up using sshd".</comment>