Comment by carlmr
6 years ago
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.
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.
5 replies →
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!
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.
2 replies →
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.
1 reply →
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 :)
1 reply →
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.
1 reply →
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
1 reply →
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?