Software development: do good manners matter?
peerj.com
peerj.com
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:
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.
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.
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.
These comments, hyperbole or not, definitely give the impression that there is no real distinction being made.
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.
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.
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?".
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. :)
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.
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.
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.
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.
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.
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!
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.
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.
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.
Linux exists, so that can't be entirely true.
Because telling someone to grow up is some very mature behavior.
The word to describe this, among many other behaviors, is to act childish.
* 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.
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.
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.
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.
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.
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.
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.
Are those projects successes despite their manners?
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.
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.
What else is there?
Was it Bill Gates, Linus Torvalds or Steve Jobs?
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.
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.