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 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.
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.
> I'm not clever enough to understand why you didn't use sshd. It would take a fucking genius to figure that out.
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.
"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.
>> 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.
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.
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.
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.
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.
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 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.
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.
Praise in public, criticize in private
- 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.
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.
This seems unnecessarily belligerent.
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.
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.
- 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.
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".
Usually I would be more openly critical if someone is more experienced.
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.
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.."
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.
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
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."
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?
"How would sshd function in this setting?"
"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 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.
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 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.
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.
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.
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.
I'd probably phrase it 'did you consider using X here?' sometimes prefaced with 'maybe I'm missing something...'
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.
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..
"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 suppose now I'm deriving meaning in my head.
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.
However, I can see that in text conversations the chance for misunderstanding can be much higher.
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.
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.
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.
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.
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.
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`?
> Did you try `sshd`? This seems like it might be a good fit.
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.
"I was wondering if `sshd` would work here. What do you think?"
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.
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.
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.
"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?
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)
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!"
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.
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!
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.
"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 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.
"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.
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).
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.
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).
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.
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.
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.
“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.
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.
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.
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.
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.
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.
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)
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.
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"?
> What made you realize that sshd wasn’t going to work for you?
> 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.
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.
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.
"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.
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?"
"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!"
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.
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.
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.
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).
- 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.
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.
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.)
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.
> 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.
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.
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.
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.
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.
"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.
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.
"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.
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.
- 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 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.
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?"
I think you should always think a little bit for the person opposite: Did you give enough context? Is it ambiguos? etc.
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.
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...
They're literally asking _why_.
If you take it as a statement i.e. 'just use $x' then that's a completely different matter.
“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?
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?
Why doesn't the author just try putting it that way?
> "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.
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.
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.
I mean just ask whether they tried it.
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.
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
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".
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.
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.
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)
- "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.
"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.
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.
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.
"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.
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.
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.
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 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.
- 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.
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.
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.
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.
Even being socratic (my preferred slow as hell approach) can sometimes border being patronising.
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...."
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?”
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.
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.
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"
> 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?
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.
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.
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.
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.
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.
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?
"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.
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).
"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.
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.
Well, it won't be sshd because everyone knows that. But you get it.