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.
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 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.
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.
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?
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.
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?
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 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.
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.
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.
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.
This is just magical thinking - saying the right incantation is going to make everything ok. It doesn't work that way. This is all about the worship of weakness, a peculiarly American kind of power play where the goal isn't to gain any power, but to avoid any kind of value judgment at all.
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.
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).
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...?"
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.
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.
This is a discussion between 2 more or less equally clever persons.
The problem is when 1 person is clever and the other is not (and you probably don’t know yet).
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.
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.
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.
361 comments
[ 3.0 ms ] story [ 302 ms ] threadFor 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 come” feels slightly lest antagonistic then simple “why” but that may well be regional differences
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.
> 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?
> I would have used sshd, because I am inexperienced and don't understand your approach. Could you help me understand?
That's my go-to phrase. It implies that I am looking to be educated, and not that I think they messed up.
Compare that to "Why doesn't sshd work here?" (mentioned elsewhere in the comments), which seems more focused on education.
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 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.
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 :)
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.
"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.
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.
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.
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.
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
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.
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 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.
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 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).
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).
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".
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?”
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.
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.
"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!"
>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.