Although certainly intentionally not sharing knowledge can be unintentionally rewarded I don’t think the author’s issue is with poor knowledge sharing so much as unintuitive code that requires knowledge sharing.

CVE-2023-2640 and CVE-2023-32629 if you don’t fancy spending an age clicking Object to all the ‘legitimate interest’ cookie shit.

He’s not exactly comparing software to netscape or win 3.11 though, he’s comparing version N of some software to version N-1 or N-2 and noticing that they’re getting worse from release to release. Given the rate of new releases the complexity shouldn’t be increasing that rapidly between releases so I’m not convinced that is the cause per se. I have to agree with the conclusion from the article, testing was more rigorous in the past than it is now. Both because there was less surface area to test back then and because time-to-market pressures were less due to the longer windows between releases.

I feel your pain because as you say these Lutzes are everywhere but I think you hit the nail on the head when you say, “simply paying the person until they choose to leave and tank some other team’s / company’s productivity is less risky than firing them and potentially having to deal with a lawsuit.” This absolutely is the reason why it’s so hard to get rid of these people.

We’ve managed to get rid of two such Lutzes on our team in the years I’ve been in my current job and on the first occasion it took over six months for the managers to build a sufficient case to just put the Lutz on a Performance Improvement Plan. The hope was that said Lutz would take the hint and jump rather than be pushed and luckily for us that’s exactly what happened and the second occasion was just luck as not long after we started complaining about them the mass layoffs in tech started happening and we got rid of them as part of that (though we sadly also lost some good devs in the process).