Summary of answer from both common sense and the article: Yes. I suspect the answer would be the same if the question were simply "do good manners matter?", but that is probably much harder to study. This is not meant to diminish the study; confirming seemingly obvious things is important.
It's not necessarily an obvious conclusion. Many people look at the success of Linux and of Apple under Steve Jobs and conclude that a rude leader is a positive.
One wildly successful rude leader gets thousands of times more attention and consideration than the thousands of amiable managers who do their jobs well without hurting people's feelings.
In both the case of Linus and Jobs, they aren't/weren't reviewing everyone's code directly. It's possible to work on Linux and work at Apple without enduring the wrath of the very top.
Well those people are obviously wrong :). Joking aside, point taken. One of the reasons it is important to confirm "obvious" things is that one person's "obvious" is another person's "clearly wrong".
I will say that I think the reason the "rudeness as a positive leadership trait" thing gets so much attention is because most people expect it to not be the case. Non-intuitive things tend to make for better stories.
If you had bothered to at least read the abstract, you might have found that there is no claim that projects like that will always fail, as you insinuate. The authors merely claim that politeness is positively correlated with with a number of key metrics like time required to fix an issue and duration of project participation.
I tend to draw a distinction between "impoliteness on its own" and "impoliteness in response to impoliteness". Not reading TFA is, to me, the latter, and a mildly sharpish response isn't the worst thing in the world.
This result is going to be abused by people whose ideas of good manners a) don't cover themselves because hello important work and b) are essentially a demand for deference.
Unfortunately true. A lot of the people talking the most about good manners and civility in software development turn out to themselves spend a lot of time bullying and insulting those they disagree with, and a lot of the requests for politeness are actually thinly disguised demands for political litmus tests, backed up with threats of online mobs for those who don't fall into line.
This is a pity, as I'm open to being convinced that a more polite and pleasant environment is also better for productivity, but that well has been thoroughly poisoned by its loudest advocates.
Intuition on this issue is not that politeness in itself matters, but that politeness would be correlated with patience. Patient development schedules are likely to result in less technical debt, fewer defects, and greater long-term throughput.
People are less creative when they feel disrespected. If you're running a military or places like UPS, where your work value can be boiled down to time and motion studies, it makes a ton of sense to break down people's sense of self: they are being asked to become machines, after all.
Torvald's recent screed on Management via perkele, where rudeness is encouraged, interestingly, was born from his time serving in the Finnish military. Could Linux be even better if he dropped this mentality? Maybe. He insists that by being rude you stop tacit political behavior which would undermine technical excellence. But this seems contradictory. Management by perkele is by definition a form of tacit politics.
The Linux project is probably not the best place to look for this sort of thing. It's huge. It's completely plausible that a project big enough to have multiple layers may have different optimal levels of politeness in those different layers.
It's also plausible that larger projects may simply not be able to function with total politeness, as they face threats that smaller projects can only dream of facing. Even if you've only followed the kernel development via HN over the years, you've heard of any number of instances of someone who has a very strong opinion about where the kernel should go, and basically can only be fended off with a flamethrower. Sometimes the fault lies not in the person wielding the flamethrower, but in the person who would not be dissuaded by anything less. (That's a general comment, not about any specific controversy.)
It's also possible that Linus' attitude is a complete disaster, that the only reason the project is successful is a major case of right-place-at-the-right-time, and in the parallel universe where Linus is a perfectly polite person Linux is much farther along.
Again, my real point is that the outlier projects may not be the best places to look, because they intrinsically live in environments very unlike the environments most open source projects live in.
However, your argument is not what Linus himself has emphasized. He emphasizes that his abrasiveness comes from the idea that people must earn respect. Which is more than just wrong, it's completely idiotic. If life were about earning respect, what are you supposed to do if people disrespect you? Aren't we right back to marching from Selma to Montgomery?
The civil rights movement, in which people wished to, eg, not be lynched vs mean words on the internet. Below you compare similar mean words to actual terrorists fresh from murdering hundreds of people in Russia and France, not to mention random civilians stuck inside their territory. Good analogies.
It occurs to me that you might be touching on the difference between "earn respect" and "earn freedom from disrespect".
Also, the need to distinguish what different respects mean. There is respect as a person, versus respect as a knowledgeable kernel developer.
(They are not always easy to separate. If someone keeps pushing their bad development ideas even though they have been thoroughly debunked, just because of their ego, I think my respect for them as a person will drop somewhat not only as a developer.)
Still, the default toward some new person should be: basic respect as a person, neutral as a developer. I think that this is the case in the OSS project model; but then where it breaks down is that if the latter respect tanks, then the former does also. I.e. you're a good person if you're a good hacker (in particular one with mostly the same opinions as me), otherwise you're non grata scum.
Yes of course. I would prefer if Linus made the distinction you're making by actually saying something like "respect as a programmer" But he didn't do that.
When you program something correctly, it's expected to be correct to the keystroke. Here I think we should be able to expect correct to the point of distinct idea which is not what's coming across. It's almost to the point where Linus appears as an old man from pre civil rights days about things.
> When you program something correctly, it's expected to be correct to the keystroke.
Are you saying that this is the philosophy Torvalds holds? If you are not, then please disregard the rest of this paragraph (and, if you have the time, please let me know what you did mean.). If you are, then I'mma slap a big [citation needed] on that comment. While searching for that citation, do keep in mind that writing code for OS kernel is usually going to require much more in-depth knowledge of how a compiler optimizes things and the like than writing code for some CRUD application. This means that -not infrequently- single-character errors do have substantial significance.
Uh, It sounds like we're in violent agreement? What I'm saying is that if you code it wrong it's completely wrong, even if it's only off by one keystroke. There's no guessing. Computers aren't flexible in interpreting what you're writing. I don't think this requires a citation from Torvalds. It's just a fact.
If this differentiation is actually being made, then why is Linus making comments saying "he's surprised [this developer] is still alive, because they are too stupid to find food", or "should be retroactively aborted".
These comments, hyperbole or not, definitely give the impression that there is no real distinction being made.
Its once more the media thats producing a distorted image by only reporting the few times he brings out the big guns.
And invariably when he does so, the issue has been bouncing around on the mailing list for some time, holding up developers, and he is basically there to clear out the blockage and get development moving again.
It's not a caricature if it's his own words. His culture? What a lame excuse. Daesh has a much more abrasive culture than the US. Does that make Daesh culture OK? Where do we draw the line?
You can reductio ad absurd. most positions to make them seem silly, but the cultural variation argument is a very valid one.
Most Germans I've talked to about the topic are somewhere between bemused and horrified about many aspects of US culture. Here's a sampling:
* We have -comparatively- a very high burden of proof for slander/libel.
* We do not require internet publications to have a byline positively identifying the author.
* We do not make it a crime to fail to register with The State every time we change home addresses.
* We permit -comparatively- incompetent people to operate motor vehicles.
I gather that USians are not infrequently similarly affected by German attitudes towards free speech restrictions, public sexuality, credentialism, anti-gun-ownership hysteria and the like.
There are a wide variety of cultures -bringing an even wider notion of what "proper" behavior looks like- even amongst people who live in the same country. Surely you're sufficiently worldly to understand that. :)
Sounds in line with my experience of open source interfaces and GUIs. Generally technically deep and absolutely uncreative and unintuitive to the right-brain.
They are services created to have a featurelist with only a passing regard to aesthetics, and even less thought towards usability. They always answer well to "well does it do x", but almost never positive to "how does it feel to use?".
People are less creative when they feel disrespected? Wow, okay. I beg to differ, I have seem people get more creative when disrespected because they feel they have something to prove and are competitive.
There is no right or wrong way. We live in a very sensitive society. It is very easy to offend people by asking them to do their work these days.
If you have a problem with someone's code, tell them about it, and be an adult about it. I've read Linus' numerous public outings of what he thinks are less talented developers, and it's childish, end of story. Nobody works well in that environment.
It's a simple cost/benefit thing for me; the costs are you lose talented developers who may be more sensitive to criticism, which people like Linus say is a good thing because apparently the quality of your work is partially determined by your ability to handle assholes. The benefit side is you get to act like a child publicly and not be treated like one. The cost doesn't come close to justifying the benefit.
In short: Linus and everyone like him need to grow up.
Does the difference between someone thinking that I'm wrong 100% of the time vs. being wrong at one particular incident make it better? Certainly. It's still rude and childish, but I'd certainly rather have a singular incident stomped on than my entire character tarnished.
If he's going to treat you as shitty whether you made a single error after a long, long time of perfectly competent contributions or you write code that reads like you typed it with your face all the time, then I really don't think it makes a difference.
The classic Linus tirades I've read are the result of the person he's addressing, who knows less about the project at hand, not accepting his reason for a particular decision he's made and continuing to press the issue.
He's not a bear, he's a person, and should be expected to act accordingly. I have coworkers I argue with on a regular basis and yes, things get spirited, that doesn't give you license to be an asshole.
If someone makes repeated bad code contributions aren't they then actually hurting Linux rather than helping it by tying up a talented dev from being able to do actual useful work.
Everyone has this idea that all patches are beautiful snowflakes and everyone's effort is just as good as everyone else's and such. But there's no reason to suspect that there aren't some un-talented people that want to work on the kernel and that they could waste a bunch of time by demanding that everyone explain why they're wrong, politely, and at length.
Sometimes for volunteer projects to succeed, not everyone gets to participate. I think it's interesting that people who say "lived experience is the ultimate truth, full stop" then armchair quarterback another person's lived experience, without having lived it.
I'm not talking about polite, sweet n pretty, hey buddy let me help you out. I'm talking base line, standard, up front and direct as the subject requires and as something like kernel development most certainly does.
However, you should be expected to be able to carry on a conversation that wouldn't be confused for a transcript of a 12 year old boy on XBox Live, calling people retards and morons.
If you find code of mine that's shitty, great. Tell me about it. You can even come up to me and say "hey pal, your code here is shit." Fine. You call me names, or you attempt personal shots at me over it, we're done.
This is true for me as a professional, and would be excessively extra true for open source. People contributing to linux are volunteering their time and talent to work on something they believe in, and quite frankly, that those efforts are met with attitudes like those expressed by Linus and Linux still having ANY contributors left is amazing.
I don't care how much you believe that talking like an adult doesn't matter, I would bet every cent I had that if he were at least cordial, linux would be far ahead of where it is now.
> I would bet every cent I had that if he were at least cordial, linux would be far ahead of where it is now.
Again, you're basing this on the assumption that the talented devs far, far outweigh the untalented ones and that you 100% want any and every contribution. I don't believe that either of those assumptions necessarily holds.
Expected by whom, exactly? The targets of Linus' ire aren't his colleagues, they're developers with unfounded opinions and more often than not, little experience with the kernel. If someone publicly stated:
"Why did you use C for the kernel? You should've used C++.",
I chose to ignore it, but having read it now, I still think the same way. Just because some thinks differently than you, makes different trade-offs and has an unfamiliar way of behaving, doesn't mean they're childish.
It's not unfamiliar or different, it's extremely familiar. Like when you get an answer wrong in class and one of the other kids goes "HA HA Dummy!" His intent is clearly not to help you learn something or to simply state you're wrong, his intent is to elevate himself at your expense.
The word to describe this, among many other behaviors, is to act childish.
Who cares? What purpose does it solve? What end do we work towards by berating someone publicly instead of simply acknowledging the error and moving along with the fix? What is accomplished with public mocking that is accomplished with a professional note?
There is one thing, and only one thing that is different; one gives into ego, one doesn't. I take ego out of my work because involving ego in work is the best way to ensure shitty work is done.
I've never once questioned his competence, he's clearly great at what he does. But you could be the best software dev on the planet, you act like that toward me, there isn't enough money on the planet to make me work with you. I'd sooner change careers.
Interesting. I guess it comes down to personal preference. Would you rather work with somebody exceptional but abrasive, as opposed to somebody average but nice? I think many people would choose the former.
I think the reason exceptional people are abrasive is that they are primarily harsh to themselves, and that's the reason of their success. Being harsh to others is merely a side effect.
And there are people like that in every profession, for example in modern magic Dai Vernon (one of the most respected magicians that ever lived), who was also infamous for being very critical to bad magicians.
Abrasive and abusive are too very different things. Linus frequently slides into the latter. Abrasive, to me, means if you do something stupid you'll be called out and told what's wrong. Abusive is when that conversation turns into name calling.
You can be as hard on yourself as you please, and we are often our own worst critic. When those complaints let fly to other ears, they should be phrased a little better.
Again, your preference may vary. Me? I work with adults, I don't care how good the other kids are.
> Abusive is when that conversation turns into name calling.
I don't think so; it depends on context. If someone calls you names in context of you doing something stupid, then it's not abuse, it's just being abrasive. Abuse would be had he done it without you giving a reason. And I think we should save the word abuse for the latter (and also perhaps for something where is a profit motive).
I mean, every post from Linus where he uses harsh words has some context like that. He just doesn't randomly throws insults to his colleagues. You can read the insults as an abuse or you can read them as a big yellow warning signs - your choice.
> When those complaints let fly to other ears, they should be phrased a little better.
Here the "should" is a cultural choice. It's a universal, safe option. It's like being polite to people you don't know, or being diplomatic in diplomacy.
But in the cultural context of kernel development, you're already part of the in-group. And in that particular in-group, being called names is normal and accepted by the insiders. That it happens on the Internet, for the outsiders to see, doesn't change the fact that the cultural choice was made freely by insiders.
And people who prefer the former to the latter (as per my previous post) probably don't care to much about being called names when they do stupid thing (being abused, as you call it, but they actually don't want to be really abused or tolerate it either) - because with that mentality, it's results or your own improvement that matters, not so much who is polite. I think Linus would be OK if other people called him names when he does something stupid, however it doesn't happen mostly because people respect him and he doesn't do stupid things very often.
Abusive can also be a result of continued and systematic unnecessary comments and critiques of irrelevant things. I agree that we should be tactful and careful with complaints and criticisms of others, it's very easy to say things without enough forethought and damage a relationship.
I would love to get paid to work for Linus. I'd feel bad if I got fired, but I would not feel bad if he harshly criticized my shitty code. I'd be enthusiastic about the fact that my skills were about to be honed sharply because all the sudden the standards are raised extremely high. Insults don't really matter to me as long as a legitimate criticism is in there somewhere. If it was just "you're awful, go away" with no technical points, that's a different story. But in that event, it's easy to respond: "Did you have any actual criticism of my code? Pretend that I can't read your mind, and explain the problem to me."
I agree with you 100%. I actually turned in my 2 weeks notice at the development shop I was at over this, yesterday was my last day. Systematic bullying of junior devs by the manager, a culture of "because I said so" from the top down (especially when the management was wrong and could have listened), and just general incompetence led me to get the hell out.
Developing software is almost always about building things for other people to use. It's inherently a social thing, and if you can't play nice with others, you will alienate and run off developers. Of course, there's a difference between getting your code critiqued in review and being treated like a child because you wanted to automate a build. I assume developers are smart enough to know the difference, though.
And I've learned something about Linus: he values that feeling (of power?) he gets from "verbally" abusing people, and is smart enough to get himself a job where he gets to do it whenever he wants.
The results don't surprise me but I do think there is more than one way to have a thriving development culture. While not mutually exclusive, I think blunt/transparent environments are just as, if not more effective, than polite environments.
A blunt environment requires a certain level of professionalism but actively knowing you will be challenged when its called for and knowing everyone is simply striving to do whats best for the cause can be really refreshing.
I'm known to request that people tell me when I'm full of shit. I'd much rather have a moment of subtle hostility than a stretch of time where I operate under false assumptions. Once people acknowledge it's not personal, it allows everyone to move much faster.
I can appreciate the need for gut checks, and have asked people for feedback so I can get a better idea of how I'm being perceived. But the burden of knowing when you're full of shit should really fall on the individual. So to that end I think we should all strive to be conscious of how our words and actions affect those around us and the task at hand, instead of relying on someone else to rein us in.
I think it may be a good thing to agree on what good manners are. I almost wish there was some sort of standard practice on this.
I know when I was starting out my career I had no idea what good manners were. One time at a milestone review I simply said: "I had to rewrite X's first pass he was using some older tech and there's better ways of doing it now." and it really blew up. My boss took me in his office afterwards and told me that probably wasn't the right thing to say that I had in fact insulted the other guy and he was hurt. Believe me it was never my intention to hurt anyone I was just stating what I did and what I knew. I apologized and we got along afterwards no harm in the long run.
That incident taught me to always be wary of corrections or talking about someone else's work. They put their heart and soul into what they do and I should respect their code and them.
It is people that put their hearts into the work that made great things. Being polite should a technique rather than principal; if deeply in one's heart it is to make a great product. Also, when it's appropriate why not be rude to make things moving? Isn't it like the relationship of summer sunshine and winter snow; people perceive things based on different perspectives, as long as it's a natural reaction, why should we bother. I'd rather take candor rudeness than seemingly polite pretending. But of course, vice versa.
> I simply said: "I had to rewrite X's first pass he was using some older tech and there's better ways of doing it now." ... My boss ... told me that ... I had in fact insulted the other guy...
...what? The other guy is too attached to his code.
> [People] put their heart and soul into what they do and I should respect their code and them.
One thing that every good programmer has to learn to do is to be able to disentangle one's ego from one's code. It's verygood to be proud of one's accomplishments. It's bad to become so attached to one's work that one suffers injury from criticism of or attempts to improve the work.
If you love your code too much, it'll be harder for you to see (or let others help you see) where it needs improvement and when it needs to be thrown away.
Is it really shocking that people's feelings about things are closely tied to motivation? My level of motivation absolutely plummets when someone is mean to me. It doesn't matter if they were right or whether it was deserved or not. People need to take people's feelings into consideration when they are making comments on other's work.
My motivation rises when people piss me off. I have something to prove, the best way I can say "fuck off" is by working hard and proving you wrong.
Telling me the truth might hurt my feeling but that is not disrespectful or rude. If I fuck up, tell me so. If you work with me, I'm not going to take your feelings into consideration when making comment's about your work. I'm going to take your experience tho. If you are new, I'll be gentle. But if you have doing this for a long time and should know better or/and like to act like you know it all, you have it coming!
* Of course you are not obligated to respond at all or in a timely manner, but if you do, it's a real treat for the person filing an issue.
* Respect the other person's abilities and skills. When troubleshooting, use language that recognizes the abilities of the other person. For example, instead of "Did you read the documentation?" say "Can you double-check the documentation, especially the section on ____?"
* Keep issues open until the person who filed the issue feels like their problem is resolved. Of course, if the person does not respond for a long time, then there's no harm in closing the issue.
* Get invested in the user's use case. Perhaps this is a "won't fix" scenario, but to truly understand that the issue is out of scope, you should understand exactly what the user needs, up to and including suggesting an alternative solution that is not your software. Sometimes when doing this you realize that in fact the user was correct and their problem is in the scope of your software.
* Be ready to embrace humility. It is common for a user to stop by and drop a piece of information that makes you realize you made a design choice long ago that would be costly to change, both in time and emotionally. At this point you have two choices: humbly admit that you made a mistake and that your software has a limitation due to the mistake, or, humbly admit that you made a mistake and that you'll be working on fixing this mistake in the next major version bump.
* Don't leave code rotting in the main development branch for a long time. Release that code!
* When someone submits a patch, don't nitpick the code conventions. How hard is it to change tabs to spaces and rename a few variables? If the idea behind the code is sound, just merge it and fix the conventions yourself. Style conventions are arbitrary and meaningless. Reduce the friction here for people who bother to look at your source code.
* When you feel you do not have the resources to continue maintaining one of your projects, but users are still filing issues and sending patches, try to hand off the maintainer hat to someone competent. Keep the project alive!
* If your software has a bug, but it's the fault of one of your dependencies, keep a bug report open in your bug tracker too, with a link to the dependency's open bug. Your dependencies' bugs are your bugs too.
I'm sure there are more; that's just what I thought of off the top of my head.
sometimes people get away with being assholish when they are the best at something in a group. but to combat that tendency in yourself, just remember what you would look like if someone showed up who was better than you, and not an asshole.
In this thread I see a few comments assuming that polite VS blatantly rude are the only options. If for "polite" we mean, accepting bad contributions, ideas, code, yep that's a problem, but to refuse contribs that don't match the idea of the person in charge of a project does not need to be as bad as we see in certain cases. It is possible to say negative things about ideas or code in a decent way and very firmly at the same time, without attaching persons, and without creating an environment where new ideas are limited since, well, you are going to be insulted if your idea is less than excellent. A couple examples:
Behavior A: This code is a good example about how you should never write code, it's going to explode in the hand of users, it's going to make our project a piece of crap. Please don't do that, how many times I've to repeat that... you are a long time contrib, it is unacceptable you send me such a crap of stupid patch.
Behavior B: Sorry, I think the patch is not good because it does not test correctly for <some-technical-reason-here>. Without this check the code works today but may fail tomorrow. Because our project needs an high level of stability, we can't merge such a contribution. Please could you review it or perhaps even rewrite it in a way that's going to be very stable? Thanks.
I think both A and B send the same message, but with "A" the problem is that the contributor may never return back or may be offended. Life is already tough, there is no need to be offended randomly because you are trying to give code for free.
We have a tight deadline. Why don't you approach this by doing x and y. After we're finished and have production code deployed, you can refactor into z.
In the process of implementing x and y, the developer will soon learn that z is inferior. If he doesn't, you need to get rid of him because he's incapable of learning.
B doesn't send the same message, there are too many weasel words, and rather than being polite, comes off as giving the other person authority. I think.
Here's how I would phrase it: "Thanks for the patch. How does your code deal with condition X? We're a big project that needs to consider the needs of users under many different circumstances, so even if it seems like X only happens in 1 out of every 10,000 cases, that means it happens every five minutes to one of our users somewhere in the world."
The idea is that you know the contributor didn't check for X, but you're giving them the option of saving face. You just asked them whether they considered such a condition and explained why it might be important.
Edit: and if they did consider X, they can explain why their solution is okay. You could be wrong in thinking that it's not.
There are people out there who will take your politeness and use it against you like a weapon. Telemarketers, for one. The only way to get off the phone is to interrupt them and unilaterally end the conversation.
Fake monks are another good example. They ask you a question, like "what do you want most in the world," which you answer just to be polite. They then write your answer on a token, and give it to you. You feel obligated to accept it because they made it just for you. Then, they ask for a donation in return for the gift you just accepted. Again you feel obligated, this time because you accepted their gift.
The entire thing depends on your polite response to each of their actions. Unless you know where they're going with this, it's impossible to politely escape. By the time I was handing over the money, I knew it was a scam and I still gave them $10 because I felt stupid.
While I have never personally had cause to be impolite during my professional work, sometimes politeness is an improper response.
Influence scams are no reason to skip on politeness. The scams use a few well known psychological switches. Once you realize you are being under a dishonest influence attempt it is very easy to disconnect from the process - still politely, if firmly. I suggest "Influence" by Robert Cialdini as a well written general survival guide against the influence artists of the world and as a guidebook as well..
I think the more useful way to look at his comment is that similar tactics as these "influence scams" can be used within projects. I've personally found it difficult sometimes to walk the line between bluntness and rudeness. There are going to be instances where a co-worker will continue down the wrong path or make the same mistakes or just not conform to the proper design philosophies or decisions, but things will keep stalling during any polite discussion as they keep walking around the issues while you try to come to the correct decision that they don't want to do (either through ignorance or perceived excessive effort required). At the end of the day, you can't always rely on your manager to step up and say "you are wrong, do it the other way", and informing a stubborn co-worker that their work/decision is stupid can be difficult to do politely if they engage in delaying or obstructive tactics.
A lot of comments are voicing opinions about politeness, but I'd like to focus on the study. In particular, I'd like to disagree with the conclusion. If you look at their stats and box plots, its a mess. They should run the Wilson test on all their data, not split it up by project. Also, the effect size is miniscule. In a couple of cases, it's negative, though p > 0.05 for those.
Before reading this study, I thought politeness helped fix issues faster. Now, I'm of the opinion that it has little or no effect. Of course, polite discourse is more pleasant, so I'll continue to be nice when communicating.
I should go further. There is a significant amount of data that doesn't work well with their conclusions. I also find the example of "impolite" comments hilarious. It seems to be detecting the imperative vs. detecting impoliteness.
This study doesn't account for the "good cop bad cop" tactic many projects run.
Politeness is maintained on the mailing list, but undesirable posters are tracked down and bullied behind the scenes where proof who's doing it is difficult. This happened to me 10 yrs ago when I started posting casually on a mailing list for a new programming language. I've found overall (not by statistical analysis, but by personal impression) that this tends to happen more when the project leader has a management rather than technical background. Many open source contributors learn their skills in paid employment first so the political skills of online project managers are often more developed than what you find on the job. And because open source contribution is far more global and with a more permanent record than a local job somewhere, the effects are often long-lasting for those involved.
In such good cop bad cop behavior, maybe the real situation tends to show itself over time, just as shown in the study. That project I was trying to politely join has evolved into a blatant "smoke and mirrors" environment that few people trust.
You're right, and they do acknowledge this to some degree in section 5 ("Threats to Validity"). The projects they monitored were unaware of having been so, therefore the authors would have had no way to observe much nuance. They could only what was publicly visible.
Actually that's standard management training: don't criticize people in front of everyone. Talk to them offline, and it's less likely to result in a big fight.
Maybe it can be misused, but it still seems like a good idea.
The effect doesn't seem that clear. That it varies from project to project makes me believe it's just some weak correlation.
They should have tracked developer retention to those projects. People might still contribute and fix issues if someone's being a jerk, but are they going to stick around and contribute further? That's the real question to me.
Someone actively contributing for a project for years is much more desirable than someone doing drive-by PRs.
I don't think it's about the surface politeness factor, but about what kind of discussion is conducted.
The ideal for an intellectual discourse is to have questions be responded to with more questions. If question is met with answer, then old ground was covered, there was nothing new to see. If answer is met with answer, you're just ramming into each other. (And yes, there are disingenuous questions, but those tend to be "Jeopardy answers".)
Politeness/rudeness does factor into that in that it "bulks up" the rhetoric. You can be a polite bullshitter or an insulting truth-seeker. You can use rhetoric tactically to goad the other person into the questioning mode, or you can use it to shut down the discussion.
Thinking that you have "politeness capital" that you can "spend down" by being occasionally impolite is very wrong.
I've run into people that I refuse to work with, ranging from choosing not to do projects with them to trying really, really hard not to ever have contact with them again, by any means.
I have probably been a guy that people avoided. It sucked. My advice is that, in the long game of doing stuff with other people, being professional and polite is worth it.
Looking at the names being named, rudeness seems to come with being foreign. I guess Steve Jobs is a counterpoint in that he is at least second generation.
Politeness is a nice thing to have, in theory, but any attempt at enforcing politeness is a tax on creativity.
Human processes are extremely imperfect and subject to all kinds of biases and conflicts of interest. The cost of attempts at enforcement will be huge and not immediately obvious to everyone. It will silence dissent. It will create chilling effects. It will alter the balance of power towards the rules-lawyers and away from those that just want to get their work done.
I am against any sort of standard here for the same reason I am against government censorship: because it will be turned around and used against us as a weapon, for reasons that will have nothing to do with improving productivity and everything to do with some petty squabble for territory and influence.
98 comments
[ 2.0 ms ] story [ 199 ms ] threadI will say that I think the reason the "rudeness as a positive leadership trait" thing gets so much attention is because most people expect it to not be the case. Non-intuitive things tend to make for better stories.
Are those projects successes despite their manners?
This is a pity, as I'm open to being convinced that a more polite and pleasant environment is also better for productivity, but that well has been thoroughly poisoned by its loudest advocates.
Torvald's recent screed on Management via perkele, where rudeness is encouraged, interestingly, was born from his time serving in the Finnish military. Could Linux be even better if he dropped this mentality? Maybe. He insists that by being rude you stop tacit political behavior which would undermine technical excellence. But this seems contradictory. Management by perkele is by definition a form of tacit politics.
Torvalds position: https://www.youtube.com/watch?v=JZ017D_JOPY
Other points of interest:
https://hbr.org/2013/01/the-high-cost-of-rudeness-at-w/
https://hbr.org/2013/01/the-price-of-incivility
It's also plausible that larger projects may simply not be able to function with total politeness, as they face threats that smaller projects can only dream of facing. Even if you've only followed the kernel development via HN over the years, you've heard of any number of instances of someone who has a very strong opinion about where the kernel should go, and basically can only be fended off with a flamethrower. Sometimes the fault lies not in the person wielding the flamethrower, but in the person who would not be dissuaded by anything less. (That's a general comment, not about any specific controversy.)
It's also possible that Linus' attitude is a complete disaster, that the only reason the project is successful is a major case of right-place-at-the-right-time, and in the parallel universe where Linus is a perfectly polite person Linux is much farther along.
Again, my real point is that the outlier projects may not be the best places to look, because they intrinsically live in environments very unlike the environments most open source projects live in.
However, your argument is not what Linus himself has emphasized. He emphasizes that his abrasiveness comes from the idea that people must earn respect. Which is more than just wrong, it's completely idiotic. If life were about earning respect, what are you supposed to do if people disrespect you? Aren't we right back to marching from Selma to Montgomery?
Also, the need to distinguish what different respects mean. There is respect as a person, versus respect as a knowledgeable kernel developer.
(They are not always easy to separate. If someone keeps pushing their bad development ideas even though they have been thoroughly debunked, just because of their ego, I think my respect for them as a person will drop somewhat not only as a developer.)
Still, the default toward some new person should be: basic respect as a person, neutral as a developer. I think that this is the case in the OSS project model; but then where it breaks down is that if the latter respect tanks, then the former does also. I.e. you're a good person if you're a good hacker (in particular one with mostly the same opinions as me), otherwise you're non grata scum.
When you program something correctly, it's expected to be correct to the keystroke. Here I think we should be able to expect correct to the point of distinct idea which is not what's coming across. It's almost to the point where Linus appears as an old man from pre civil rights days about things.
Are you saying that this is the philosophy Torvalds holds? If you are not, then please disregard the rest of this paragraph (and, if you have the time, please let me know what you did mean.). If you are, then I'mma slap a big [citation needed] on that comment. While searching for that citation, do keep in mind that writing code for OS kernel is usually going to require much more in-depth knowledge of how a compiler optimizes things and the like than writing code for some CRUD application. This means that -not infrequently- single-character errors do have substantial significance.
So we are! I -somehow- completely failed to understand the subtext in your statement. :(
Mea maxima culpa. Please disregard my stupidity.
These comments, hyperbole or not, definitely give the impression that there is no real distinction being made.
Its once more the media thats producing a distorted image by only reporting the few times he brings out the big guns.
And invariably when he does so, the issue has been bouncing around on the mailing list for some time, holding up developers, and he is basically there to clear out the blockage and get development moving again.
edit:
Here's another video that does a better job of conveying his reasons for being the way he is.
https://www.youtube.com/watch?v=MShbP3OpASA&t=35m41s
He's also been on record as saying multiple times that a lot of it is because he comes from a culture that's much more abrasive than US.
You can reductio ad absurd. most positions to make them seem silly, but the cultural variation argument is a very valid one.
Most Germans I've talked to about the topic are somewhere between bemused and horrified about many aspects of US culture. Here's a sampling:
* We have -comparatively- a very high burden of proof for slander/libel.
* We do not require internet publications to have a byline positively identifying the author.
* We do not make it a crime to fail to register with The State every time we change home addresses.
* We permit -comparatively- incompetent people to operate motor vehicles.
I gather that USians are not infrequently similarly affected by German attitudes towards free speech restrictions, public sexuality, credentialism, anti-gun-ownership hysteria and the like.
There are a wide variety of cultures -bringing an even wider notion of what "proper" behavior looks like- even amongst people who live in the same country. Surely you're sufficiently worldly to understand that. :)
They are services created to have a featurelist with only a passing regard to aesthetics, and even less thought towards usability. They always answer well to "well does it do x", but almost never positive to "how does it feel to use?".
There is no right or wrong way. We live in a very sensitive society. It is very easy to offend people by asking them to do their work these days.
It's a simple cost/benefit thing for me; the costs are you lose talented developers who may be more sensitive to criticism, which people like Linus say is a good thing because apparently the quality of your work is partially determined by your ability to handle assholes. The benefit side is you get to act like a child publicly and not be treated like one. The cost doesn't come close to justifying the benefit.
In short: Linus and everyone like him need to grow up.
He doesn't. He just thinks they're in the wrong _that one time_.
If you poke the bear, expect to get mauled.
Everyone has this idea that all patches are beautiful snowflakes and everyone's effort is just as good as everyone else's and such. But there's no reason to suspect that there aren't some un-talented people that want to work on the kernel and that they could waste a bunch of time by demanding that everyone explain why they're wrong, politely, and at length.
Sometimes for volunteer projects to succeed, not everyone gets to participate. I think it's interesting that people who say "lived experience is the ultimate truth, full stop" then armchair quarterback another person's lived experience, without having lived it.
However, you should be expected to be able to carry on a conversation that wouldn't be confused for a transcript of a 12 year old boy on XBox Live, calling people retards and morons.
If you find code of mine that's shitty, great. Tell me about it. You can even come up to me and say "hey pal, your code here is shit." Fine. You call me names, or you attempt personal shots at me over it, we're done.
This is true for me as a professional, and would be excessively extra true for open source. People contributing to linux are volunteering their time and talent to work on something they believe in, and quite frankly, that those efforts are met with attitudes like those expressed by Linus and Linux still having ANY contributors left is amazing.
I don't care how much you believe that talking like an adult doesn't matter, I would bet every cent I had that if he were at least cordial, linux would be far ahead of where it is now.
Again, you're basing this on the assumption that the talented devs far, far outweigh the untalented ones and that you 100% want any and every contribution. I don't believe that either of those assumptions necessarily holds.
"Why did you use C for the kernel? You should've used C++.",
I'd probably call them a moron too.
Because telling someone to grow up is some very mature behavior.
The word to describe this, among many other behaviors, is to act childish.
There is one thing, and only one thing that is different; one gives into ego, one doesn't. I take ego out of my work because involving ego in work is the best way to ensure shitty work is done.
Not the end of story.
I've read many of the same articles. Carefully. And most of the time I've learned something good about software development.
Not necessarily about how to express myself to co-workers. But about software development.
I think the reason exceptional people are abrasive is that they are primarily harsh to themselves, and that's the reason of their success. Being harsh to others is merely a side effect.
And there are people like that in every profession, for example in modern magic Dai Vernon (one of the most respected magicians that ever lived), who was also infamous for being very critical to bad magicians.
You can be as hard on yourself as you please, and we are often our own worst critic. When those complaints let fly to other ears, they should be phrased a little better.
Again, your preference may vary. Me? I work with adults, I don't care how good the other kids are.
I don't think so; it depends on context. If someone calls you names in context of you doing something stupid, then it's not abuse, it's just being abrasive. Abuse would be had he done it without you giving a reason. And I think we should save the word abuse for the latter (and also perhaps for something where is a profit motive).
I mean, every post from Linus where he uses harsh words has some context like that. He just doesn't randomly throws insults to his colleagues. You can read the insults as an abuse or you can read them as a big yellow warning signs - your choice.
> When those complaints let fly to other ears, they should be phrased a little better.
Here the "should" is a cultural choice. It's a universal, safe option. It's like being polite to people you don't know, or being diplomatic in diplomacy.
But in the cultural context of kernel development, you're already part of the in-group. And in that particular in-group, being called names is normal and accepted by the insiders. That it happens on the Internet, for the outsiders to see, doesn't change the fact that the cultural choice was made freely by insiders.
And people who prefer the former to the latter (as per my previous post) probably don't care to much about being called names when they do stupid thing (being abused, as you call it, but they actually don't want to be really abused or tolerate it either) - because with that mentality, it's results or your own improvement that matters, not so much who is polite. I think Linus would be OK if other people called him names when he does something stupid, however it doesn't happen mostly because people respect him and he doesn't do stupid things very often.
Developing software is almost always about building things for other people to use. It's inherently a social thing, and if you can't play nice with others, you will alienate and run off developers. Of course, there's a difference between getting your code critiqued in review and being treated like a child because you wanted to automate a build. I assume developers are smart enough to know the difference, though.
Linux exists, so that can't be entirely true.
A blunt environment requires a certain level of professionalism but actively knowing you will be challenged when its called for and knowing everyone is simply striving to do whats best for the cause can be really refreshing.
I'm known to request that people tell me when I'm full of shit. I'd much rather have a moment of subtle hostility than a stretch of time where I operate under false assumptions. Once people acknowledge it's not personal, it allows everyone to move much faster.
I know when I was starting out my career I had no idea what good manners were. One time at a milestone review I simply said: "I had to rewrite X's first pass he was using some older tech and there's better ways of doing it now." and it really blew up. My boss took me in his office afterwards and told me that probably wasn't the right thing to say that I had in fact insulted the other guy and he was hurt. Believe me it was never my intention to hurt anyone I was just stating what I did and what I knew. I apologized and we got along afterwards no harm in the long run.
That incident taught me to always be wary of corrections or talking about someone else's work. They put their heart and soul into what they do and I should respect their code and them.
...what? The other guy is too attached to his code.
> [People] put their heart and soul into what they do and I should respect their code and them.
One thing that every good programmer has to learn to do is to be able to disentangle one's ego from one's code. It's very good to be proud of one's accomplishments. It's bad to become so attached to one's work that one suffers injury from criticism of or attempts to improve the work.
If you love your code too much, it'll be harder for you to see (or let others help you see) where it needs improvement and when it needs to be thrown away.
Telling me the truth might hurt my feeling but that is not disrespectful or rude. If I fuck up, tell me so. If you work with me, I'm not going to take your feelings into consideration when making comment's about your work. I'm going to take your experience tho. If you are new, I'll be gentle. But if you have doing this for a long time and should know better or/and like to act like you know it all, you have it coming!
* Of course you are not obligated to respond at all or in a timely manner, but if you do, it's a real treat for the person filing an issue.
* Respect the other person's abilities and skills. When troubleshooting, use language that recognizes the abilities of the other person. For example, instead of "Did you read the documentation?" say "Can you double-check the documentation, especially the section on ____?"
* Keep issues open until the person who filed the issue feels like their problem is resolved. Of course, if the person does not respond for a long time, then there's no harm in closing the issue.
* Get invested in the user's use case. Perhaps this is a "won't fix" scenario, but to truly understand that the issue is out of scope, you should understand exactly what the user needs, up to and including suggesting an alternative solution that is not your software. Sometimes when doing this you realize that in fact the user was correct and their problem is in the scope of your software.
* Be ready to embrace humility. It is common for a user to stop by and drop a piece of information that makes you realize you made a design choice long ago that would be costly to change, both in time and emotionally. At this point you have two choices: humbly admit that you made a mistake and that your software has a limitation due to the mistake, or, humbly admit that you made a mistake and that you'll be working on fixing this mistake in the next major version bump.
* Don't leave code rotting in the main development branch for a long time. Release that code!
* When someone submits a patch, don't nitpick the code conventions. How hard is it to change tabs to spaces and rename a few variables? If the idea behind the code is sound, just merge it and fix the conventions yourself. Style conventions are arbitrary and meaningless. Reduce the friction here for people who bother to look at your source code.
* When you feel you do not have the resources to continue maintaining one of your projects, but users are still filing issues and sending patches, try to hand off the maintainer hat to someone competent. Keep the project alive!
* If your software has a bug, but it's the fault of one of your dependencies, keep a bug report open in your bug tracker too, with a link to the dependency's open bug. Your dependencies' bugs are your bugs too.
I'm sure there are more; that's just what I thought of off the top of my head.
Behavior A: This code is a good example about how you should never write code, it's going to explode in the hand of users, it's going to make our project a piece of crap. Please don't do that, how many times I've to repeat that... you are a long time contrib, it is unacceptable you send me such a crap of stupid patch.
Behavior B: Sorry, I think the patch is not good because it does not test correctly for <some-technical-reason-here>. Without this check the code works today but may fail tomorrow. Because our project needs an high level of stability, we can't merge such a contribution. Please could you review it or perhaps even rewrite it in a way that's going to be very stable? Thanks.
I think both A and B send the same message, but with "A" the problem is that the contributor may never return back or may be offended. Life is already tough, there is no need to be offended randomly because you are trying to give code for free.
We have a tight deadline. Why don't you approach this by doing x and y. After we're finished and have production code deployed, you can refactor into z.
In the process of implementing x and y, the developer will soon learn that z is inferior. If he doesn't, you need to get rid of him because he's incapable of learning.
Here's how I would phrase it: "Thanks for the patch. How does your code deal with condition X? We're a big project that needs to consider the needs of users under many different circumstances, so even if it seems like X only happens in 1 out of every 10,000 cases, that means it happens every five minutes to one of our users somewhere in the world."
The idea is that you know the contributor didn't check for X, but you're giving them the option of saving face. You just asked them whether they considered such a condition and explained why it might be important.
Edit: and if they did consider X, they can explain why their solution is okay. You could be wrong in thinking that it's not.
What else is there?
Fake monks are another good example. They ask you a question, like "what do you want most in the world," which you answer just to be polite. They then write your answer on a token, and give it to you. You feel obligated to accept it because they made it just for you. Then, they ask for a donation in return for the gift you just accepted. Again you feel obligated, this time because you accepted their gift.
The entire thing depends on your polite response to each of their actions. Unless you know where they're going with this, it's impossible to politely escape. By the time I was handing over the money, I knew it was a scam and I still gave them $10 because I felt stupid.
While I have never personally had cause to be impolite during my professional work, sometimes politeness is an improper response.
Before reading this study, I thought politeness helped fix issues faster. Now, I'm of the opinion that it has little or no effect. Of course, polite discourse is more pleasant, so I'll continue to be nice when communicating.
Politeness is maintained on the mailing list, but undesirable posters are tracked down and bullied behind the scenes where proof who's doing it is difficult. This happened to me 10 yrs ago when I started posting casually on a mailing list for a new programming language. I've found overall (not by statistical analysis, but by personal impression) that this tends to happen more when the project leader has a management rather than technical background. Many open source contributors learn their skills in paid employment first so the political skills of online project managers are often more developed than what you find on the job. And because open source contribution is far more global and with a more permanent record than a local job somewhere, the effects are often long-lasting for those involved.
In such good cop bad cop behavior, maybe the real situation tends to show itself over time, just as shown in the study. That project I was trying to politely join has evolved into a blatant "smoke and mirrors" environment that few people trust.
Maybe it can be misused, but it still seems like a good idea.
They should have tracked developer retention to those projects. People might still contribute and fix issues if someone's being a jerk, but are they going to stick around and contribute further? That's the real question to me.
Someone actively contributing for a project for years is much more desirable than someone doing drive-by PRs.
The ideal for an intellectual discourse is to have questions be responded to with more questions. If question is met with answer, then old ground was covered, there was nothing new to see. If answer is met with answer, you're just ramming into each other. (And yes, there are disingenuous questions, but those tend to be "Jeopardy answers".)
Politeness/rudeness does factor into that in that it "bulks up" the rhetoric. You can be a polite bullshitter or an insulting truth-seeker. You can use rhetoric tactically to goad the other person into the questioning mode, or you can use it to shut down the discussion.
Thinking that you have "politeness capital" that you can "spend down" by being occasionally impolite is very wrong.
I've run into people that I refuse to work with, ranging from choosing not to do projects with them to trying really, really hard not to ever have contact with them again, by any means.
I have probably been a guy that people avoided. It sucked. My advice is that, in the long game of doing stuff with other people, being professional and polite is worth it.
Human processes are extremely imperfect and subject to all kinds of biases and conflicts of interest. The cost of attempts at enforcement will be huge and not immediately obvious to everyone. It will silence dissent. It will create chilling effects. It will alter the balance of power towards the rules-lawyers and away from those that just want to get their work done.
I am against any sort of standard here for the same reason I am against government censorship: because it will be turned around and used against us as a weapon, for reasons that will have nothing to do with improving productivity and everything to do with some petty squabble for territory and influence.