Am I not teaching people properly? Isn't that exactly what this very talk was about? Did you read the 3000 words that went along with the talk? Did I say anything wrong there about how you can properly submit code to the kernel and what to do?
I don't "mock" people, I critique code, and sometimes, that includes pointing out horrible examples of where the author went totally wrong, in the code. If you were someone who relies on Linux, don't you want the maintainers doing that in order to ensure that the code is of the highest quality?
Take some time this week and provide review comments on code submissions to the Linux kernel. That will help everyone out (the authors, and the maintainers), and give you a glimpse of how difficult this task really is.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 1:57 UTC (Tue) by daglwn (subscriber, #65432)
[Link]
> Am I not teaching people properly?
Not if you're making personal attacks, no.
> I don't "mock" people, I critique code, and sometimes, that includes
> pointing out horrible examples of where the author went totally wrong, in > the code.
It's all about the language. It really is. Providing a strong critique is good. Calling someone or something someone has created "stupid" is not.
Your whole talk is predicated on the assumption that the only the contributors are doing it wrong. There are two sides to this coin and the maintainers also need to improve. I could give an equally compelling talk about how to make contributors less grumpy. We're all human and we all have improving to do.
I've been through enough code reviews to know that it is challenging. Much of the challenge is in remaining professional and taking the time to mentor people rather than castigate them.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 4:34 UTC (Tue) by jrn (subscriber, #64214)
[Link]
> Providing a strong critique is good. Calling [...] something someone has created "stupid" is not.
Why not? Isn't it a useful way to teach people to start looking at the effect (both direct and on maintainability) of their own work critically and to think less sentimentally about their code?
Plenty of people have told me some code that I wrote was stupid and been right. I am generally grateful for the reality check.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 6:20 UTC (Tue) by liw (subscriber, #6379)
[Link]
Bob, 8, has written an essay for school. The teacher reads it out aloud to the class, and then tells everyone it's a stupidly written essay, full of spelling mistakes and the storyline is silly too. Does this make Bob learn to write better essays? Does it help if the teacher also goes through every mistake Bob made and suggests improvements?
For most instances of Bob, it doesn't help him to be taught that way. Some instances of Bob don't care, and will learn anyway, but those instances are in the minority. The majority of Bobs will be upset, and hurt, and will have a hard time accepting any lessons from the experience, and indeed may well have a harder time accepting any lessons from that teacher in the future.
Now, it's true that the emotional lives of 8-year-olds and adults are different. On the whole, adults can take more emotional stress and conflict, but the general effect is the same, just less strong.
There is a subset of programmers who have what is called a thick skin: they can take a lot more abuse than the average person without being upset much. Given the way text-only communication over the Internet tends to filter away subtle emotional expressions, it's very easy to express yourself in a way that seems neutral to you, but feels hurtful to the recipient. Without an effort to avoid that, mailing lists for free software development tend to push out those who are more easily hurt, making the list be mainly populated by those with thick skins.
That's not a good thing. Apart from any moral aspects, it reduces the number of potential participants a lot: those who submit patches and feel hurt, and those who are watching and decide to not even submit a patch.
Note that this is all about how you express criticism, not at all about having to be accepting and supporting of anyone who submits any kind of patch. It's perfectly fine to criticize and reject patches. You can, however, be nice about it.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 7:23 UTC (Tue) by bronson (subscriber, #4806)
[Link]
I take it you don't subscribe to LKML.
There's no need to encourage every mediocre Bob. There's only a need to encourage excellent, self-motivated Roberts, and to actively discourage well-meaning but noisy Bobbies.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 8:03 UTC (Tue) by dgm (subscriber, #49227)
[Link]
At least until they turn 18.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 8:36 UTC (Tue) by dgm (subscriber, #49227)
[Link]
> it reduces the number of potential participants a lot: those who submit patches and feel hurt, and those who are watching and decide to not even submit a patch.
Last time I looked there was not a shortage of people submitting patches, but of people reviewing them. And also, when calling someone "a moron" openly on a mailing lists opens yourself to a lot of criticism, thus people try to avoid doing it unless they have good reasons.
In practice (not that I follow LKML that much lately, but still) I haven't seen people calling newbies "noob" or "stupid" just because, but when they did something stupid indeed. If someone does, they tend to get routed around by the rest of the community, because they tend to be "toxic" people.
To summarize: If Linus Torvalds calls you names, better pay attention. And better ask first and try to educate yourself before posting stuff on a mailing list full of busy people.
And let me tell you a little tale, too:
"Bob has come to the kitchen, where his father is cooking dinner. While his father is not looking, he grabs a knife and starts cutting some vegetables, just like he has seen his father do so many times. But Bob is not very good at handling the knife, and it's too big for his hands. His father, hearing the noise, tells his son how to properly handle the knife, and then keeps on with the cooking. A minute later both are running to the hospital because Bob has a deep bleeding cut on his left hand.
After that episode, Bob's father tries to avoid using harsh words. It's his own fault, after all. A week later, while Bob's father observes the remains of the burnt family kitchen, he cannot avoid to ask himself if this all could have been prevented somehow."
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 14, 2012 8:55 UTC (Thu) by spanezz (subscriber, #56653)
[Link]
You seriously think it would have helped if the first reaction of Bob's father at Bob badly cutting himself had been publicly shaming him?
My feeling of distress towards people advocating mocking people in public is kind of being shadowed by your disturbing choice of example.
I would expect that any normal father would, on seeing that Bob is playing with a dangerous knife, tell him that he should help dad with that only after he grew up a bit and has more experience with dangerous tools. And if Bob is really interested in helping with knives, give him a small blunt knife to help cut soft fruit for the fruit salad.
That also sounds like a reasonable, grown up reply (aside of course of the patronising tone) to inexperienced but eager people wasting other people's time on LKML.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 17, 2012 7:17 UTC (Sun) by yeti-dn (guest, #46560)
[Link]
So you agree that kernel devs should tell people that they should try to help dad with that only after they grew up a bit and have more experience with dangerous tools. Good.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 17:28 UTC (Tue) by gregkh (subscriber, #8)
[Link]
The number of people contributing kernel patches keeps increasing every year, and the rate of patches submitted also keeps increasing.
So, something we are doing is correct here. Remember, we have a overabundance of kernel developers, and we purposefully waste their time in order to make the project better overall. And so far, it seems to be working, if you think otherwise, that's great, how do you prove that?
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 13, 2012 4:57 UTC (Wed) by jrn (subscriber, #64214)
[Link]
Thank you.
I agree with what you said. It suggests to me that providing a strong critique is not always good, at least in public, unless you are very tactful. Better to find a minimal set of hints that makes it clear what people interested in the patch can do next.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 13, 2012 18:02 UTC (Wed) by bronson (subscriber, #4806)
[Link]
That would be true if patch reviewers were in unlimited (or even sufficient) supply, and if iteration was a viable way to develop a decently sized kernel patch.
Neither of which is currently the case.
LinuxCon Japan: Making kernel developers less grumpy
Posted Jun 12, 2012 17:26 UTC (Tue) by gregkh (subscriber, #8)
[Link]
> Your whole talk is predicated on the assumption that the only the contributors are doing it wrong.
Have you read or seen this talk? I do not think that was the assumption at all, and I pointed out that the large majority of patches I get are just fine, but I still get lots of incorrect ones, and here are some specific examples of what not to do.
It is not my job to mentor anyone, which people here seem to forget. It is my job to guide them in how to correct incorrect code, up to a point.
For each and every maintainer to be a personal mentor to the thousands of kernel developers does not scale at all, and is not anything that anyone has ever said is the job of any kernel developer or maintainer to do.
Remember, we waste kernel engineer's time, as that is what we have a surplus of at this point (and have for the past 8 years or so.) We do this so that the project overall gets better and succeeds, and so far, we seem to be doing a good job at this. If you have statistics that point out otherwise, please let us know.