There are papers that show positive results for Fagan inspection (1976 onwards) and I'd put good money on there being a straight line between IBM having good results with that method and more recent devs believing that code review is good for finding bugs, despite the loss of a formal structure.

> we think that code review is good for spotting bugs but what it's actually good for is knowledge sharing.

It can be both! I'm not sure it is, but there's nothing contradictory in that.

> Ask engineers why they review code, and most will say they do it to find bugs. In 2013, Alberto Bacchelli and Christian Bird studied code review at Microsoft and classified 570 review comments. 44% of developers ranked finding defects as their top reason for reviewing. Only 14% of the actual comments were about defects. Five years later, Caitlin Sadowski and her colleagues looked at nine million reviewed changes at Google and reached the same conclusion.

Proportion of comments tells you nothing about whether it's a good technique for finding bugs. It just tells you what the spread of comments is across the different purposes for which the channel is being used.

> "Can you review this" [link to PR] is getting a rubber stamp because humans have never been good enough at "just spotting bugs" to make this worth it and now any LLM is better than a human.

Spotting bugs is the one thing we do have evidence that code inspection is good for. But there's a massive difference between the type of code review there's good evidence for and a github-style PR review, so it's mixed but not entirely without foundation.

That's where the difficulty is, where the round trip to testing this stuff on live services is painfully slow and error feedback is mixed at best.

Or maybe him: https://www.networkrailmediacentre.co.uk/news/cable-thief-ja...

"Almost exclusively" would seem to point in a very home-grown direction.

I don't think this is true? Certainly you could have done those things with Delphi but it pre-dated DVCS and CI/CD being common concerns.

> Also you want to reuse code via package management systems.

Again, these tools pre-dated package management systems being in common use because they pre-date internet access at any sort of bandwidth being a reliable assumption. No reason they couldn't have one. Perl did at the time, which I mainly put down to it being in common use where internet access was a reliable assumption, but very little else did.

> And a single code base for several target systems (cross compilation , electron) is also nice

You can absolutely do this with Lazarus, which picked up where Delphi left off. Flash also counts here.

You can tell when it happened, because the E3D v6 nozzle pattern went from being a de facto standard across everything to something you need to buy an adapter for, and nobody really seemed to blink.

The efficient frontier of portfolio theory is also a line. Not sure I get your point here.