
Software development: do good manners matter? - cpeterso
https://peerj.com/preprints/1515v1/
======
nickbauman
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
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
I think your point is valid (and I agree).

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?

~~~
kazinator
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.

~~~
nickbauman
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.

~~~
simoncion
> 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.

~~~
nickbauman
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.

~~~
simoncion
> Uh, It sounds like we're in violent agreement?

So we are! I -somehow- _completely_ failed to understand the subtext in your
statement. :(

Mea maxima culpa. Please disregard my stupidity.

------
antirez
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
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
antirez is approaching it from the open source point of view - businesses are
different in many ways.

------
ggreer
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
Well done.

~~~
mucker
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.

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

------
iamleppert
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
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!

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

~~~
btilly
_I 've read Linus' numerous public outings of what he thinks are less talented
developers, and it's childish, end of story._

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.

~~~
FussyZeus
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.

~~~
asgard1024
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.

~~~
FussyZeus
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.

~~~
asgard1024
> 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.

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

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

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

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

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

~~~
simoncion
> 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.

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

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

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

~~~
13thLetter
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.

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

------
deadprogram
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
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
Speaking of being polite...

~~~
eropple
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.

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

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

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

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

------
sjclemmy
Stick to the facts. Be respectful.

What else is there?

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

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

------
calebm
Yes.

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

