4 ms·

"You made a mistake here. Correct it." "You made a mistake here and need to correct it." "Please correct this mistake." "There's a mistake here that needs co

"You made a mistake here. Correct it." "You made a mistake here and need to correct it." "Please correct this mistake." "There's a mistake here that needs correcting." "Can you correct this mistake?" I'd say the top two are direct and definitely impolite. Number two may seem polite to a direct sort of person, but the blame makes it impolite. Of the latter three I'd say the top one is not only the most concise and direct, but also fairly polite. These last two are more polite, but lack directness.

ye-olde-sysrq 4y ago
IMO all of this is too brusque. "Hey - <problem> is causing <symptom>. I think you have context on this - can you drive <solution>?" We're people. The nuance, tone, and empathy of what we say matters. I know some people will scoff at "coddling" or "beating around the bush". I think these people don't correctly prioritize the outcomes of their communication. When I talk to someone, my goals are, in this order: 1. That the other person like me and want to continue working happily with me in the future and feel emotionally safe talking to me. 2. Whatever "primary"/immediate outcome I'm shooting for Paying attention to 1 pays off in the long term. People are happy to work with you and it accelerates how effective you can be because people feel safe with you.
- lisasays 4y ago
  "Hey - <problem> is causing <symptom>. I think you have context on this - can you drive <solution>?" Please don't go around blowing corporate-speak up people's asses like this. Seriously this a huge waste of time. If I made a typo in some important document or piece of code, just tell me what it was, and I'll fix it. We're team members after all. Plus we've been spent years at hard technical schools and are used to having our work evaluated and corrected by others. We're not babies. Granted, your approach is much more applicable (and is arguably necessary) when things are fuzzier, when it's not clear what the root cause is or who (if anyone) is at fault. Most of the time it isn't though - it's very straightforward, and has nothing to do with ego or blame at all. In these (the vast majority of cases) -- just give me the information so I get through the day, please.
  - MrGilbert 4y ago
    > Granted, your approach is much more applicable (and is arguably necessary) when things are fuzzier, when it's not clear what the root cause is or who (if anyone) is at fault. But can you always reliably tell? There might be a reason, what looks like a mistake to you, was done in the first place. A reason that’s not obvious to you, because the error is in plain sight and takes up all the space. So, by "blowing corporate-speak up people’s asses", you actually give them a chance to elaborate, without already coming to a conclusion and calling it a day. This is something I'd expect from a senior developer, for instance. I usually frame it as a question, to get an understanding as to why it was done. And trivial errors like typos in a method name get a comment with a suggestion, that can be applied by the original author in Azure DevOps with a single click.
    - lisasays 4y ago
      All I can say is that with both experience, and after getting into the groove and flow of working with a particular team - one starts to learn how to read the tea leaves, as it were, and to make reasonably accurate judgement calls about such things. I'm not saying the "soft, guarded" approach is never suitable; quite often it is. Most of the time, though -- especially after we've gotten to know the people we work with -- it's more efficient (and genuinely less distracting / bothersome to the other party) to just get to the point.
      - ye-olde-sysrq 4y ago
        I think devs are often prone to misjudging that though. Especially when there's a power imbalance. A senior or staff engineer talking to a junior or mid-level ALWAYS needs to be cognizant of the effect your actions and words have on other people. "after we've gotten to know" In my experience, once you've built solid rapport, you generally can always be less direct. "hey man did you just deploy xyz? I noticed there's some weird error prints, wanted to make sure you saw" "yeah thanks, just saw them a minute ago, already on it" There's no need to be highly structured or direct, just a small nudge/hint/check, and they know you have their best interests at heart and aren't upset or annoyed.
- deleted 4y ago
  [deleted]
- ricardobeat 4y ago
  Let's circle back to this question. It starts well, with "X is causing Y", and reminds me of a framework we had at one of my previous jobs - behaviour -> impact -> outcomes (or options?). It's a model to provide developmental feedback, but can be useful to frame other situations. In this case: "System X is currently way behind our target uptime. As you know, this was caused by the introduction of feature X which your team worked on recently. We need to get back on track and meet our SLOs before it starts impacting revenue." Tells them everything they need to know. You shared the necessary info and actions to be taken are obvious, but adding a "we need you to focus on this and take the lead on fixing it" will not sound aggressive. The approach you mentioned is very cloudy in comparison, "driving" something is not a clear outcome, "you have context" is soft blaming. It's just a very polished "it's your fault, fix your shit", and it would sound exactly like that to me. It's precisely the kind of beating around the bush that people scoff at. The message itself can be a lot better.
- zaphar 4y ago
  I have similar sounding goals except my first goal is this instead: 1. That the other person know they are valued by me as a person and feel safe talking with me. It shifts the goal from one that is about me to one that is about them. And that is really what I want. It's not to be liked but for them to feel valued.
- throwaway2037 4y ago
  I think your pattern looks very effective. I never considered that the side effect of #1 is to create a psychologically safe environment. Not to take anything away from your post, but I have noticed that a few people lean very heavily on #1 to get people to do a lot of #2 for them. In return, they are "always busy" and cannot help. I struggle the most with these people. I am sucker for #1, as I am human after all.
satellite2 4y ago
Generally "Is this a mistake?" Is largely sufficient and a smart person will fix it. All the five examples are too direct and in case there was no mistake which happens most often than not with competent teams, will leave a sour aftertaste to everyone.
- anonymouskimmer 4y ago
  I agree, but it's not direct. And the OP wanted direct.
  - tremon 4y ago
    I think you're confusing direct and confrontational. All five of your phrasings are combative and lack specificity (and so does the GP's questioning phrase). Simply saying or asking "this is a mistake" is not identifying the problem at all. Maybe you implied there would be more context than just that one phrase, but in the interest of furthering the discussion, these phrasings are all better than your examples, and still very direct: - "This approach fails under conditions A or B" - "This code seems to assume X, where is this validated?" - "How does this code handle condition Y?" - "This code delivers the wrong result under condition Z" - "This does not do what's specified in the ticket: it should do S, not P"
jacobolus 4y ago
You missed various less-direct but often just as effective kinds of questions: “Can you find the mistake here?” “Is there a mistake here?” “Could there be a mistake here?” “Did you test this part?” Better still is to be specific: “What happens if «specific edge case»?” “I did it that way one time, but ran into «concrete problem».” “Your way here works just as well, but doesn’t match our conventions.”
- ntr-- 4y ago
  I can't imagine how much time you must have available to be able to respond to an error with: > Could there be a mistake here? in place of simply correcting and then getting back on track with actually solving a presumably difficult problem. <<The Zone>> is a fleeting thing, especially with two programmers. Such nebulous, passive language seems like a guaranteed way to disrupt any kind of flow state.
jacobsenscott 4y ago
None of these would qualify as a good code review though. The reviewer needs to put in the work - explain in a concrete way what the problem is (and be right), and offer possible and correct solutions. "This will cause a problem if there are a large number of records in the table because it loads all the records at once. A memory efficient way to iterate this data is ...". is a good comment.
- tharkun__ 4y ago
  Not necessarily. There can be so many different things happening here. The commenter might overlook something. So the word will might not be a good choice. You can say could or can. The second sentence is not free from this either. If the commenter did indeed overlook something and the code was specifically written as it was on purpose with full knowledge of what might happen, then this can come across as quite condescending. As in "you dumb-eff don't even know how to read a large table efficiently. Here I'll show you how exactly to do it sigh". And the author will think "what an a-hole, does he think I don't know how to do this? What a dumb-eff". Without knowing the exact example you were thinking of one could at least rewrite it to "One possible optimization I can think of would be to do X". Now your PR author might say "Aah you're right, I copied this code from place A quickly to prototype this and forgot to come back and do it properly for the large amount of data we expect in Prod. That X approach is pretty neat. I usually prefer Y. Look here I pushed a change. Let me know what you think".
thegrimmest 4y ago
Can you elaborate as to why the first two are impolite? They seem like statements of fact followed by a directive. I don't think directives should be phrased as requests (which are possible to politely decline). These are commands, what's wrong with phrasing them as such?
- anonymouskimmer 4y ago
  > Can you elaborate as to why the first two are impolite? The "YOU caused a problem", not "I see a problem".
  - thegrimmest 4y ago
    Again, that's a statement of fact. Why is it impolite? What's wrong with being directly told you've caused a problem? Especially if you in fact have.
    - anonymouskimmer 4y ago
      > What's wrong with being directly told you've caused a problem? There's nothing "wrong" with being impolite, it's just impolite to be impolite. > Why is it impolite? It feels impolite to me therefore it is impolite. Trying to parse out my feelings the best I can come up with is that the phrasing highlights the subordinate nature of the person being directed relative to the person directing by focusing on the person and the mistake prior to the task. https://pragmatics.indiana.edu/politeness/impoliteness.html https://pragmatics.indiana.edu/politeness/impoliteness.html > Contextual and co-textual factors > • The extent to which the behavior is positively or negatively valued in the relevant culture; Making a mistake is negatively valued in most cultures, especially when it needs to be corrected. > • The extent to which face or sociality rights are exposed; Highlighting subordination and superordination exposes sociality rights. > • The degree of intentionality ascribed to the actor(s); The personal "you" can be, though may not be, seen to impute a degree of intentionality. Additionally: > (2) [rude behavior] does not utilise politeness strategies whetre they would be expected, in such a way that the utterance can only almost plausibly be interpreted as intentionally and negatively confrontational. (Lakoff, 1989: 103) > (5) Impoliteness comes about when: (1) the speaker communicates face-attack intentionally, or (2) the hearer perceives and/or constructs behavior as intentionally face-attacking, or a combination of (1) and (2). (Culpeper, 2005a: 38) > impoliteness <versus rudeness> occurs when the expression used is not conventionalised relative to the context of occurrence; it threatens the addressee’s face… but no face-threatening intention is attributed to the speaker by the hearer. (Terkourafi, 2008: 70)

ye-olde-sysrq 4y ago

IMO all of this is too brusque. "Hey - <problem> is causing <symptom>. I think you have context on this - can you drive <solution>?" We're people. The nuance, tone, and empathy of what we say matters. I know some people will scoff at "coddling" or "beating around the bush". I think these people don't correctly prioritize the outcomes of their communication. When I talk to someone, my goals are, in this order: 1. That the other person like me and want to continue working happily with me in the future and feel emotionally safe talking to me. 2. Whatever "primary"/immediate outcome I'm shooting for Paying attention to 1 pays off in the long term. People are happy to work with you and it accelerates how effective you can be because people feel safe with you.

lisasays 4y ago
"Hey - <problem> is causing <symptom>. I think you have context on this - can you drive <solution>?" Please don't go around blowing corporate-speak up people's asses like this. Seriously this a huge waste of time. If I made a typo in some important document or piece of code, just tell me what it was, and I'll fix it. We're team members after all. Plus we've been spent years at hard technical schools and are used to having our work evaluated and corrected by others. We're not babies. Granted, your approach is much more applicable (and is arguably necessary) when things are fuzzier, when it's not clear what the root cause is or who (if anyone) is at fault. Most of the time it isn't though - it's very straightforward, and has nothing to do with ego or blame at all. In these (the vast majority of cases) -- just give me the information so I get through the day, please.
- MrGilbert 4y ago
  > Granted, your approach is much more applicable (and is arguably necessary) when things are fuzzier, when it's not clear what the root cause is or who (if anyone) is at fault. But can you always reliably tell? There might be a reason, what looks like a mistake to you, was done in the first place. A reason that’s not obvious to you, because the error is in plain sight and takes up all the space. So, by "blowing corporate-speak up people’s asses", you actually give them a chance to elaborate, without already coming to a conclusion and calling it a day. This is something I'd expect from a senior developer, for instance. I usually frame it as a question, to get an understanding as to why it was done. And trivial errors like typos in a method name get a comment with a suggestion, that can be applied by the original author in Azure DevOps with a single click.
  - lisasays 4y ago
    All I can say is that with both experience, and after getting into the groove and flow of working with a particular team - one starts to learn how to read the tea leaves, as it were, and to make reasonably accurate judgement calls about such things. I'm not saying the "soft, guarded" approach is never suitable; quite often it is. Most of the time, though -- especially after we've gotten to know the people we work with -- it's more efficient (and genuinely less distracting / bothersome to the other party) to just get to the point.
    - ye-olde-sysrq 4y ago
      I think devs are often prone to misjudging that though. Especially when there's a power imbalance. A senior or staff engineer talking to a junior or mid-level ALWAYS needs to be cognizant of the effect your actions and words have on other people. "after we've gotten to know" In my experience, once you've built solid rapport, you generally can always be less direct. "hey man did you just deploy xyz? I noticed there's some weird error prints, wanted to make sure you saw" "yeah thanks, just saw them a minute ago, already on it" There's no need to be highly structured or direct, just a small nudge/hint/check, and they know you have their best interests at heart and aren't upset or annoyed.
deleted 4y ago
[deleted]
ricardobeat 4y ago
Let's circle back to this question. It starts well, with "X is causing Y", and reminds me of a framework we had at one of my previous jobs - behaviour -> impact -> outcomes (or options?). It's a model to provide developmental feedback, but can be useful to frame other situations. In this case: "System X is currently way behind our target uptime. As you know, this was caused by the introduction of feature X which your team worked on recently. We need to get back on track and meet our SLOs before it starts impacting revenue." Tells them everything they need to know. You shared the necessary info and actions to be taken are obvious, but adding a "we need you to focus on this and take the lead on fixing it" will not sound aggressive. The approach you mentioned is very cloudy in comparison, "driving" something is not a clear outcome, "you have context" is soft blaming. It's just a very polished "it's your fault, fix your shit", and it would sound exactly like that to me. It's precisely the kind of beating around the bush that people scoff at. The message itself can be a lot better.
zaphar 4y ago
I have similar sounding goals except my first goal is this instead: 1. That the other person know they are valued by me as a person and feel safe talking with me. It shifts the goal from one that is about me to one that is about them. And that is really what I want. It's not to be liked but for them to feel valued.
throwaway2037 4y ago
I think your pattern looks very effective. I never considered that the side effect of #1 is to create a psychologically safe environment. Not to take anything away from your post, but I have noticed that a few people lean very heavily on #1 to get people to do a lot of #2 for them. In return, they are "always busy" and cannot help. I struggle the most with these people. I am sucker for #1, as I am human after all.

satellite2 4y ago

Generally "Is this a mistake?" Is largely sufficient and a smart person will fix it. All the five examples are too direct and in case there was no mistake which happens most often than not with competent teams, will leave a sour aftertaste to everyone.

anonymouskimmer 4y ago
I agree, but it's not direct. And the OP wanted direct.
- tremon 4y ago
  I think you're confusing direct and confrontational. All five of your phrasings are combative and lack specificity (and so does the GP's questioning phrase). Simply saying or asking "this is a mistake" is not identifying the problem at all. Maybe you implied there would be more context than just that one phrase, but in the interest of furthering the discussion, these phrasings are all better than your examples, and still very direct: - "This approach fails under conditions A or B" - "This code seems to assume X, where is this validated?" - "How does this code handle condition Y?" - "This code delivers the wrong result under condition Z" - "This does not do what's specified in the ticket: it should do S, not P"

jacobolus 4y ago

You missed various less-direct but often just as effective kinds of questions: “Can you find the mistake here?” “Is there a mistake here?” “Could there be a mistake here?” “Did you test this part?” Better still is to be specific: “What happens if «specific edge case»?” “I did it that way one time, but ran into «concrete problem».” “Your way here works just as well, but doesn’t match our conventions.”

ntr-- 4y ago
I can't imagine how much time you must have available to be able to respond to an error with: > Could there be a mistake here? in place of simply correcting and then getting back on track with actually solving a presumably difficult problem. <<The Zone>> is a fleeting thing, especially with two programmers. Such nebulous, passive language seems like a guaranteed way to disrupt any kind of flow state.

jacobsenscott 4y ago

None of these would qualify as a good code review though. The reviewer needs to put in the work - explain in a concrete way what the problem is (and be right), and offer possible and correct solutions. "This will cause a problem if there are a large number of records in the table because it loads all the records at once. A memory efficient way to iterate this data is ...". is a good comment.

tharkun__ 4y ago
Not necessarily. There can be so many different things happening here. The commenter might overlook something. So the word will might not be a good choice. You can say could or can. The second sentence is not free from this either. If the commenter did indeed overlook something and the code was specifically written as it was on purpose with full knowledge of what might happen, then this can come across as quite condescending. As in "you dumb-eff don't even know how to read a large table efficiently. Here I'll show you how exactly to do it sigh". And the author will think "what an a-hole, does he think I don't know how to do this? What a dumb-eff". Without knowing the exact example you were thinking of one could at least rewrite it to "One possible optimization I can think of would be to do X". Now your PR author might say "Aah you're right, I copied this code from place A quickly to prototype this and forgot to come back and do it properly for the large amount of data we expect in Prod. That X approach is pretty neat. I usually prefer Y. Look here I pushed a change. Let me know what you think".

thegrimmest 4y ago

Can you elaborate as to why the first two are impolite? They seem like statements of fact followed by a directive. I don't think directives should be phrased as requests (which are possible to politely decline). These are commands, what's wrong with phrasing them as such?

anonymouskimmer 4y ago
> Can you elaborate as to why the first two are impolite? The "YOU caused a problem", not "I see a problem".
- thegrimmest 4y ago
  Again, that's a statement of fact. Why is it impolite? What's wrong with being directly told you've caused a problem? Especially if you in fact have.
  - anonymouskimmer 4y ago
    > What's wrong with being directly told you've caused a problem? There's nothing "wrong" with being impolite, it's just impolite to be impolite. > Why is it impolite? It feels impolite to me therefore it is impolite. Trying to parse out my feelings the best I can come up with is that the phrasing highlights the subordinate nature of the person being directed relative to the person directing by focusing on the person and the mistake prior to the task. https://pragmatics.indiana.edu/politeness/impoliteness.html https://pragmatics.indiana.edu/politeness/impoliteness.html > Contextual and co-textual factors > • The extent to which the behavior is positively or negatively valued in the relevant culture; Making a mistake is negatively valued in most cultures, especially when it needs to be corrected. > • The extent to which face or sociality rights are exposed; Highlighting subordination and superordination exposes sociality rights. > • The degree of intentionality ascribed to the actor(s); The personal "you" can be, though may not be, seen to impute a degree of intentionality. Additionally: > (2) [rude behavior] does not utilise politeness strategies whetre they would be expected, in such a way that the utterance can only almost plausibly be interpreted as intentionally and negatively confrontational. (Lakoff, 1989: 103) > (5) Impoliteness comes about when: (1) the speaker communicates face-attack intentionally, or (2) the hearer perceives and/or constructs behavior as intentionally face-attacking, or a combination of (1) and (2). (Culpeper, 2005a: 38) > impoliteness <versus rudeness> occurs when the expression used is not conventionalised relative to the context of occurrence; it threatens the addressee’s face… but no face-threatening intention is attributed to the speaker by the hearer. (Terkourafi, 2008: 70)