I used to think the same way as you, and then I started a company and had to pay out of pocket for employees, and the sad truth that I almost hate myself for admitting is that if you have to pick between incompetent but nice, and competent but a jerk, you take the jerk. And yes, multiple people will even quit because you picked the jerk over the nice guy, and I still found it's worth it to take the jerk because of how competency scales. A good/competent software engineer can genuinely do the work of many, many mediocre developers and you're almost always better off with a small number of really solid developers over a large number of nice but mediocre ones.
Now of course we can always exaggerate things to an extreme and compare a racist, sexist, jerk who swears nonstop, to someone who is mildly incompetent, and there are certain principles and boundaries that are worth upholding with respect to how people treat each other regardless of their productivity, but in actuality that's not really the difficult choice you end up facing.
The really difficult choice you end up facing is someone who is nice and gets along with people but is ultimately too dependent on others to do their job versus someone who works independently and does an excellent job but is very blunt and can be an asshole in regards to the expectations they hold others to. Good software developers often expect their peers to also be at a high standard and will speak in very plain, rude, and blunt language if they feel others are not pulling their weight.
And finally, I have observed that in the long run, competent people tend to prefer to work with others whose skill they respect and they feel they can learn from because they're really good at their job, compared to working with someone who is pleasant but is always dependent on others. Being nice is a good short term skill to have, but people get used to those who are nice but they never get used to someone who is incompetent.
Back when I was a developer, I tended towards the competent jerk. I was pretty good, but not 10x and I was a bit short with people not a raging asshole, though looking back I am ashamed of my behavior. The good thing is that it makes it really easy for me to recognize now.
On my teams, I don’t accept incompetence, so even the nice folks get managed out quickly.
I do have a strategy for handling the 10x assholes, though. We have a difficult problem domain (lots of math and physics) so I need those smart folks. I’m also lucky to have 2 hyper-competent nice devs too. I use them like jiu jitsu gyms use their enforcers.
When an extra aggressive 20 something shows up to a gym and starts making it unsafe to train, the gym will pair them up with a black belt who will humiliate them but be super nice about it and put them in their place.
I do the same. If I see asshole behavior surfacing, I’ll pair them up with my one of my super competent devs and have a them do a in depth code review or something like that.
Most of the time it works and the bad behavior goes away. If that doesn’t work (very rarely), we’ll manage them out.
Sometimes the 10x jerk is a jerk because he’s used to dealing with incompetence. But if you can show them competent-nice behavior, they’ll often pattern match to that.
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.
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.
Yeah, for me the key thing is professionalism (a loaded word, worth an entire book). If everyone on the team "has it", then whether people are more direct or less direct probably won't matter, because everyone understands their role and their duty, and aligns their behaviours and their interpretations accordingly.
Anecdotally, for every "bad situation" I've ever been in in the workplace, I could point to at least one person who was not being professional.
Many disciplines have a real "culture of professionalism" (and I've operated in these disciplines prior to switching to to eng), but I don't think software engineering has that. I think it's probably related both to the relative abundance of workers without formal instruction, and to the lack of standards across academic programmes / bootcamps etc.
It’s also sign (IMO) of the rapid growth in the field.
When there is a severe shortage of warm bodies and things go up and to the right, a lot of ‘less important’ expectations get overlooked.
When it does that for a long time, people sometimes forget why the original expectations were even there in the first place. Then, when it’s no longer up and to the right, we have to figure it all out again or it falls apart.
Do it enough time and it gets embedded in official professional standards, etc.
That said, I’ve certainly run across many Engineers (with the ring type) that do plenty of unprofessional things. They just figure out how to do them passive aggressively or sidestep what would run afoul of the official standards. But it’s the same thing.
That's pretty much in line with my observations as well.
It's not to say that accredited engineers are automatically better, or that accredited engineering programmes are perfect, or anything like that. Like you pointed out, there's no shortage of examples/arguments to the contrary. (Personally, my background is medical, so it's a bit different than accredited engineering programmes, but I also am familiar with those having been involved in a bunch of senate-level evaluation of programmes, etc, at my school.)
But I do think accredited programs have certain benefits, and that the software world should pay attention to what other engineering disciplines get right.
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.)
> As a Frenchman, many Americans find my totally France compliant speech a bit rude.
I call it exact. But indeed, it takes a little while to get used to it. I recall someone at a tech company here in the Bay with a French manager that thought his manager didn't like him, until he read his feedback during his first performance review.
French Canadians sounds like Americans with accents.
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.
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.
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."
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"
This is just my take, but if the person being rightfully called-out is claiming you are socially awkward, that to me seems a bit tactless, unnecessarily defensive (in the emotionally immature sense), and kinda hypocritical. But hey, I don't know the full story, wasn't there, and don't know the stakes. Might just be the way I see things, though.
> 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.
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.
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.
> I prefer to put "tests must pass before PR can be merged", rather than before commits can be made.
I worded it poorly, but this is largely what I meant. Although I was trying to stick to commits on main/master for the repository of record since PRs are a github (and bitbucket?) thing, whereas pre-commit hooks are a git thing.
I send screenshots all the time, though. I feel like it's helpful. But I agree else-thread [1] that "word padding" helps soften what the other may (depending on mood, time of day, kids yelling, and Oh God I am this close to sending up this PR if I can just have time to think) misinterpret and become agitated by.
I think you're fortunate to have someone be able to tell you stuff like that without it offending you [2]. Maybe she needed to vent a little. It's nice to have someone to vent to (within limits).
In a week or so she might come around and agree, yeah we shouldn't break the build--but at the time it was annoying to be told that (due to tone or whatever reason).
If I'm following this correctly, they asked your opinion and then were dismissive of it "because you're socially awkward." If so, they're the assholes.
Surely, they knew you were socially awkward before they asked.
Context is important. There's a way to say that nicely like sending that person a DM to let them know. And then maybe send a note to the team chat if the rest of the team need to know and it would be a blocker.
But your friend should also have less of an ego about it and accept responsibility.
That being said, I've been in team environments where the language felt personal and like I was being thrown under the bus unnecessarily. So I've been on both sides.
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?
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.
> 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.
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
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.
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.
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.
"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.
"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.
> 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.
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.
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.
"Hey man did you just deploy xyz? I noticed there's some weird error prints, wanted to make sure you saw"
That sounds totally great of course. What I'm concerned about is when people think they need to get all long-winded and and jargon-y to avoid sounding "blunt". Per the example in the ancestor comment which tipped this all off (slotting your values in):
"Hey - it seems the XYZ deployment is causing some weird error prints. I think you might have the context on this - can you drive a solution?"
Even if your teammates don't need this, writing this way is a useful skill when dealing with vendors or other 3rd parties whose culture you don't know, and you don't want to give them an excuse to prioritise someone else's ticket
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.
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.
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.
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.
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"
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.
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".
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?
> 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.
> • 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)
Wouldn't professionalism dictate that your management of your own feelings in the face of simple factual statements is your own responsibility? What's impolite in a social context isn't the same as what's impolite in a professional context.
If the goal of an organization is to accomplish the objective in the most efficient way, doesn't this sort of feelings-management interfere? Isn't it (much) more efficient to just communicate directly and clearly, an leave feelings-management to listeners? Isn't this why militaries all over the world do this? Shouldn't we all learn from their example?
No, this is called being a grown up in all contexts, not just professional ones.
> What's impolite in a social context isn't the same as what's impolite in a professional context.
Professional contexts are subsets of social contexts. They aren't special. The only thing that can make any context special are the meanings of individual behaviors the actors within that context have mutually negotiated between them.
> doesn't this sort of feelings-management interfere?
Of course not. A typical person can work more effectively when they personally don't have to actively manage their emotional responses to others. This is facilitated by non-superficial politeness all around. Because it is a natural response to ruminate, for periods of time that are disproportionate to the event, on how others have treated us (common in relatively social animals, and possibly non-animal organisms), it is far more efficient to manage politeness than to count on emotional self-management.
> Isn't this why militaries all over the world do this? Shouldn't we all learn from their example?
You can be rude, not just impolite, in particular instances in civilian life without getting most people het up about it. But these instances are few and far between.
In militaries people are explicitly taught that their life absolutely depends on this rote learning and immediate response to shouted orders. Additionally, the military doesn't care as much about optimal functionality, just basic functionality. Theoretically systems exist in the military to prevent cronyism and other forms of privilege; everyone is treated the same, or at least has the same opportunities. This itself minimizes the rudeness bias. More importantly, when off duty, or on duty but not actively engaged in an exercise, officers and senior non-coms are less direct and do a lot of feelings management. Military life is not boot camp.
Even with all of that, in Vietnam at least, grunts did kill their officers at times. Active shooter situations are extraordinarily bad, and a lot of work goes into preventing and managing them. Being polite is one part of this management.
And plenty of people don't have the mindset for the military, and know this, and purposefully avoid joining the military because of this. You can't eliminate them from the civilian workforce.
Right, but my initial point is that any reasonable rumination on a statement of fact followed by a directive concludes with the assessment that nothing inappropriate happened. If you are at fault, and are subordinate, then the communication was appropriate. If you're not, then a simple refutation of the factual claim is all that's needed.
Shouldn't we expect people to be fundamentally reasonable in this way, even if some people have a hard time with it? I would say that is what striving for excellence looks like.
> the military doesn't care as much about optimal functionality
The military certainly does care about optimal functionality, since the price of failure (losing battles/wars) is cataclysmic. I'd say that (winning) militaries are among the most efficient human organizations out there.
Vietnam was staffed by conscripts who, importantly (and rightly), didn't believe in the objective they were forced to fight for. It's not a situation with any good outcomes, and is wildly different from a volunteer army (or corporation).
> You can't eliminate them from the civilian workforce.
I'm not suggesting we do, only that we as an industry endeavour to elevate our standards of professionalism by emulating some of the most professional organizations out there (militaries, intelligence organizations, industry leaders, etc.). All of these organizations are characterized as "toxic" in wider circles specifically for the traits that allow them to succeed.
> that any reasonable rumination on a statement of fact followed by a directive concludes with the assessment that nothing inappropriate happened.
If everyone responded in a way you find reasonable we'd be a lot more monotonous. "It takes all kinds" is not just an idiom of tolerance, it's a genuine fact. We would not have as vibrant and productive a culture if we were monotonous.
> Shouldn't we expect people to be fundamentally reasonable in this way
No.
> even if some people have a hard time with it?
Especially not then.
> I would say that is what striving for excellence looks like.
I would say that "striving for excellence" means it takes two to tango (I feel in the mood for idioms :P). To most effectively ameliorate impolite situations both parties need to respond, not just the one who felt that they received impoliteness.
> The military certainly does care about optimal functionality
Just like almost every other organization (other than NIST) optimality is not the priority, adequacy is. "Is this adequate to our needs? Great, we go with it."
> It's not a situation with any good outcomes, and is wildly different from a volunteer army (or corporation).
And yet we still get active shooter situations in volunteer militaries and civilian corporations.
> emulating some of the most professional organizations out there
Why are these organization more "professional" than other corporations which practice professions?
> militaries, intelligence organizations, industry leaders, etc.)
Militaries typically don't have competition anymore, except for other militaries. And when they do face irregular forces they don't always outright win. There are very few non-military martial forces, and I would guess most of those follow a military cultural structure. We're a long way from bands of warriors (e.g. "The 13th warrior"). Even then, we have seen that volunteer forces function better than draft forces.
As there is no more competition, has the effectiveness of these particular direct organizational cultures been experimentally validated against other organizational cultures? In which contexts (i.e. does the effectiveness universalize to all sorts of organizations and professions)?
> All of these organizations are characterized as "toxic" in wider circles specifically for the traits that allow them to succeed.
And you know these traits are responsible for their success (and not their failures) because why? And that, even if so, the effectiveness of these traits will generalize to the success of other organizations?
It seems as though you're just defending unreasonable behaviour in the sprit of diversity. Assigning value to things necessitates narrowing the diversity of all possibility. I'm not clear on what value exactly tolerating unreasonable behaviour provides, can you elaborate?
To most effectively ameliorate impolite situations we need clear, written codes of conduct (read: communication protocols) dictating what is and isn't polite to say, and explaining why. None of this "It feels impolite to me therefore it is impolite" nonsense. Clarifying and standardizing communication is unsurprisingly the best way to avoid miscommunication.
The military's main goal is to succeed (read: win). I concede that organizations optimize for adequacy, but hold that organizations that consistently meet and exceed their objectives are those to be emulated.
Many people working at very high-functioning (military and civilian) organizations (and teams) report an environment of clear, direct, communication and a culture of personal responsibility and ownership. These traits are antithetical to the indirect, blame-shifting style that is being advocated in the above thread. If something is your fault, you should be the first person to admit it, and others should not hesitate to (directly) point it out. This is a hallmark of high-functioning teams, and is a great example of how communication style is inseparable from wider team and organizational culture. And it's the culture of ownership found in high-functioning organizations that we should all aspire to.
You're the person who wants a monoculture of direct speech, when it is facially evident that indirect speech is highly used in society, and you're calling me unreasonable?
I've said what I had to say. From my point of view you appear to have a bias for a particular order that you are unwilling to budge from. I'm not convinced of its correctness.
> we need clear, written codes of conduct (read: communication protocols) dictating what is and isn't polite to say, and explaining why.
People who are unable to "read the room" need this. Mores evolve without such clear guidelines, which would not be possible if many people were not able to adapt to unstated expectations. Yes, it's important to reality check. But no, protocols and explanations are not the only way to do this . We are not children anymore. We are adults and are expected to figure this out on our own. You don't seem to find my explanations adequate anyway, so the best you'd get with a protocol and explanations are people complaining about the protocol and saying they really don't get the explanations, and so don't find them worth following.
> None of this "It feels impolite to me therefore it is impolite" nonsense.
Why do you think intuitive, or guttural, means of understanding are nonsense? Without them we would be either paralyzed in analysis or slow as a sloth. We evolve to take shortcuts. We evolve, for very, very good reasons!, to read between the lines and look through superficiality. Without doing so we would have died off a long time ago.
> Clarifying and standardizing communication is unsurprisingly the best way to avoid miscommunication.
Sure, I agree with this as stated. I just think politeness, as described above, also fits into this. Hierarchy does not matter for clear communication. Blame does not matter for clear communication. And unfortunately we aren't all speaking Lojban - there will always be some miscommunication. We are also a species that reads nuance into tone and word choices. This isn't going to change, and trying to make it change is a heck of a lot less efficient than navigating around it. Not to mention dangerous! It is actively dangerous to get people to second guess their intuitive readings of social situations, at least without a lot of follow up training. People have died because they felt they should give a situation the benefit of the doubt when their instincts were to flee.
And I'll add that avoiding miscommunication is not the be all and end all. If a person knows, beyond a shadow of a doubt, that you look down on them, this can be worse for productive labor than merely thinking it might be the case.
> These traits are antithetical to the indirect, blame-shifting style that is being advocated in the above thread.
Blame doesn't have to be cast in order for personal responsibility to be cast!
> If something is your fault, you should be the first person to admit it
I don't disagree. If you realize it, of course.
> and others should not hesitate to (directly) point it out.
They can do so politely. Much more easy to do in person where a polite tone of voice can be used.
> And it's the culture of ownership found in high-functioning organizations that we should all aspire to.
Whatever, man. Give me a stake and I'll take ownership, just give me a salary and why the hell should I feel a sense of ownership in something I don't own?
I'm done with my part of this conversation. I don't feel we're going anywhere.
You'll find that traditional cultures are almost universally quite rigid, prescriptive, and hierarchical about such things. Strict, slowly-evolving, protocols about whom to address by what title, whom to bow to and how low, etc. It's only our modern multiculture that has shed these traditional mores. I'm pointing out that it hasn't exactly resulted in a net win. An environment when no one is sure exactly how direct they can afford to be, and who might take offense to what, isn't a productive one.
Many of these customs have only been shed by American culture very recently. Calling your boss "Sir" or "Ma'am" (with all the associated deference and subordination) and strangers "Mr" and "Ms" was the norm in living memory. Shedding this structure is still very much experimental.
> If a person knows, beyond a shadow of a doubt, that you look down on them
And yet we managed to build just about all of civilization working in deep and rigid hierarchies. You might even say that the construction of such hierarchies is one of the most important enablers of civilization. I'm simply saying we should try to optimize them.
> why the hell should I feel a sense of ownership in something I don't own
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.
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.
Those hyper-competent nice devs can turn incompetent engineers into competent ones, though, and have such a huge impact on work culture that they bring everyone else up with them too. A lot of incompetence can just be inexperience, not understanding what the priorities are and getting overwhelmed.
I have never found this to be the case. It is almost always a combination of low ability to learn anything, needing to be told exactly what to do frequently, and eating up lots of other people's time, and none of this improves over time. The other situation I've seen is people who basically do little to no work and make no attempt to really hide it. I've never seen either of these situations resolved successfully, no matter how many times they are moved around, or coached, or allowed to eat up the time of those who get things done.
You are hinting about an important third trait: persistence (effort). I am not the nicest person, nor the smartest, but I am very persistent. This can make-up for other shortfalls. When hiring, if I cannot find highly competent, then I will sacrifice some niceness for more persistence. Never hire people who are low effort / not persistent. Some much of office work is "following up" to make sure that things are completed -- non-managers included. People with low effort will frequently complete tasks to 80-90%, then need to be managed across the finish line.
Edit
About: <<needing to be told exactly what to do frequently, and eating up lots of other people's time>>
I recommend that you Google: youtube casino blueberry muffin
Watch that two minute clip. It ends with this quote: <<Like everything else in this place, if you don't do it yourself, it never gets done.>>
I often mutter "blueberry muffins" to myself when it is easier to do it myself than ask someone (multiple times) to do it, and the results will be incomplete or low quality.
There's an initial phase where a new hire, no matter the level, will require hand-holding, especially if transitioning to a new language of level of abstraction.
Not seeing any improvement points at either a completely broken onboarding process, or sub-par candidates. There's a chance you simply have a poor hiring pool. I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.
There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" (Some use the term "dark matter devs" but I know it has another meaning). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally).
FAANG companies have internship pipelines, with bonus for returning interns. These guys are off the market years before they even graduate.
The sort of competence I think about is more of an innate ability to learn and figure out things on your own. Some people simply cannot do this. They need very specific instructions and hand holding.
They won't read documentation. They won't Google for an answer. They won't look at error logs. They won't browse around in the code to see what other people have done similarly. They won't look at the git history.
You can build experience by doing these things, even if you don't have any. If you are inexperienced and don't at least try to do them... well... that's incompetence.
As long as it's the latter - inexperience - yes. But a lot of the time it's just the aptitude and that cannot be taught (easily). I've seen my fair share of experienced, nice people with less that good aptitude for the job. A year later being nice and teaching, I see marginal improvement at a huge cost. It's not worth it at least in startups. I've also seen many young devs with the right aptitude but no knowledge/experience and they've turned out to be assets within a short period of time.
If you came by your understanding through bone-headed determination, you might have an inkling of how to explain concepts to someone who just doesn't seem to get it.
If you are someone who just 'got it', your ability to teach someone who doesn't might be the limiting factor.
Kinda sounds like what a buddy told me about Michael Jordan vs Steve Kerr.
Not saying Jordan can't make a good coach, but someone like Kerr apparently was better able to coach due to being a specialist and knowing what the roles were and understanding his limits, whereas Michael Jordan – not to say he in any way lacked basketball IQ – just had an order of magnitude more talent than even the cream of the crop (arguably), and was better suited to execution.
Goes without saying though that Jordan was known to just be utterly ruthless on the court, being unnecessarily cruel, and always needing to dominate and win. Which is fun and entertaining as an audience with a bit of distance, but I personally wouldn't enjoy having to be near that kind of personality.
I’ve not found that they can
be taught. An inexperienced person may lack the knowledge of what to do but they can learn to ask, to read a book, to follow the state-of-the-art. An incompetent person will decide they know what to do (or wrongly conclude that that no one can possibly know what to do) and charge off in the wrong direction at 1000 miles per hour.
> A lot of incompetence can just be inexperience, not understanding what the priorities are and getting overwhelmed.
This is the job of the manager to resolve. If that person really is incompetent rather than merely unfamiliar with the work, the manager has access to assets such as hyper-competent nice people for mentoring the less-competent, and should coordinate between the mentor and mentee to lift people out of incompetency.
Both competence and social skills are trainable. A specific shop may not be able to train both, but there are shops that can train at least one of the above.
My last job I could take the most incompetent beginner and make them productive. In my current one, I really can only train that social skill side.
Obviously tail behavior on either end may make training not worth it.
>My last job I could take the most incompetent beginner and make them productive. In my current one, I really can only train that social skill side.
The problem is not the incompetent beginner. The incompetent beginner has potential for future competence.
Incompetent seniors are a bigger issue, since their future potential is usually limited, and they might still have sway due to their seniority. This is especially bad in big bureaucratic companies.
That sounds like a really good place to work, I'm not a jerk, but I want to be a team with "hyper-competent" devs and a good management, are you hiring? if so please ping me root#at#jpg.computer.
Good software developers often expect their peers to also be at a high standard and will speak in very plain, rude, and blunt language if they feel others are not pulling their weight.
Speaking bluntly isn't what is meant by being an asshole/jerk.
What we're talking about here is the completely gratuitous, "I'm so valuable here that I can get away with it" abusive behavior that has no correlation with performative ability.
Yes you have a point, but it's like either we're discussing something obvious and trivial, like a caricature of a person who is just complete asshole abusive toxic diva, or we're discussing the real grey area that is genuinely difficult to deal with.
Luckily I've never hired a completely abusive and gratuitous but competent asshole but yes, I would fire that person as a matter of principle regardless of how competent they are.
But come on, are we really discussing that scenario or are we discussing the much more common scenario like someone who is about as much of an asshole as 2010s Linus Torvalds? Someone who is really competent but gets very impatient with others, has no problem stating rudely that your work is bad, that you keep making the same tiring mistakes over and over again, that you should know how to do certain things by now, that you're expected blah blah blah.
I think that's the more interesting and worthwhile discussion to have and it's the case where for my company, I decided I'll take the asshole over the nice guy.
If they really are a 2010 Linus Torvalds, you just might have a case of keeping them on the team. Unfortunately, 99.99 percent of the people who seem to be trying to be this archetype -- just aren't.
Or we're discussing the real grey area that is genuinely difficult to deal with.
What's so difficult to deal with? You make it plain and clear to them that their competence absolutely does not give them a pass for bad behavior. And that under no circumstances will it be allowed to continue.
I've never hired a completely abusive and gratuitous but competent asshole but ... I decided I'll take the asshole over the nice guy.
What? Mealy-mouthed / "strategically nice, but selectively an asshole" is the most common type actually - and still an asshole.
Respectfully, if you think dealing with people is as simple as delivering ultimatums about their behavior then you likely have not dealt with leading teams of highly skilled professionals.
The behaviors you are describing (and tacitly defending) - continually getting impatient with, and browbeating (not just criticizing) others - are those of overgrown kidults, basically. Not highly skilled professionals.
Those behaviors manifest when you work in high performance environments.
Yeah, if you're on the sidelines in an over-funded environment with little connection to the performance of the business, then you can play tea-party and be nice, and inclusive, and oh so delightful.
But when you've got a critical deadline you need to meet, and some fuckhead decided he was going to slack and cause the rest of us to have to pick up his end of things due to shear caprice, there's going to be strong language thrown around about the situation -- where all patience has already been exhausted weeks ago.
Same shit happens in the Boy Scouts, same shit happens in the military, same shit happens in boardrooms, same shit happens everywhere people go to get stuff done.
[When someone does something stupid, and then people get angry]
That's not what we're talking about here.
But rather: the type of people who basically prefer to be assholes, on general principle. Even when no one is messing up and everything is going perfectly fine.
Then we're talking past each other because our experiences are at odds.
I have never met, what I imagine is, a gratuitous asshole in the workplace.
I've met people who were just all-around cantankerous assholes outside of work, but I quickly distance myself from them.
Maybe it's because I've never worked in a corporate environment -- but only small, close-knit teams where that shit isn't tolerated. Or maybe I've just been lucky, I don't know.
Yes. You’re lucky. They exist, and my first rule of start-ups is “no assholes”.
I’ve encountered true jerks who naturally gravitate towards anger and abuse, and I’ve even worked for a couple of them. It’s quite difficult. When it takes someone energy to keep from getting angry, that’s a dangerous boss to have.
Conversely, what I have encountered more frequently over time is people taking firm refusal to give them what they want (e.g., sign off on a design) as meanness. Firm assertiveness has been conflated with aggression in some contexts. It’s a losing game to be put in an environment with technically weak people where accusations of meanness for holding to organizational standards are given weight. B-players will eventually recognize the crack in the incentive model and get ahead via complaints instead of competence.
There was a point where Jeff Bezos advocated truth-seeking over social cohesion regularly for Amazon, and it resulted in a bruising but brutally effective culture able to attack numerous hard problems effectively.
“Affable” can only get people so far in a productive enterprise, but it’s just no fun to work with a jerk. Jerks and mediocrity are both ways to kill teams.
Yeah the corporate world is absolutely full of such people.
Granted, it usually isn't premeditated; it's more likely to be of the reactive / passive sort. Some form of: "Oh I'm having a bad day, so I'm going to spontaneously get salty at you over something completely non-consequential, or in fact, over an outright, and frankly pretty thick-headed misunderstanding on my part. Not that I'll ever apologize, though. Oh and good luck trying to go over my head to get one out of me."
That sort of thing. Less frequently, outright nasty and career-damaging (and sometimes health-damaging) stuff happens too.
Such that at some point, one realizes that, to a large extent -- putting up with this nonsense is what the gig is all about, and what you're essentially getting paid for.
I wouldn't be so sure about that, speaking directly/bluntly often gets you labeled as a jerk these days. I'm over it though, people are going to hear what they need to hear, whether that makes me a jerk or not.
> What we're talking about here is the completely gratuitous, "I'm so valuable here that I can get away with it" abusive behavior that has no correlation with performative ability.
Can you give a concrete example of this behavior? I'm sure I can think of some, but I'd like to be more clear on what you had in mind.
Then there are all kinds of examples not specific to matters of pure and simple rudeness (e.g. all manner of politicking, manouevring and bad-mouthing that goes on), as well as not defending / standing up for others when you should, etc.
There have been plenty of serious articles written about this topic; the search term to look for would be "workplace hygiene", which is the somewhat more formal description. ("Toxic work environments", "workplace bullying" also work but tend to be more second-hand, and sometimes spammy).
> competent people tend to prefer to work with others whose skill they respect and they feel they can learn from because they're really good at their job
Amen.
The #1 "perk" any company can offer is working with a skilled, competent team.
In my experience teams taking on significant challenges benefit from having a range of contributors. Thoroughbred racers have their place, but there are times when having a big and heavy load puller or even a small donkey or pony is just the right fit.
The really fast moving types don't like finishing every detail of the test suite or documentation and get bored with customer feedback and meetings. They are super mega A grade ten plus ex contributors and they know what that entails, so they are always on the forefront picking up the best tools, honing them as needed, and then moving on. They know how to take credit for their lead also.
Meanwhile more modest contributors handle details and it is less easy to quantify the value of actually running through the product with customers and finding critical bugs, catching embarrassing errors in documentation, or filling in important missing test cases and so on. Some products do okay without all the i dotting and t crossing, but too much reliance on the cutting edge of tech leadership tends to show up over time in tech debt and accumulated bug overhead.
As is said, you may be capable of great things, but life consists of small things.
The only competent jerk I ever worked near (different part of a very multi-disciplinary org) probably wasn't that competent. That is, they had a habit of belittling other people's opinions and performances, but they were eventually fired for running a system outside of safe bounds, ultimately destroying some equipment and product. They were not as brilliant as they thought themselves to be, and eventually that disconnect caught up with them. It's only hubris if you're wrong.
I have known a lot of insufferable people who were the only person at the company who could do what they did, but they weren't brilliant, per se. They just focused on building a moat rather than building a community. And because of that, they never really progressed past the little niche they had made for themselves (and the organization didn't need them to, so it was fine). The brilliant asshole recognizes the utility of at least having other brilliant assholes around, and so invests at least some effort in baseline social grace.
I'd wager that there's something akin to the Dunning-Kruger "mount stupid" at work here. That is, your probability of being a jerk peaks at some slightly above-average level of competence, but tapers off as competence increases, because the confidence becomes justified. Confidence can be abrasive, but hubris is always caustic.
Systems (set up by people) can definitely multiply. Say a well-oiled review, CI+CD, deployment system can def multiply everyone's productivity by some margin (e.g. 1.2x). So if someone improves this system, it can definitely multiply everyone's in the team's productivity.
We can’t truly test the edge of this function without finding the most least competent person ever. They’re like a perfect anti-classifier!
I’ve actually worked with people who were so persistently wrong that we could generally take their assertion or approach (and they’d almost always be the first to raise a finger to start dropping knowledge on us) as definitely not the right answer, thinning the search space by one option.
It was actually kind of amazing. The one (seriously, one) time one was right about something, the room was stunned.
That said, they did not increase productivity, so we need to search for someone more perfect…
One of the hidden downsides of this approach that I never see discussed: The competent jerk that chases off employees is going to shape your codebase and company in their image. This isn't something that may be immediately apparent, but when you start running into design walls where said competent jerk does not want to budge, then the costs of having such a person become a major problem. Especially if they decide to leave and take their knowledge of the system with them.
> The really difficult choice you end up facing is someone who is nice and gets along with people but is ultimately too dependent on others to do their job
Importantly, getting rid of someone like this can actually _improve_ productivity
with a lot of hesitation and even regret I agree with this assessment.
obviously, it's a matter of degree, but competence means paying customers because their output is externally visible and incompetence - nice or not - doesn't.
Now of course we can always exaggerate things to an extreme and compare a racist, sexist, jerk who swears nonstop, to someone who is mildly incompetent, and there are certain principles and boundaries that are worth upholding with respect to how people treat each other regardless of their productivity, but in actuality that's not really the difficult choice you end up facing.
The really difficult choice you end up facing is someone who is nice and gets along with people but is ultimately too dependent on others to do their job versus someone who works independently and does an excellent job but is very blunt and can be an asshole in regards to the expectations they hold others to. Good software developers often expect their peers to also be at a high standard and will speak in very plain, rude, and blunt language if they feel others are not pulling their weight.
And finally, I have observed that in the long run, competent people tend to prefer to work with others whose skill they respect and they feel they can learn from because they're really good at their job, compared to working with someone who is pleasant but is always dependent on others. Being nice is a good short term skill to have, but people get used to those who are nice but they never get used to someone who is incompetent.