Help me ask why you didn't just | Hacker News Reader

Help me ask why you didn't just

blog.plover.com

315 pointspsanford343 comments

Open articleView on HN

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.

Favoriting your comment here. You just gave 2 "learn within 1 minute social skills" lessons within one HN comment.

There's a lot to unpack here.

1. Your way of analyzing on how it could be less threatening

2. The final answer to it being less threatening

3. Praise in public, criticize in private

I'm normally not a fan of simple sentences, but the sentence of (3) is one I'll keep in mind when I'll start my career.

Thanks!

I find that 3 can become a mental down spiral for the carer.

Praise anywhere, criticise anyware, make sure to do it sometimes in public. Otherwise, it becomes a game of fools, which at scale may lead us all to insanity.

Care to elaborate? I don't understand why it's a "game of fools" or how it would lead to insanity.

Honest question.

What I observed among groups where public criticism is discouraged:

- Pressure on the good actors to communicate using the protocol. Basically being positive at all costs. It creates depression as feelings are constantly suppressed. - No pressure on the bad actors to correct their behaviour. Unless someone with the necessary authority notices the issue and had interests in taking the required action.

A game of fools, because, if a team is mostly made of good actors, then the frustration is tolerable, and perhaps the bad actors can be raised to the level of "good". There is a tipping point though, I've observed, where if the ratio of bad actors gets high, there is less and less of a incentive to do the right thing. Since criticism must be kept to none, or made in private, it becomes a battle of alliances. Things are said quietly. People end up spending more energy in sculpting a great image, rather than becoming better.

It's a game of fools. Fool participants, it's even contagious.

It also somewhat serves management as they only are to then decide how to compensate, promote, lay off every individual without risking any questioning from the contributors (everyone is equal by the sound of things, really)

When I say good and bad actors, I don't mean a category of people is bad while another is good. It's not about the intent, but about skills, performance, agile abilities, knowledge and wisdom.

It's important to have some tact, and respect. But I don't see anything wrong in calling out someone on poor execution. He may learn from it. And so what if it is made in public. Perhaps everyone needs to know. Again, tact and respect, it is not incompatible.

    Praise in public, criticize in private

In my (considerable) experience of working in large organisation (private and public), whether this works or not depends strongly on the power differential between praiser/criticiser and praisee/criticisee. Basically this is the most likely outcome:

- Powerless praises publicly and criticises privately: criticism will be ignored, praise will be milked.

- Powerless praises privately and criticises publicly: if played right, this is working, since the powerful cannot brush aside the criticism, but this is likely to lead to retaliation!

A way of making public criticism more digestible is to make it very constructive: "You are wrong because XYZ, I recommend ABC instead because <reasons>". Ideally the <reasons> align with the organisation's goals, e.g. "ABC is clearly in the interest of our shareholders / voters / students / environment because <other reasons>.

Make of this what you will.

I agree with you. However I'd say leading with, "You are wrong" is risky. Unless you have a very good working relationship with them, always start with empithy and praise. "I think this will really work well for our clients. How do you handle 'reason they're wrong'?"

Obviously, do what the situation calls for, but I pissed many people off, without being wrong, telling them they are. I found really looking at it from their point of view first helps. Usually they're trying to solve a real problem, so at least take the time to understand it and how they see it.

The phrase "you are wrong" is one of the fastest ways to get someone's back up against the wall. In your example, completely removing that phrase doesn't change the meaning and it eliminates negativity.

I completely agree with you.

That's why publicly saying "you are wrong" is so powerful (and so dangerous). The powerful are not used to be challenged in public. They typically respond by a combination of

- reframing, changing the subject

- attacking, belittling you

You can see this in action in stand-up comedy with hecklers. If you anticipate this reaction, you can turn this around very effectively in a professional context (not in standup-comedy though): "I note you are NOT answering my question, instead ...".

With great power comes great responsibility.

> I note you are NOT answering my question

This seems unnecessarily belligerent.

I always prefer X is wrong to You are wrong about X. Separate the error from the identity.

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.

Is "Why don't you just use sshd?" actually objectively more useful than "Would there be any tradeoffs using sshd here?"

Both of those comments are actually not great, but at least the first one has the benefit of being direct. Really the question you’re asking is something like ‘you’re deviating from an established design pattern here, why?’. It’s essential to communicate that you either don’t understand a decisions they’ve made, or that you have some particular reason to question a decision they’ve made. Beating around the bush dilutes that message, will usually just end up wasting time, and will often seem condescending. If your team can’t deal with good faith criticism in peer review, then you have a problem with your team culture, not a problem with improperly concealed criticism.

But questions like this can be used to better understand the engineering decision. There have been plenty of times when questions like this have saved me typing out a long, critical response because there was something I didn't understand, and most of the other times it helps me better frame my response or change my criticism entirely.

Thank you, I appreciate your take on this. I personally also like to learn from criticism, but it took me a long time to be able to accept it better. I try to get to know the other developers first to get a feeling for whether or not they're used to accepting criticism. If the other person becomes defensive I try to be more careful, if they seem more accepting I will continue being critical.

Usually I would be more openly critical if someone is more experienced.

Learning to accept criticism isnt easy. I've found one way, at least for me, is to be self-critical. I'm usually harder on myself than my peers. Makes it a bit easier to accept when someone else points out a flaw.

I think it’s something you can develop as a team. One of the best teams I’ve ever worked on took blameless post-mortems very seriously. If a decision you made lead to an incident, then you had to attend a PM, explain what you did, and why you did it. Most people got pretty stressed about their first PM, but would pretty soon come to realise that they were actually quite positive experiences. The team knew that failure was something that was completely unavoidable. You can continuously improve the resilience of your systems, but you will still have failures every so often. As such it’s not ‘your fault’ when you cause a failure, it’s just something that happens, and the only thing we can do about it is learn from it. People would figure out pretty quickly that everybody on the team wanted everybody else on the team to succeed, and that that’s what motivated all critical discussion. This team had succeeded in building a trust that everybody had everybody else’s best interests in mind, and because of that criticism was given openly and without creating conflict or feelings of judgement.

That said, I’ve also learned a lot from giving misguided criticism on PRs. I’d point out something I thought was wrong and the author would come back to me and point out some misunderstanding I had. This sort of work environment is one that naturally maximises personal development, and eliminates a lot of the anxiety people have about making mistakes at work. It takes a lot of continuous effort, but imo developing that sort of culture is far more valuable in the long run than developing social conventions around sugar coating criticism.

I'm aware of an unofficial convention in some US government departments - if 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".

I want this to be true

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

I like this - so this is a real thing?

Totally agreed. I think one important aspect of your suggestion is that it avoids creating a territorial interaction: no association is made between the speakers and their respective ideas. Each is free to consider one idea or the other, without feeling like they have to identify with & defend “their idea”.

IMHO the critique isn't the issue - that's after all the point of the process - it's the hidden reasoning and sounding like an examiner or quizmaster.

Are you testing whether I know if SSH could be good, or are you honestly asking if I made a decision not to for a reason I can help you understand?

Assuming we're on the same side (which isn't 'let's quiz each other to teach other') I'd rather receive something like:

> As I understand it flibbitd could be used here with similar properties as widgetd, but faster foo since it drops legacy bar support (that we don't use). Normally we avoid it as it's less common, but since we're bundling whichever one here I think we can safely use it - unless there's another reason not to that I've missed?

The article is trying to ask "assuming I don't know better than the developer, and SSHD genuinely wasn't the right fit, how can I enquire about the reasons without seeming critical?"

Your comment comes across as the opposite; "without knowing or caring about the reasons, how can I communicate that I know better and that SSHD should have been used - but dodge looking smug by asking it opaquely?"

> Why was sshd not used here? - demanding and aggressive phrasing.

> Could sshd be used here? - "Yes. Anything could be used anywhere. If you have a point to go with that bikeshedding, please make it"

> Would there be any tradeoffs using sshd here? - "Of course there would be. Moving on.."

To be frank, those hypothetical answers seem very hostile and I wouldn't want to work in an environment where communication works this way.

Instead of saying "of course there would be" there could be a bit of a deeper discussion and the two people could figure out the best solution together. It's always supposed to be people against a problem, not people against people.

Yeah, all of their answers show that they never intended to take any advice.

If they were a junior developer here, they wouldn't make it to 3 months. If they were a mid-level developer, they'd get talked to about their attitude, and if they continued to be hostile, I'm pretty sure they'd be let go. It'd be a harder decision if they were passively hostile instead of overtly, actively hostile like those comments, but I think it'd show clearly enough anyhow.

The company here cares so much about the culture that my morning "standups" actually turned into hour-long random discussions daily, and management would walk by and say nothing, unless there was an emergency happening. (Thankfully seldom.) When one of us went remote, that turned into a video chat and they even wanted to schedule a second one in the afternoon, but we were all against it.

Toxic answers like the ones above could ruin that culture from someone with tenure, and we'd never let a novice with that attitude get far enough to affect things.

As for myself, I'm not as soft as the original questions, but I do soften my critiques. I'm honest about what I'm thinking about their code, and give my thoughts as to how it could be improved. When I think it won't actually cause a bug, I let them decide whether to take my advice or not, and most of the time they don't rewrite the code. (And often later find out that it was a mistake, but that might be years later.) Or it might not be a mistake. :D

I wouldn't reply in that way in a workplace, they're exaggerated to illustrate the trolling nature of the questions. Picking arbitrary things and demanding that someone explain them to you is what narcissistic parents and horrible film drill sergeants do - what they are doing is power-tripping and keeping you uncomfortable.

It looks polite because they aren't using swear words, but you can tell there's something up when the original commenters wants to go and give this advice "in private" "for your own good". That's not right. Private is for "your work is all over the place and you are distracted, is there anything I can help with?". It's not for "SSHD handles login failures much more sanely than BLUB". There's nothing about that which needs to be critical or secretive.

Giving well-meaning advice would be something like "Many times when I brought in new tools turned to regret when other people had to deal with them during outages, and when I see BLUB used instead of SSHD it makes me nervous. All N people will have to take time to learn it to integrate it properly with the team, so I strongly recommend unexciting and familiar tools by default; but individual situations are unique and I don't know BLUB well - what is its strength, and does it add enough that we might consider moving everything to it?"

That is - advise what to do ("use unexciting tools"), explain why (backstory with consequences of not following advice in the past), explain who it affects (coworkers in stressful times), share less-obvious concerns (cost of everyone having to learn it), and be open to new information (maybe their plan can add a lot of value).

> and we'd never let a novice with that attitude get far enough to affect things.

A child would never have the power to talk back to power-tripping adult, but an equal adult would. "I want to stop you and interrogate you about some random thing I've noticed without explaining why I want to do that", "Well you can't, I'm busy. Stop power playing and trying to imply you know things and making me beg for them; if you have advice which improves the product, give that advice to everyone."

Did you (try|consider) sshd?

"Yes, it wasn't suitable because..."

"No?" Ah ok, I think it'd work really well here because...

Direct, no assumptions, no trick questions, no toes trodden on.

The directness here is important. If you start playing word games to imply things (non-threatening, non-accusative) etc., you confuse the message. You know what's worse than a threatening or accusative question? One where the recipient spends their time trying to guess what second meaning might be implied with the obviously convoluted wording. Clear, direct questions that have only one distinct query.

>> Would there be any tradeoffs using sshd here?

Some might focus on the tradeoffs as the primary query, but others might assume that the real intent is press for an alternative to sshd. It sounds like you know something, but didn't want to say it, and now you want me to infer it from your question.

Some people might be offended or sensitive to direct questions, but that's for them to work through with their therapist.

> Some people might be offended or sensitive to direct questions, but that's for them to work through with their therapist.

It's a fair position to take, but in some cases where successful communication is a necessity, that stance doesn't cut it.

My go-to heuristic is "the wordier the question, the more likely it is to be perceived as well intentioned."

So if I'm wondering why someone didn't use sshd, I might say, "So I'm wondering if you considered using sshd for this? You probably did, I'm mostly curious about how you think it fits into things."

Wordiness works in my favor in two ways. One, the extra words help me to be precise in my _intent_ behind what I'm saying. Fewer words may, in some cases, technically be more precise, but have a tendency to leave the other person considering whether their initial interpretation is really the correct one or if there is some other implication to the words they're not seeing. Using more words cuts down on that effect quite a bit. It narrows the search space, so to speak.

The second way is that because I'm presumably actually speaking the question, it allows me to closely shape my intonation to be as neutral as possible. I say neutral rather than non-threatening, because non-threatening makes me think of how one speaks to a child, which is definitely not what you want when speaking to a colleague. And of course, you don't want to sound like you're coming from a position of superiority either. I like to think of it as an adventure between me and the listener to solve the puzzle. That takes the focus off some implied power struggle between me and them and instead frames things as the listener and I teamed up to slay the puzzle-dragon.

Number two doesn't apply if you're communicating through text, which is why it's important for those who communicate through text very often to have a tendency of always assuming the best intentions of a given piece of communication until proven otherwise, or by intentionally asking for clarification when necessary.

I was born when my dad was about 41 years old. The significant generational gap between us caused some difficulty in the way we communicated with one another and so I was forced to adapt my approach to communicating with him as I grew up. Now that I'm older, I find that I'm exceptionally good at communicating with other people where cultural differences between the communicators might otherwise result in issues for someone without the same type of "training" as me.

The downside is my written communication tends to be annoyingly wordy. Ironically, my high school English teacher didn't like me very much.

EDIT:

And knowing your audience is important too, of course. The direct, "Did you consider using sshd for this?" would be fine if I were talking to a senior dev, or someone I know is unlikely to take offense to a direct question. Actually, in the particular case of a senior dev, I'd probably reword it to be, "Why didn't you use sshd here? I would've thought it would be useful because of x, y, and z." This frames it as me asking for guidance from the master. I like to bring the wordiness technique in for cases where I know the listener has a tendency to take things the wrong way. Definitely not to be used all the time or else you get a reputation for being a wordy speaker.

> My go-to heuristic is "the wordier the question, the more likely it is to be perceived as well intentioned."

Just wanted you to know that I have a conflicting heuristic (which admittedly may or may not be unique to me): "the wordier the question, the more likely it is that the intention is being hidden from me".

Inefficient, wishy-washy, wandering questions set off my spidey sense that tells me I'm not getting the full picture. Earlier in my career, such an interaction would have left me with some risidual anxiety, feeling unsure that I'd been given honest feedback and questioning whether I'd done a good job.

I'm speaking only from the point of view of a review situation of course.

At the end of the day, if I need something from someone, I'll contort my discourse in any way necessary to achieve the end I need. Even if it means tip-toeing around someone who's extra sensitive. I'm not out to make my life harder. And to be clear, when I say "direct" I'm implying neutrality. I'm not talking about direct, yet antagonistic, questioning (which I'd argue is less direct than neutral questioning).

In person communication is less of an issue because you can use things like body language and tone to take the edge off.

However I've found through experience that the more words you add, the number of possible interpretations increases, and the likelihood you get a relevant answer decreases. Back to the example at hand, maybe it would make sense to chain two distinct queries together: Did you try sshd? If so, what was the result?

It's my belief that in written communication, clarity of purpose is king.

> My go-to heuristic is "the wordier the question, the more likely it is to be perceived as well intentioned."

Are you familiar with "How To Make Friends And Influence People"? It trades on exactly this idea.

Specifically, it trades on this idea to both seem well-intentioned and manipulate people. It uses this presumption of good intentions to cover the true intentions. It buries everything meaningful under an endless sea of noisome, excessive verbiage to lull the reader to distraction and smuggle its actual point past the listener.

Wordiness is what you do when you're worried about slipping something past someone's defenses, for fear of being unable to have the required conversation otherwise.

Maybe a little embarrassingly, but I've tried to read it a couple of times and usually bailed around chapter 3 or so due to boredom.

I think I know the type of wordiness you're referring to and my term for the type of person that uses that technique is a "snake". The kind of unconscionable person that, like a magician, draws the audience's focus to one point while enacting their trick with the other hand.

I had a particular person in mind when I wrote my other comment. It was a guy I used to work with who initially didn't like me despite my very team-oriented spirit. I think he thought I was a snake.

Eventually our boss noticed our inability to collaborate and forced us two, along with a more senior team member to brainstorm a solution to a particular problem afflicting the project that day.

I have a tendency to relentlessly refine on a solution or quickly reject solutions I don't see as tenable. Sometimes when someone first meets me, they get the impression that I "shoot down" their ideas because of some desire to appear superior.

I do sometimes shoot down ideas but only because I am an umcompromisably honest person, at least with respect to work, which I take seriously. Which isn't to say I'm Dwight Schrute and I go out of my way to shoot other people's ideas down. I just won't lie and say I like something if I don't. I also am aware of this aspect of my personality and go to lengths to suppress it for the sake of those around me. But it is who I am at the end of the day, and I don't intend to change that.

Anyway, at first the guy wanted to butt heads with me, but I did my best to project a patient and collaborative vibe and the senior member encouraged the dude to look at my ideas in a more removed fashion rather than in an emotional way and my teammate eventually came around and began working with me.

That coworker and I went on to become, if not friends, solid collaborators for over a year after that until the point at which I left the company.

I think some people have an initial dislike for overly straightforward people like me, but most usually come around to it and even appreciate it eventually. You don't have to worry about me double crossing you. I'm predictable.

The rest who don't can pound sand as far as I'm concerned.

I've actually read this book no fewer than three times. I disagree that it trades on excessive verbiage. I think people were far more eloquent when the book was written and the excessive verbiage is an artifact of that. The book's real value stems from it's ideas around expressing honest interest in other people and making proposals in terms of other peoples needs, for example.

Actually, the unfavorable assumption here is that the interviewee did not consider easy solution sshd.

I've taken this a step further and often completely flip the wording to match the intended assumption which is that I am wrong:

> I can't figure out the reason X doesn't work

This is more often what I really mean, i.e there is some obvious solution (to me at least), but it's too obvious that they have likely already considered it and there is an issue with it... but they have been working on the problem longer than me - so tell me. Occasionally the solution is obscure enough or slightly unfamiliar to them that it slipped their mind - in which case it's an "oh of course" moment, which also causes no hurt feelings since you aren't trying to rub it in.

The article mentions the problems with those:

> I'm not clever enough to understand why you didn't use sshd. It would take a fucking genius to figure that out.

"I can't figure out" != "I'm not clever enough"

I think saying "i'm not clever enough" (one of the options presented in the article) was never a realistic option given the premise of the article, which is: "a problem somebody’s been working on for a week or a month or maybe years". In this context it's also the least likely interpretation of any other question unless you are a telepath, the limitations on the time you've spent thinking about it are implicit, it does not mean you are incapable of figuring it out...

The other person has been working on this significantly longer than you, this is the reason you can't quickly deduce everything they know. The whole point of this type of questioning is to try and extract some of the results of work the other person has already achieved, for the purpose of better understanding the problem, guide further enquiry and possibly allow you to make useful suggestions.

The difference, and the problem, is the word "clever." If you leave it out, and just plainly state "I can't figure out why x doesn't work," it's less likely to be misunderstood, and it's an accurate representation of your current mental state.

That just sounds passive aggressive to me. At the end of the day, I think it’s best to say what you mean directly, but still in the nicest way possible instead of trying to beat around the bush.

I’d go with “I think X might work better here - is there a reason you didn’t use it?” - because the answer might just be “oh, I didn’t think of that, cool, I’ll do it that way”. Whereas your question implies that they should have thought of it, which could be perceived as an underhanded insult if they didn’t.

In a communication course my employer asked me to take a while back we were taught to a) never ask a yes-no question and b) never ask "why". So I would reformulate simply as

"How would sshd function in this setting?"

I have no idea how I'd answer that question without just ignoring it and treating it like a "why" question instead. I'm trying to apply this to a few technical decisions I've made someone might ask me about.

"I made a game on the web!" "How would your game work as a native app?"

"I made a thing that syncs files!" "How would you build this with Git?"

The two word answer I'm always going to be tempted to give is just: "I/It wouldn't."

To me, this is no longer asking the reasons why I made a technical decision, it's asking me to consider an alternate reality where I didn't make that decision, and to try and suss out what that reality might look like. And my purely instinctive, gut reaction to that is, "why are you wasting my time asking about things I didn't build, ask me about the thing I built or go away. It's not my job to re-architecture and reconsider all of my things under your random restrictions."

If a boss asked me a question like that: "How would Postgress work in this setting", I would politely reformat their question in my head, but unless I knew them quite well I would be quietly annoyed. But when someone asks me a direct "why" question, I feel like they're being more respectful, and I feel free to give a range of answers:

- "Why wouldn't your game work as a native app?" "It has some complicated tradeoffs that would take too long to enumerate."

- "Why not use Git?" "It has some specific tradeoffs, that I can go into more detail about: X, Y, and Z."

- or even, "Why not use Rust?" "I'm just not familiar with that technology, so I used something I already knew."

I'm not disputing that there are probably people who have different reactions. But I am immediately skeptical of any rule that uses the word "never". People just aren't that uniform.

I disagree with your communication course. In technical discussions, asking "why?" is one of the most important things you can do. You are ignorant. The person you are speaking to is not, and they are teaching you. But in order to teach you, they need to know what you don't know. Asking "why?" tells them what to explain.

I agree with danShumway's take: if I received your question, I would furrow my brow, pause for a moment trying to understand what the real question is, then probably plainly state: "It doesn't. Why are you asking?" Then you would explain that it seems to you like it would solve the problem, and I would explain why it doesn't.

The further I get down your list of alternative phrasings, the worse the writing gets.

This is corporate speak and it's regrettably taking over the world.

I do agree with your final paragraph. Telling people privately sidesteps all the newspeak entirely.

What is distasteful in corporate speak is its use of inflated words to hide the lack of honesty and humanity.

What the GP points out is intentional phrasing to express no more and no less than what is desired. That it happens to sound formulaic is less of an issue than conveying the wrong meaning.

When you use passive voice, you are obscuring who performed the action.

This is one of the hallmarks of corporate speak ("Mistakes were made.") It is bloodless and takes the people out of the picture. Business is a human activity.

There are other more human ways to express the same message ("You might not have thought of it, but ssh might be a good option here." or "Maybe there's a reason it wouldn't work, but perhaps ssh might be easier?")

Language shouldn't become the victim of our distorted corporate culture. We can speak plainly and still be respectful.

I usually go with something along the lines of: "I assume you tried sshd and it didn't work?"

IE, I am assuming that you are not an idiot and that you tried the obvious thing and that it didn't work for some reason that I don't understand yet.

Whenever I write the word "just" in this context, I go back to see if the sentence can work (and be more-positive) without it. Most of the time, it can.

Somehow, it is helpful to write the "just" in order to get the sentence out, but it appears to be a temporary crutch to get the idea on paper. It is in the same category as, "it should be noted that" for me -- temporary scaffolding to get an idea on paper that can be later removed.

Could we use sshd in the future?

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...)

I like this a lot. I often phrase this question as "can you tell me about the trade offs of your method vs. something that uses sshd?"

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.

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...'

Yes or "Is there a reason we don't use sshd here?"

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.

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

I agree. Especially face to face worrying about this kind of thing seems unhealthy.

However, I can see that in text conversations the chance for misunderstanding can be much higher.

I agree with you, but I think this applies only in high trust environment. In my experience one toxic, condescending person can destroy the trust of an entire team and start making people take things the wrong way. Maybe in such situations, after getting rid of the toxic element, temporarily paying more attention to the language used would help regain the trust between all team members.

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

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.

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.

It's such a fine line to walk between discussing an issue about work, and directly insulting a human being. And so very often, the receiver interprets the message entirely differently than the sender.

So I'd say regardless of how powerful you feel, personally, the same fortitude should not be assumed to exist in everybody, all the time. It's not about the strength of a person, but about avoiding harm wherever possible.

Harming people, whether intentionally or not, is just never worthwhile. If that means "silk gloves" and "weakness", so be it.

That fine line is entirely a cultural construct though. I feel like my culture is much more inclined to assume anyone talking to them at work has good intentions. Seems like a better strategy from a game-theory perspective as well (tit for tat).

So when others treat you in ways that you don't like (or you misinterpret their meaning) it annoys you. Sounds like you are supporting the idea of the article, albeit from a contradictory starting point.

It would annoy me yes if my genuine interest would be mistake for condescension because I choose my words wrong. This makes for a very unwelcoming culture.

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.

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.

"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.

> "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.

Yep this is what I say too. The easiest way to prevent this kind of thing, and a large class of similar reactions, is to cast yourself as the 'incompetent nitwit' and speak accordingly.

As a bonus, in the cases where you are the nitwit (often in my case) it saves your teammate from having to do the awkward dance of the inverted problem of the OP: pointing out you are in fact, wrong, without it being taken harshly. If you already tee it up that you are probably incorrect, they can just run with your assumption in the common case where it's a correct assumption :)

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

I'm actually quite surprised that you're the first person I've seen mention this, because in my personal experience this is exactly the answer. People seem to receive that question well regardless of it's form when it comes from someone that is known to be relatively open and non-judgemental.

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.

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

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.

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.

hjorthjort, exactly my thinking.

Another one:

"I was wondering if `sshd` would work here. What do you think?"

If you're supervising a junior it can be an idea to discuss potential solutions before they implement them.

If you get to "Why didn't you just...?" not only have you questioned their competence, but you've also undermined your own competence by allowing them to proceed with work they didn't need to do and/or may have to redo.

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.

Here's the suggestion: don't ask!

This is bad advice and I hope nobody takes it. We learn from each other. I've very glad I didn't have to learn everything I know first-hand.

Personally I am honored when people think highly enough of me to feel like they can learn from my experience. I also like learning new things, so if there was some obvious answer that I just missed of course I want to know about it!

The correct answer is first form a relationship, then ask. The author worries:

I have realized I honestly don't know how to express my question to make clear that I mean #2, without including a ridiculously long and pleading disclaimer before what should be a short question.

It's perfectly ok to have that long preface the first time you ask this kind of question. "Sorry to be long-winded, but since we don't know each other that well yet I just want to be clear: I don't understand why you didn't choose XYZ? I'm interested in learning about this but I haven't spent as much time on it as you have. I would have tried XYZ but I'm assuming there was some issue. What was the issue?"

In general over time people will learn your character and your intention. If you are truly humble and trying to learn they will come to expect that attitude of humility from you and the long preamble won't be necessary.

In situations where you don't have the opportunity to build a continuing relationship just accept that the verbosity of your question is the price of clear communication without the context of an existing relationship.

But please, please keep asking questions, even if they seem obvious. That's how we grow.

I'm not saying "don't ask questions." I'm saying "Don't ask that specific question that specific way. Get the same information by asking about the problem that's trying to be solved for long enough that you come to the same conclusion that they did that an off the shelf solution doesn't work. And if that never happens and you're never led to believe that an off the shelf solution was inadequate, then just say so."

That sounds like a colossal waste of time when you could learn just as much by asking that specific question.

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.

You're right to mention context. In my own experience, when stating something that can be interpreted in multiple ways, whether it is interpreted good or bad by someone depends on what they believe the context of the statement is. It's my job to provide the correct context. Adding a disclaimer is one way to try to fix this, but I think for many people you need to provide context in your typical interactions with that person. The disclaimer is probably a good idea if who you are speaking with is unfamiliar with you, as there's not much context built up yet.

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?

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)

> Here's the suggestion: don't ask!

In addition to my learning (and other reviewers too embarrassed to ask a question they might be wrong about), I can't count the times I've asked a simple probing question about X and gotten a short response that includes "thinking about it more I realized that X is correct but I completely screwed up Y!"

"Don't patronize someone by saying..." I'm sorry but a company where people confuse genuine curiosity into your work and chosen solutions with patronizing would feel so toxic to me that I would leave very soon. Don't be a snowflake, just answer the question honestly. Maybe you should have used sshd and you should stop wasting time doing what your are doing right now. Or maybe sshd doesn't cut it and the person asking you why you didn't use it is going to learn something new. Fear of patronizing is inhibiting honest open communication.

> Either understand why the first thing that popped into your head doesn't work without having them tell you why that's the case

I actually like that phrasing. Some thing simple and open-ended, like

"Well, the first thing that comes to my mind is sshd."

And let them talk.

It's generally a true statement, in that it is the first thing that comes to mind, with all the naivete that this implies. And IMHO doesn't unduly pressure the person who has worked with the problem longer.

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!

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.

Just as you're accepting that you don't know everything and would welcome input, so that you could grow since your technical career is not static, so too are people not static, and should welcome input on better ways of communicating & the ramifications of their communication choices, so that they can become more effective in their own lives. It's actually a pretty sweet deal if you ask me, full of betterment on both ends of things, even if it exposes some less-than-fun feelings in the process.

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

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

This reads like anyone asking a question with an obvious (to you) answer is automatically branded as "intellectually lazy", instead of simply ignorant or genuinely curious. Is it better for outsiders/juniors to study "the problem space" in their own silos before questioning the experts, lest they cause offense? Sounds toxic to me.

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)

"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.

Right - almost all of the examples from the website use “you.”

"How about sshd?"

"Have you tried sshd?"

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.

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.

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.

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

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.

This is a really important aspect. It's not necessarily the critique by itself.

It's about one being confronted with the possibility that some other unforseen solution could have saved days, weeks, or months of work (or even perhaps longer!) and the foolishness or incompetence that one might feel at not having realized this.

If there is a meaningful chance the alternative solution would have been better, and a significant amount of effort invested into the harder approach, it can be a very tough pill to swallow. The ego might reflexively jump in to defend the path that was taken. It may be difficult to have a productive conversation.

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.

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

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).

But you're missing half of the value of the interaction.

Generally when I'm asking this question, it's not because I have any expectation that they should have used sshd, it's because I want to understand the design tradeoffs that led to building X alternative. It's a learning exercise for me.

If I'm chatting to the Nobel Prize winner in not using sshd, I want to learn something from them, but if I'm not careful I come across as sounding like I disagree with them (I personally tend towards the 'three sentences of pre-amble' approach).

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.

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.

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.

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.

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.

I get you... I spent so long hearing “why dont you just [incredibly useless and patronising suggestion based on manager’s knowledge of the code/industry as it was 10 years ago]”, it drove me insane. “Why don’t you just” is ok if someone’s been stuck on something for, say, a day. Weeks or months? You’re definitely missing something that makes the task so hard, and you will infuriate the developer by approaching it as if you know best.

"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.

Hmm, using "you/your" and asking them to explain their actions actually comes off as accusatory to me.

Compare that to "Why doesn't sshd work here?" (mentioned elsewhere in the comments), which seems more focused on education.

Alternatively: “For what reason did you not choose...”

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.

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.

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.

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.

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

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.

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.

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.

Yes, and they will also move the goal posts when you explain why their solution doesn't work.

I feel there is something missing in this whole discussion and that's the question of unsolicited advice. I don't think anyone will feel insulted if the j-word comes out after they have asked for help on a problem.

On the other hand, It's hard not to feel like that question is condescending when it is unsolicited.

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.

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)

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.

I think the article directly addressed that "most people" are reasonable, but a minority are not and will take the question as an insult. It's trying to work out a way of phrasing the question so it can't be taken as an insult, even by an unreasonable person.

But what if the person actually is a moron or -- maybe more likely -- just really insecure. Just because a person is a moron doesn't make it right to treat them badly.

But yes, I really agree with your comment: This is not usually an issue if you have a well developed relationship to that person. But if the context is still undecided, that's when the phrasing can really decide which way your relationship is going.

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"?

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.

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.

"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.

Unfortunately, if "xyz" is one of the approaches they did already try/dismiss, it still comes across as patronising.

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!"

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.

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.

"assume good intent" is a good rule of thumb, but there are ways the author of the code review can also communicate in a way that's inviting a constructive conversation, rather than potentially leading the author of the code to have to "defend" their position.

"Can you walk me through what you've tried so far?"

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

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.

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.

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.

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.

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.

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.

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).

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.

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.

Totally agree. Words only make up part of communication. There are >300 comments on this thread because everyone has their own way of saying this phrase based on how they would be received if they said it at their workplace.

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.

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.)

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

this exactly.

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?

"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.

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?"

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.

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.

"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."

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.

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

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.

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.

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

"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.

“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?

It's explained in the post.

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?

That was the joke.

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?

He mentions that there are complaints about even that approach.

Where does he mention that? I don't see it.

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.

Yes!

I mean just ask whether they tried it.

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

if - from the start - either:

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

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.

"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?"

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.

"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.

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.

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".

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

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 - you 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.

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.

"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.

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.

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.

"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.

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)

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.

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.

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.

"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.

Why give anyone the opportunity to wave away your ideas? :) I don’t think the other person should be respected at your own expense.

I mean "wave away" in the context of "Yes, I already tried that."

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.

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.

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.

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.

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.

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".

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?”

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.

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.

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.

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.

"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.

“This looks like a situation where I’ve used ‘sshd’ - but I might be missing the big picture here.”

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.

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?

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?

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?

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.

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

“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.

Or maybe just “what was wrong with existing tools?”

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...."

"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.

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.

Your answer seems to suffer from the other alternatives. Still reads with an air of condescension.

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"

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.

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?

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.

"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.

"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.

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.

“Did you consider using `sshd`? Why didn’t it work for you?”

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

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

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.

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).

"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?

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?"

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.

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).

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

"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.

I don't think the answer lies in phrasing; the best approach I've found is to say little and ask questions around it.

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?"

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.

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?

> who cares what jerks think of you?

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

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.

They read like synonyms to me.

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.

"what happened when you tried sshd?"/"what went wrong when you tried sshd?"

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.

This is the other side of a bad coin: "why didn't you" assumes they didn't. Just asking if they did will automatically include asking why they didn't and what went wrong when they did, whatever the case may be, and without the tone of either of those.

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.

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?

This about the non verbal communications of tone and gesture.

No amount of rewording will substitute for a smile.

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.

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.

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.

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.

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.

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?"

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.

"sshd may also work for that"

The trick is to turn question into a constructive suggestion.

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."

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...?"

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

“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.

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!

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

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 :)

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.

I think words matter, because they convey an underlying attitude toward a person's work, and that attitude matters.

Consider an extreme: "You're an idiot, any competent person would have done X".

Obviously that would be rude, disrespectful, and arrogant. Nobody would say that, but it suggests there is a continuum of responses from "I do not respect your work at all" to "I respect your work but think you might have overlooked something". There's a line somewhere on that continuum (which is going to vary by person) that separates useful input from arrogant drive-by criticism.

If I want my suggestions to be taken seriously, I should take care that I'm on the right side of the line. Using the word "just" implies that your proposed solution is obvious and trivial, and will probably be on the far side of the line for lots of people.

I completely agree with you. I've come to the realization recently that most people are incredibly insecure. It's funny that I find this article posted today given that this is something that I'm struggling with and was mentioned to me today.

Some of my colleagues have told me that they consider me to be "brilliant" and that they enjoy working with me, yet there are many others who tell me I can't hold a conversation with them without making them feel like an idiot or that I'm belittling them. From my perspective, I would never intentionally say anything that would cause someone to feel bad about themselves. I also make it a point to tell those I meet that I'm very blunt and if I seem confrontational it's just because I'm curious about their thought process. I see mistakes or inefficiencies as a way to learn, not belittle.

However, this never works. Some people are simply unwilling to learn or consider your solution. The unfortunate part about software development is that the actual software development is a fraction of the job and the politics make up the rest. There is no clear answer to the question of "how can I say this particular thing without someone getting offended?" because the unfortunate truth that I've found is that at the end of the day if the person is insecure or is going through some kind of emotional turmoil anything you say or do will offend or bother them. Especially if you're confident and incredibly good at what you do.

The solution that has seemed to work for me is to simply not help them unless you are their boss. If you're their boss people are more likely to be receptive of your advice. However if you're not their boss and you know they're insecure (you can learn who is and who isn't if you pay attention and practice this skill) just avoid any chance you can where you might point out their mistakes or make them feel bad unintentionally. It's unfortunate, but it's human nature.

I've learned a lot about human nature and politics in the positions that I've been in recently... I might write a blog post about it. It's incredibly frustrating how much of software development is mired with emotions.

Software without context or purpose is worthless, so an inability to relate to other humans is a net negative.

Fortunately, doing is a technical skill that can be learned; however, the desire to do so requires first abandoning both that holier-than-thou attitude making flawed inferences about other people's preferences, and the narcissistic belief in your own Socratic importance.

I think the problem isn't the phrasing, it's asking the question at all.

It's all too easy to confuse PRs as a quick peer review with an opportunity to vicariously work on something by asking questions that you should have asked when pairing.

If you don't trust the engineer, then why let them waste their time getting to the point they're asking for feedback to telegraph your contempt for them and try to "help" them?

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."

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.

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.

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...".

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.

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.

“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.

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?"

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.

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?"

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.

Can you add "why not sshd?" to the FAQ please

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

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? ;)

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?”

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.

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

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

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

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

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

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

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.

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

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.

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.

"Is it possible to use something like sshd"?

"Would it also work if we used sshd"?

"Have you tried using sshd"?

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

"You probably tried sshd, could you share what problems you ran into?"

"Is there a particular reason that sshd doesn't work for this?"

"I'm obviously coming at this afresh. Could using _X_ work?"

3. Why didn't you just use sshd? Now I have to learn something new.

Why don't you just ask "Have you tried using sshd"?

"Have you considered using sshd in this case?"

"Wait, why couldn't you use sshd?"

Oh, I feel like I know this one:

“What happened when you used X?”

Would "Would sshd work?" work?

I would have tried sshd. What's the catch?

"How did you try to solve this?"

"How does it compare to sshd?"

"Did you consider using xxx?"

"Sshd didn't work?"

"Can you use sshd?"

Assuming you eliminated sshd…

”ssh?”

i.e., “Or not?”

Was sshd considered?

Related comic relief: https://xkcd.com/1831/

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

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

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.

"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.

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

Reply on news.ycombinator.com