17 ms·

Software development: do good manners matter?

109 points by cpeterso 11y ago

sanderjd 11y ago
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.
- bryanlarsen 11y ago
  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.
  - rm_-rf_slash 11y ago
    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.
  - hueving 11y ago
    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.
  - sanderjd 11y ago
    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.
deadprogram 11y ago
How does this explain communities where there is a lot of rudeness and bullying, and yet the projects themselves are successful? Are those projects successes despite their manners?
- this_user 11y ago
  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.
  - garrettheaver 11y ago
    Speaking of being polite...
    - strictnein 11y ago
      Next study: does politeness in HN responses result in greater upvotes?
    - eropple 11y ago
      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.
yarrel 11y ago
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.
- sz4kerto 11y ago
  This is not a result. Really, look at the article. No serious paper would publish this.
- 13thLetter 11y ago
  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.
vox_mollis 11y ago
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.
nickbauman 11y ago
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. Torvalds position: https://www.youtube.com/watch?v=JZ017D_JOPY 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-high-cost-of-rudeness-at-w/ https://hbr.org/2013/01/the-price-of-incivility https://hbr.org/2013/01/the-price-of-incivility
- jerf 11y ago
  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.
  - nickbauman 11y ago
FussyZeus 11y ago
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.
- deleted 11y ago
  [deleted]
- bonzini 11y ago
  > I've read Linus' numerous public outings of what he thinks are less talented developers He doesn't. He just thinks they're in the wrong _that one time_.
  - FussyZeus 11y ago
    Does that make it better somehow?
    - Dru89 11y ago
      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.
      - FussyZeus 11y ago
        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.
brd 11y ago
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.
- cjcenizal 11y ago
  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.
cprayingmantis 11y ago
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.
- chahex 11y ago
  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.
- simoncion 11y ago
  > 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 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.
iamleppert 11y ago
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.
- segmondy 11y ago
  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!
AndyKelley 11y ago
How to be a delightful open source contributor: * 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.
the_cat_kittles 11y ago
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.
antirez 11y ago
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.
- maratd 11y ago
  How about C: 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.
  - davidw 11y ago
    antirez is approaching it from the open source point of view - businesses are different in many ways.
- Swizec 11y ago
  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.
sz4kerto 11y ago
The article is an methodological disaster. Calculating p multiple times and declaring that in most cases the result is significant? Just wow.
sjclemmy 11y ago
Stick to the facts. Be respectful. What else is there?
slavik81 11y ago
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.
- fsloth 11y ago
  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..
  - BookmarkSaver 11y ago
    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.
ggreer 11y ago
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.
- mucker 11y ago
  Well done.
  - mucker 11y ago
    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.
vorg 11y ago
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.
- peterevans 11y ago
  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.
  - AUmrysh 11y ago
    Even though they weren't able to see the offline arguments, it's still telling about a project when the arguments are brought out into the open.
- skybrian 11y ago
  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.
whatever_dude 11y ago
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.
calebm 11y ago
Yes.
chipsy 11y ago
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.
kabdib 11y ago
Yes. 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.
mucker 11y ago
I'll let Job's ghost know about the results. It will change everything.
htns 11y ago
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.
yakult 11y ago
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.
pg_is_a_butt 11y ago
fuck you
xiaoma 11y ago
Serious question here: Of those who have led the development of hugely successful OS in the past generation, who had the best manners when giving feedback? Was it Bill Gates, Linus Torvalds or Steve Jobs?
- jleyank 11y ago
  It would be useful to learn if the BSD folks and their successors, or the original Bell Labs/Unix folks share these personality traits. Has anybody dealt with Bob Cutler, who had much to do with VMS and NT? Bill Joy? Fred Brooks seems to have a different reputation, and he helped create an OS as well. Is it generational? Being unable to alter one's personal-interaction style to reflect the interaction will shed talent, so it's only safe to do in a talent-rich environment (or an environment where the talent's constrained in some way). People working in what they consider hostile environments act to minimize stress, which results in fewer ideas, fewer discussions, way less criticism and crappier products. Or they walk. Yeah, Linux development "works". It has sufficient talent to continue. Until it's displaced, we won't be able to tell whether it was run as well as it could have been.
  - xiaoma 11y ago
    There was a lot less competition back in the Bell Labs days. From what I've heard of people working at MS in the 80s and 90s, feedback was possibly more searing than it is on the linux mailing lists. I hope it's not the case, but based on available evidence it looks like there may be advantages to hostile environments. Maybe some people channel the stress into more ideas, fiercer discussions and better products (as Amazon does). I've never been in one of those environments first hand though.

109 points by cpeterso 11y ago

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.

bryanlarsen 11y ago
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.
- rm_-rf_slash 11y ago
  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.
- hueving 11y ago
  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.
- sanderjd 11y ago
  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.

deadprogram 11y ago

How does this explain communities where there is a lot of rudeness and bullying, and yet the projects themselves are successful? Are those projects successes despite their manners?

this_user 11y ago
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.
- garrettheaver 11y ago
  Speaking of being polite...
  - strictnein 11y ago
    Next study: does politeness in HN responses result in greater upvotes?
  - eropple 11y ago
    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.

yarrel 11y ago

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.

sz4kerto 11y ago
This is not a result. Really, look at the article. No serious paper would publish this.
13thLetter 11y ago
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.

vox_mollis 11y ago

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.

nickbauman 11y ago

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. Torvalds position: https://www.youtube.com/watch?v=JZ017D_JOPY 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-high-cost-of-rudeness-at-w/ https://hbr.org/2013/01/the-price-of-incivility https://hbr.org/2013/01/the-price-of-incivility

jerf 11y ago
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.
- nickbauman 11y ago

FussyZeus 11y ago

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.

deleted 11y ago
[deleted]
bonzini 11y ago
> I've read Linus' numerous public outings of what he thinks are less talented developers He doesn't. He just thinks they're in the wrong _that one time_.
- FussyZeus 11y ago
  Does that make it better somehow?
  - Dru89 11y ago
    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.
    - FussyZeus 11y ago
      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.

brd 11y ago

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.

cjcenizal 11y ago
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.

cprayingmantis 11y ago

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.

chahex 11y ago
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.
simoncion 11y ago
> 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 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.

iamleppert 11y ago

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.

segmondy 11y ago
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!

AndyKelley 11y ago

How to be a delightful open source contributor: * 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.

the_cat_kittles 11y ago

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.

antirez 11y ago

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.

maratd 11y ago
How about C: 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.
- davidw 11y ago
  antirez is approaching it from the open source point of view - businesses are different in many ways.
Swizec 11y ago
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.

sz4kerto 11y ago

The article is an methodological disaster. Calculating p multiple times and declaring that in most cases the result is significant? Just wow.

sjclemmy 11y ago

Stick to the facts. Be respectful. What else is there?

slavik81 11y ago

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.

fsloth 11y ago
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..
- BookmarkSaver 11y ago
  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.

ggreer 11y ago

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.

mucker 11y ago
Well done.
- mucker 11y ago
  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.

vorg 11y ago

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.

peterevans 11y ago
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.
- AUmrysh 11y ago
  Even though they weren't able to see the offline arguments, it's still telling about a project when the arguments are brought out into the open.
skybrian 11y ago
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.

whatever_dude 11y ago

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.

calebm 11y ago

Yes.

chipsy 11y ago

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.

kabdib 11y ago

Yes. 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.

mucker 11y ago

I'll let Job's ghost know about the results. It will change everything.

htns 11y ago

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.

yakult 11y ago

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.

pg_is_a_butt 11y ago

fuck you

xiaoma 11y ago

Serious question here: Of those who have led the development of hugely successful OS in the past generation, who had the best manners when giving feedback? Was it Bill Gates, Linus Torvalds or Steve Jobs?

jleyank 11y ago
It would be useful to learn if the BSD folks and their successors, or the original Bell Labs/Unix folks share these personality traits. Has anybody dealt with Bob Cutler, who had much to do with VMS and NT? Bill Joy? Fred Brooks seems to have a different reputation, and he helped create an OS as well. Is it generational? Being unable to alter one's personal-interaction style to reflect the interaction will shed talent, so it's only safe to do in a talent-rich environment (or an environment where the talent's constrained in some way). People working in what they consider hostile environments act to minimize stress, which results in fewer ideas, fewer discussions, way less criticism and crappier products. Or they walk. Yeah, Linux development "works". It has sufficient talent to continue. Until it's displaced, we won't be able to tell whether it was run as well as it could have been.
- xiaoma 11y ago
  There was a lot less competition back in the Bell Labs days. From what I've heard of people working at MS in the 80s and 90s, feedback was possibly more searing than it is on the linux mailing lists. I hope it's not the case, but based on available evidence it looks like there may be advantages to hostile environments. Maybe some people channel the stress into more ideas, fiercer discussions and better products (as Amazon does). I've never been in one of those environments first hand though.