Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Posted Feb 7, 2025 7:50 UTC (Fri) by kleptog (subscriber, #1183)In reply to: Fighting passive aggression should not entirely fall on the victim by koverstreet
Parent article: The selfish contributor revisited
Really? I don't see how that could be a natural response, nor can I think of a situation where it would actually help. Yelling is never a productive approach.
I guess IRL where you have non-verbal cues to clarify the situation it might work, but over the internet I just don't see how it could ever work as intended.
Posted Feb 7, 2025 9:56 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
If it's not the natural response, why do so many people do it?
As you say, it's never (or rarely) productive, but it usually gives the yeller a short term win, and we are biologically programmed to prefer immediate wins - in life-or-death situations the immediate win is all that matters! But people who can break that tend to win in the end.
The classic psychological experiment is to take a class of kids and give them all a sweet at the start of a lesson. Tell them they can eat that sweet whenever they want, but if they can show you that sweet, untouched, at the end of the lesson you'll give them another sweet. That will very rapidly identify the kids that will do well both later in school, and later in life.
Cheers,
Posted Feb 7, 2025 10:17 UTC (Fri)
by randomguy3 (subscriber, #71063)
[Link] (1 responses)
Posted Feb 7, 2025 13:56 UTC (Fri)
by fishface60 (subscriber, #88700)
[Link]
Success later in life tracks much more strongly with family wealth growing up, much quicker to look at that than wasting time with an experiment with sweets and the wealth disparity suggests a remedial action that could be taken there there were political will to do so.
Posted Feb 7, 2025 13:28 UTC (Fri)
by koverstreet (✭ supporter ✭, #4296)
[Link] (10 responses)
Precisely, IRL you notice when someone is getting annoyed and about to snap at you and you back off.
When it escalates into full blown yelling, no that's never ideal or productive, but generally the breakdown in communication happened well before that point [0]; and the solution to avoiding those breakdowns in communication is to be more direct, not less.
If someone's being an idiot and trying to do something dangerous, you tell them they're an idiot, simple and short, and you move on.
(If you're a senior engineer with a bit of eloquence and you've had your coffee you don't use those literal words, you tell them more specifically what they were doing wrong - but it amounts to the same thing).
Unfortunately, because CoC enforcement is heavy handed, everyone now walks around on eggshells, taking the politeness to absurd levels and avoiding _anything_ that might lead to a blowup or confrontation because if you're smart you don't want to be in the vicinity when that gun goes off. Not a healthy situation.
[0] or you have someone who's seriously stressed out and needs a break, or just an asshole, but that's a different problem.
Posted Feb 7, 2025 15:26 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Unless the person doing the yelling is in charge; in which case they're rewarded for "strong leadership" and "getting results".
Our society is replete with countless examples of this sort of behavior, and how it is explicitly *rewarded*.
Posted Feb 7, 2025 16:07 UTC (Fri)
by stijn (subscriber, #570)
[Link] (8 responses)
Why not just point out the first part (trying to do something dangerous)? What is gained by the insult? I do know what is lost - this fosters a shouty atmosphere that drives people away. This (kitchen, heat) is sometimes mistaken for a meritocracy, but the absence of a very basic level of (workplace-type) civility puzzles me. I'm a complete outsider to the kernel, but do participate a bit in open source. Kitchen/heat type environments create an in-crowd culture - I venture it does not help long-term sustainability.
> (If you're a senior engineer with a bit of eloquence and you've had your coffee you don't use those literal words, you tell them more specifically what they were doing wrong - but it amounts to the same thing).
For me it really does not amount to the same thing. I may not be the only one.
Posted Feb 7, 2025 16:27 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Of course the choice of words affects perceptions, emotions and form matters.
It's as far from an "exact science" as it can be though; maybe why it's tempting to dismiss it?
Posted Feb 7, 2025 16:42 UTC (Fri)
by koverstreet (✭ supporter ✭, #4296)
[Link] (6 responses)
We were talking about the situation where someone is being passive aggressive and dismissive, i.e. you've already tried the first option. In that case, making an issue out of it rather than letting it slide or simmer is absolutely the right call.
> I'm a complete outsider to the kernel, but do participate a bit in open source. Kitchen/heat type environments create an in-crowd culture - I venture it does not help long-term sustainability.
Well, the thing you have to keep in mind is: the kernel is safety critical, high stakes code. Most of the world's infrastructure runs on Linux - the stuff that doesn't is a rounding error, and whatever additional testing and validation there might be before it's put into mission critical applications can only provide an additional safety margin, not real assurances.
We have to take responsibility for our work and own our mistakes, that has to come first.
In other safety critical environments (i.e. anything blue collar; imagine working on heavy machinery, or even installing brake lines in a shop), if you screw up in a way that's dangerous for someone else you can expect to get chewed out. That's just life. Take it on the chin, learn from your mistake, and move on; if you try to flip the script and say "CoC violation!" in that kind of environment you won't be working there long.
In my career I've had to deal with and chase down quite a few silent data corruption bugs, often introduced by other people into code I wrote who were being sloppy with process. That's always a really, really stressful event, and you have to think about what's at risk; people's entire lives are on their computers these days, think about the photo albums that might not be backed up.
If we want the kernel to be a less stressful place to work, the way to do that is:
Posted Feb 7, 2025 17:43 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
Been there, done that :-)
Writing a critical path analysis program.
The code said:
1) Find a segment with no predecessors and process it.
Of course, a colleague of mine looked at the code that abandoned the next segment, said "what's that for" and deleted it (leaving the comment there, of course), and then couldn't understand why the code assumed the user had a time machine handy ... (ie would happily process temporal loops without realising there was a problem).
Cheers,
Posted Feb 7, 2025 17:50 UTC (Fri)
by koverstreet (✭ supporter ✭, #4296)
[Link] (2 responses)
Posted Feb 7, 2025 21:14 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Feb 7, 2025 21:46 UTC (Fri)
by koverstreet (✭ supporter ✭, #4296)
[Link]
So before I started working on the kernel, splitting bios (block layer IOs) was an unholy mess. There was no reasonable way to do it if the bio was more than a single segment, so upper layers would query lower layers "can I add another page to this bio?" as they were building it up. Oof...
This was all stuff that predated the more modern stacking block drivers (dm, bcache); it kind of worked for md where the restrictions were static, but quickly fell over if they were dynamic. And it was a whole pile of fragile, brittle slow code.
So I got rid of that and made efficient bio splitting possible by introducing a novel concept - the iterator. That made the biovec immutable, meaning it could be shared by splits. Novel stuff. It also meant that you could take a bio you were processing (in the middle of the io stack), stash a copy of the iterator somewhere, submit it, and then on completion restore the iterator to its previous state and walk precisely the same segments you saw when it was originally submitted to you (say for bouncing, decryption, what have you).
Deleted a ton of code from the block layer and device mapper, and bcache was pretty heavily reliant on all this stuff. Worked great, but..
It seems the maintainers never got the memo on things you can and cannot do with bio iterators. Saving and restoring iterators works great, because then it doesn't matter what the lower layer does with the bio (and it can advance the iterator, truncate it, or both, or neither). But an iterator was too big for them, they wanted to be able to restore the bio to its previous state by just rewinding it (by some number of bytes they pulled out of the ether).
So they merged an entire standard normal looking API to do this completely broken "bio_rewind()" thing, and then drivers started using it in predictably broken ways. And I didn't find out about it by getting CC'd on any patches - no, I found out about it through reports of bcache corrupting data; much shouting was required to get it reverted. And then they tried to merge it again...
Posted Feb 8, 2025 6:29 UTC (Sat)
by interalia (subscriber, #26615)
[Link] (1 responses)
But are those environments really similar to OSS work though? Strangers don't turn up at the shop doing an unprompted change to your heavy machinery or to the vehicle. In the blue collar manual labour work you're talking about, the person is a team member that got explicitly hired by you. Or they're a team member and you're their more senior peer/mentor. And the justification for occasionally shouting in this context is that it can convey urgency and gravity where necessary. If they do something wrong like they're about to screw in the wrong bolt, you might have to urgently prevent or fix their action before the machine goes haywire and explodes.
This isn't the case in an OSS setting, someone just turns up and supplies a patch or an idea. The team is all ad-hoc and made up of self-selecting interested parties. But patches don't get auto-applied to the code, so often nothing bad has actually happened yet or is imminently happening. The machine doesn't have the wrong bolt applied and it isn't about to explode. There's no urgency at all. Or sometimes maybe it has been already applied, and you see a problem, but it still takes quite a while for code to work its way to production deployments. The yelling doesn't actually achieve anything now.
If, despite previous advice, someone repeatedly tries to use the wrong bolt/bad technique in their patch/idea, you can tell them that those patches/ideas won't be considered as long as that error is still there and continues because it's not of sufficient quality. It's a brief but firm one liner that still doesn't require yelling or being passive aggressive.
Posted Feb 8, 2025 7:07 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link]
OSS didn't invent non professional collaboration, though. In the blue collar world, sharing your shop with a buddy or acquaintance based on trust, a demonstrated level of competence and some sort of quid pro quo is absolutely the norm.
And in the OSS world, we're not forced to take patches from random strangers; people demonstrate their competence and trustworthiness over time and we choose who we want to work with based on that.
It's different in the OSS world because there is indeed a higher _expectation_ that we'll try to collaborate and make it work, but fundamentally it's all about trust, and if you can't demonstrate that your work is trustworthy you can't expect to get it in - and the way to become competent, to develop that trust, is to work well with others; listen, learn, own your mistakes and all that. That part's the same anywhere.
> If, despite previous advice, someone repeatedly tries to use the wrong bolt/bad technique in their patch/idea, you can tell them that those patches/ideas won't be considered as long as that error is still there and continues because it's not of sufficient quality. It's a brief but firm one liner that still doesn't require yelling or being passive aggressive.
Yup, and that part works well when there's a clear line of competent authority.
Where you see the real problems and drama occurring is where there isn't a clear line of authority; either the authority figure has too much to do, or you've got a maintainer who's screwing up and unwilling to admit it (lose face) and listen or back down. And since there's never enough true experts, and everyone's human and makes mistakes, those situations happen quite a lot.
Fighting passive aggression should not entirely fall on the victim
Wol
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
- slow down a bit, take care with the code you write
- listen well, have empathy for the people you work with and the people who will be running and relying on your code
- own your mistakes, and make sure mistakes are addressed with a minimum of drama: seeing conflict addressed /well/ instead of being swept under the rug is a big builder of trust
- and embrace tools that make it easier to ship code we can rely on: better testing, Rust
Fighting passive aggression should not entirely fall on the victim
2) If the successor segment only has the current segment as a predecessor, go back to (1) and process it.
Comment : If there's any other predecessors DO NOT process the next segment because that's the way you find temporal loops.
3) Forget the next segment, search for a different segment with no predecessors and go back to (1) ...
Wol
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Wol
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim
Fighting passive aggression should not entirely fall on the victim