7 ms·

I'm not sure why a direct communication style is inappropriate. We all learn as developers not to write extra lines of code, to be economical with wire/communic

I'm not sure why a direct communication style is inappropriate. We all learn as developers not to write extra lines of code, to be economical with wire/communication protocols, and to avoid duplicating sources of truth. It's only natural that we extend these principles into our professional communication. When I use direct language, I am trying to economize the time and energy of everyone listening to me by speaking as clearly and concisely as possible. It's also a style practiced in military communication, where it's taught as the ABCs - accuracy, brevity and clarity. I don't think we as an industry should concede that this style is reserved for jerks.

anonymouskimmer 4y ago
"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.
- 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)
kritiko 4y ago
Have you ever stewed over something somebody said to you? Miscommunication or negative comments can have productivity impacts.
Mezzie 4y ago
I'll also add that it's a class signifier, as much as we're all loath to admit it. The upper-middle and professional classes really don't like direct communication and they have control over key parts of most companies.
- throwaway2037 4y ago
  This is a great post: I never saw it expressed so clearly. I am the type of person that loathes office politics, and I am quick to point out when a decision is politically driven to satisfy someone far above us. Another way to look at indirect comms with senior staff: Behind closed doors they are frequently direct with other senior people. (I had some years in my career where I attended closed door meetings with people more senior than me.) In "public" (speaking with the peons, two levels or lower than them), they appear ultra-indirect, always using company talking points. It is grating and inauthentic to me, but I can assure you that many of them are hiding their true comms style to get rich as a senior manager.
  - Mezzie 4y ago
    What you say about senior people/leadership is pretty accurate, although I'm not sure that the directness is their 'true' comms style. My experience with people at that level is that it's really hard to tell what their true communication style is and they may not have one because they've spent their whole life switching their style to fit the room. I'd say the difference between a lower-class direct communication style and an upper-class one is that the upper-class can speak indirectly, they choose not to. Whereas the lower-class is gatekept out of such things absent some other influence (institutions, formerly well off family members, etc.) So the professional class uses the register to determine the difference between the guy who's wearing jeans because he grew up in hick country and doesn't own any 'nice' clothes and the guy who's wearing jeans because he's so important he doesn't need to follow the rules. This is also why there's a lot of friction between the professional classes and engineering. Engineering has status and yet a great deal of them are intractable and refuse to adapt, which reads as "you're beneath me because the rules apply to you but not to me". (Of course the engineers are just like 'the rules are stupid and arbitrary' because class distinctions don't matter a ton to them/us in comparison. Like if there were rules about what language to use depending on your height compared to the other person's. Who cares?) I'd say this happened because techies developed a culture of their own before being subsumed into the dominant socio-economic apparatus. There are some other differences between lower-class and upper-class direct speech, mostly in diction. I'm very good at code-switching and one of my favorite things to do is find a group of good professional progressives and then call their diversity bluff by deliberately switching from a professional register to a working-class/poor one and watch them try to deal with the cognitive dissonance. It's great fun. It's also something to watch because as you've noted, those in high places speak differently depending on their opinion of you. It's a good way to figure out what they think of you and it can be really interesting to see what flips them from "this person is a peon/useful for their interchangable ability(abilities) I need at this point" to "this person is unique enough/has enough connections/etc. to be worth cultivating in the future."
BiteCode_dev 4y ago
It's also a cultural thing. As a Frenchman, many Americans find my totally France compliant speech a bit rude. On the other hand, I find their way of calling everyone a "friend" and every single nice things "amazing" extremely annoying. But if people are adults, having a little friction is not a big deal. We don't need to appreciate all behaviors to live together. This is something that is well understood in jobs with harsh conditions, but in our very comfy IT jobs, people seem to sweat the small stuff way more.
- mongol 4y ago
  I want to go on a tangent here and say I completely agree. I don't know how it happened but many people around me now express how they love this or that, most things are amazing or awesome, and they click on heart emojis in Teams on more or less every message. Not sure if it is generational, or cultural or whatever. I can imitate but to me if feels odd. I prefer a more balanced language. Btw I am in a large well known company in Europe with people from all over the world, but quite young for the most part.
  - etempleton 4y ago
    It felt odd to me at first too. I think it is to try and build that team culture when people are remote.
- quacked 4y ago
  I agree with you and can't stand the fake-friendly speak many of my countrymen use. Additionally: > But if people are adults, having a little friction is not a big deal. We don't need to appreciate all behaviors to live together. This is, in my opinion, a hilariously French thing to say. Although I am by no means an expert on France I did study the language for many years and lived with a Parisian family for a semester in college, with some travelling to the south. "Everyone is a little bit pissed off at each other, but that doesn't really bother them and they still quite enjoy life" is exactly what I thought of the French. (With the exception of my hometown culture, I preferred life in France to life in the US.)
- epgui 4y ago
photochemsyn 4y ago
I see a ChatGPT app here! Nobody sends messages to each other directly, instead everything goes first to the app which reads and rephrases the message in the manner that the intended recipient finds most agreeable - terse and to the point, or long-winded and circumlocutious, plus whatever else fits. The information gets delivered with minimal friction, everyone's happy? This would be an interesting experiment, anyway.
- turtleyacht 4y ago
  Hmm, interesting :) Thank-you. I'm going to try it sometime: the message went through a "persona filter," so my reaction to it can (hopefully) be more moderate too.
ackfoobar 4y ago
I'm going off the tangent here. While we're near the topic, I kind of need a AITA style judgment. A friend of mine felt it was finger-pointing when her coworker said "could you take a look at your commit `abc0123`? because it broke the test `Xyz`". When I saw the screenshot I thought it was direct but professional. My opinion was dismissed because "yeah you think so because you're a bit socially awkward too"
- nordsieck 4y ago
  > A friend of mine felt it was finger pointing when her coworker said "could you take a look at your commit `abc0123`? because it broke the test `Xyz`". I thought it was direct but professional. IMO, it was appropriately finger pointing. The person who breaks the build should be the one to fix it - they're the one with the most context. But also - require tests to pass before a commit is allowed. It makes development so much better.
  - ackfoobar 4y ago
    > require tests to pass before a commit is allowed Agreed. I did not dig for the deeper context, their org is probably quite dysfunctional.
  - foobazgt 4y ago
    I've softened my language a bit over the years from approximately that to something more like: "Hey, I think commit abc0123 might have broken the build, and it looks like it was yours (link to build results). Would you mind looking at it?" I give myself a little room for being wrong (sometimes I am), and it comes across as being less of an ass, to which people generally respond positively.
  - bluefirebrand 4y ago
    Requiring tests to pass before a commit is allowed can be a negative experience as well. For instance if you're handing off a branch to someone else to take over work in progress because you're going on vacation. Or if you just have the (good) habit of checking in your work in progress code frequently, or daily. Or if you have several workstations you want to share code on. Point is that commits should be frequent and requiring tests to pass before you can commit is guaranteed to make sure that commits are infrequent. I prefer to put "tests must pass before PR can be merged", rather than before commits can be made. It solves all of those issues.
nordsieck 4y ago
> I'm not sure why a direct communication style is inappropriate. Think of politeness as a social technology that allows large groups of people to live and work in close proximity. It's not that politeness is more efficient - it's clearly less efficient. It's that most people can't psychologically handle too much direct communication.
- ackfoobar 4y ago
  This point of view is valid. But it is more complicated in software engineering because 1. autistic-autistic communication works just as well as (if not better than) neurotypical-neurotypical. 2. Being more thing-oriented on the people-things spectrum, our industry attracts more autists. A culture of NT communication style will probably be more inclusive. NT won't have their ego hurt; autists have to wear the mask elsewhere anyway. But as someone with Asperger's (undiagnosed), I resent this. Case in point: https://news.ycombinator.com/item?id=35365508 https://news.ycombinator.com/item?id=35365508
  - zdragnar 4y ago
    As someone considered neurotypical I don't see that comment as being too blunt at all. If anything, I would be grateful that the person went out of their way to find the offending commit.
    - ackfoobar 4y ago
      Thank you for affirming. The thought that I don't have a good enough grasp of what is acceptable (quite literally) shook me.
      - InspiredIdiot 4y ago
        I wouldn't consider the original wording unacceptable but I would suggest leaning more towards the phrasing foobazgt used a few replies back. Specifically, claiming that X broke Y is likely not fact-based. The facts in such a situation are often: a certain test started breaking in a certain build and the build reports that only one commit is different than the previous build. I would suggest stating that fact instead of inferring that the commit was the reason the build broke. I've seen plenty of instances where it turned out that wasn't the problem. The build infrastructure itself was changed. The reported set of commits versus the previous build was inaccurate. The test was flaky. A third party dependency that the build system didn't insulate itself from was updated. The list goes on. Allowing for the possibility that we are wrong isn't professional only because it is nice. It is also professional because it is honest and it helps focus the whole team on the facts so that we don't spend our time investigating the wrong thing.
etempleton 4y ago
I have no problem with directness, but I think sometimes people hide behind that to excuse their own bad behavior. Direct is short and to the point. When someone writes a long response that really digs into someone it is often because they want to make that person look bad. Humiliation is a bad teacher for most people.

anonymouskimmer 4y ago

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

kritiko 4y ago

Have you ever stewed over something somebody said to you? Miscommunication or negative comments can have productivity impacts.

Mezzie 4y ago

I'll also add that it's a class signifier, as much as we're all loath to admit it. The upper-middle and professional classes really don't like direct communication and they have control over key parts of most companies.

throwaway2037 4y ago
This is a great post: I never saw it expressed so clearly. I am the type of person that loathes office politics, and I am quick to point out when a decision is politically driven to satisfy someone far above us. Another way to look at indirect comms with senior staff: Behind closed doors they are frequently direct with other senior people. (I had some years in my career where I attended closed door meetings with people more senior than me.) In "public" (speaking with the peons, two levels or lower than them), they appear ultra-indirect, always using company talking points. It is grating and inauthentic to me, but I can assure you that many of them are hiding their true comms style to get rich as a senior manager.
- Mezzie 4y ago
  What you say about senior people/leadership is pretty accurate, although I'm not sure that the directness is their 'true' comms style. My experience with people at that level is that it's really hard to tell what their true communication style is and they may not have one because they've spent their whole life switching their style to fit the room. I'd say the difference between a lower-class direct communication style and an upper-class one is that the upper-class can speak indirectly, they choose not to. Whereas the lower-class is gatekept out of such things absent some other influence (institutions, formerly well off family members, etc.) So the professional class uses the register to determine the difference between the guy who's wearing jeans because he grew up in hick country and doesn't own any 'nice' clothes and the guy who's wearing jeans because he's so important he doesn't need to follow the rules. This is also why there's a lot of friction between the professional classes and engineering. Engineering has status and yet a great deal of them are intractable and refuse to adapt, which reads as "you're beneath me because the rules apply to you but not to me". (Of course the engineers are just like 'the rules are stupid and arbitrary' because class distinctions don't matter a ton to them/us in comparison. Like if there were rules about what language to use depending on your height compared to the other person's. Who cares?) I'd say this happened because techies developed a culture of their own before being subsumed into the dominant socio-economic apparatus. There are some other differences between lower-class and upper-class direct speech, mostly in diction. I'm very good at code-switching and one of my favorite things to do is find a group of good professional progressives and then call their diversity bluff by deliberately switching from a professional register to a working-class/poor one and watch them try to deal with the cognitive dissonance. It's great fun. It's also something to watch because as you've noted, those in high places speak differently depending on their opinion of you. It's a good way to figure out what they think of you and it can be really interesting to see what flips them from "this person is a peon/useful for their interchangable ability(abilities) I need at this point" to "this person is unique enough/has enough connections/etc. to be worth cultivating in the future."

BiteCode_dev 4y ago

It's also a cultural thing. As a Frenchman, many Americans find my totally France compliant speech a bit rude. On the other hand, I find their way of calling everyone a "friend" and every single nice things "amazing" extremely annoying. But if people are adults, having a little friction is not a big deal. We don't need to appreciate all behaviors to live together. This is something that is well understood in jobs with harsh conditions, but in our very comfy IT jobs, people seem to sweat the small stuff way more.

mongol 4y ago
I want to go on a tangent here and say I completely agree. I don't know how it happened but many people around me now express how they love this or that, most things are amazing or awesome, and they click on heart emojis in Teams on more or less every message. Not sure if it is generational, or cultural or whatever. I can imitate but to me if feels odd. I prefer a more balanced language. Btw I am in a large well known company in Europe with people from all over the world, but quite young for the most part.
- etempleton 4y ago
  It felt odd to me at first too. I think it is to try and build that team culture when people are remote.
quacked 4y ago
I agree with you and can't stand the fake-friendly speak many of my countrymen use. Additionally: > But if people are adults, having a little friction is not a big deal. We don't need to appreciate all behaviors to live together. This is, in my opinion, a hilariously French thing to say. Although I am by no means an expert on France I did study the language for many years and lived with a Parisian family for a semester in college, with some travelling to the south. "Everyone is a little bit pissed off at each other, but that doesn't really bother them and they still quite enjoy life" is exactly what I thought of the French. (With the exception of my hometown culture, I preferred life in France to life in the US.)
epgui 4y ago

photochemsyn 4y ago

I see a ChatGPT app here! Nobody sends messages to each other directly, instead everything goes first to the app which reads and rephrases the message in the manner that the intended recipient finds most agreeable - terse and to the point, or long-winded and circumlocutious, plus whatever else fits. The information gets delivered with minimal friction, everyone's happy? This would be an interesting experiment, anyway.

turtleyacht 4y ago
Hmm, interesting :) Thank-you. I'm going to try it sometime: the message went through a "persona filter," so my reaction to it can (hopefully) be more moderate too.

ackfoobar 4y ago

I'm going off the tangent here. While we're near the topic, I kind of need a AITA style judgment. A friend of mine felt it was finger-pointing when her coworker said "could you take a look at your commit `abc0123`? because it broke the test `Xyz`". When I saw the screenshot I thought it was direct but professional. My opinion was dismissed because "yeah you think so because you're a bit socially awkward too"

nordsieck 4y ago
> A friend of mine felt it was finger pointing when her coworker said "could you take a look at your commit `abc0123`? because it broke the test `Xyz`". I thought it was direct but professional. IMO, it was appropriately finger pointing. The person who breaks the build should be the one to fix it - they're the one with the most context. But also - require tests to pass before a commit is allowed. It makes development so much better.
- ackfoobar 4y ago
  > require tests to pass before a commit is allowed Agreed. I did not dig for the deeper context, their org is probably quite dysfunctional.
- foobazgt 4y ago
  I've softened my language a bit over the years from approximately that to something more like: "Hey, I think commit abc0123 might have broken the build, and it looks like it was yours (link to build results). Would you mind looking at it?" I give myself a little room for being wrong (sometimes I am), and it comes across as being less of an ass, to which people generally respond positively.
- bluefirebrand 4y ago
  Requiring tests to pass before a commit is allowed can be a negative experience as well. For instance if you're handing off a branch to someone else to take over work in progress because you're going on vacation. Or if you just have the (good) habit of checking in your work in progress code frequently, or daily. Or if you have several workstations you want to share code on. Point is that commits should be frequent and requiring tests to pass before you can commit is guaranteed to make sure that commits are infrequent. I prefer to put "tests must pass before PR can be merged", rather than before commits can be made. It solves all of those issues.

nordsieck 4y ago

> I'm not sure why a direct communication style is inappropriate. Think of politeness as a social technology that allows large groups of people to live and work in close proximity. It's not that politeness is more efficient - it's clearly less efficient. It's that most people can't psychologically handle too much direct communication.

ackfoobar 4y ago
This point of view is valid. But it is more complicated in software engineering because 1. autistic-autistic communication works just as well as (if not better than) neurotypical-neurotypical. 2. Being more thing-oriented on the people-things spectrum, our industry attracts more autists. A culture of NT communication style will probably be more inclusive. NT won't have their ego hurt; autists have to wear the mask elsewhere anyway. But as someone with Asperger's (undiagnosed), I resent this. Case in point: https://news.ycombinator.com/item?id=35365508 https://news.ycombinator.com/item?id=35365508
- zdragnar 4y ago
  As someone considered neurotypical I don't see that comment as being too blunt at all. If anything, I would be grateful that the person went out of their way to find the offending commit.
  - ackfoobar 4y ago
    Thank you for affirming. The thought that I don't have a good enough grasp of what is acceptable (quite literally) shook me.
    - InspiredIdiot 4y ago
      I wouldn't consider the original wording unacceptable but I would suggest leaning more towards the phrasing foobazgt used a few replies back. Specifically, claiming that X broke Y is likely not fact-based. The facts in such a situation are often: a certain test started breaking in a certain build and the build reports that only one commit is different than the previous build. I would suggest stating that fact instead of inferring that the commit was the reason the build broke. I've seen plenty of instances where it turned out that wasn't the problem. The build infrastructure itself was changed. The reported set of commits versus the previous build was inaccurate. The test was flaky. A third party dependency that the build system didn't insulate itself from was updated. The list goes on. Allowing for the possibility that we are wrong isn't professional only because it is nice. It is also professional because it is honest and it helps focus the whole team on the facts so that we don't spend our time investigating the wrong thing.

etempleton 4y ago

I have no problem with directness, but I think sometimes people hide behind that to excuse their own bad behavior. Direct is short and to the point. When someone writes a long response that really digs into someone it is often because they want to make that person look bad. Humiliation is a bad teacher for most people.