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.

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.

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.

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.

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.

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.

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

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!

    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.

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

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

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.

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.

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?

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.

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.

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.

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

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?

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.

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

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?