Heck, it is objectively measured by a LLM adjacent seller like Faros AI.

The more LLM code in your company, the slower delivery and more bugs that you likely find on production.

Literally data is at 60% of daily tasks being LLM assisted, the throughput is (every value is an average) 500% slower, company delivers 10% less and the bug rate is +50% per PR and +250% production incidents.

At 40% of daily task being LLM assisted the bug rate was +9% vs pre-LLM.

Considering most people only know procedural programming and are calling it functional/objective…

A debugger will always interfere with the processes you are looking at, hence making debugging of multithreading-related errors a game of whack-a-mole.

It’s a very pleasant debugging experience when you can easily switch threads, have them log what happened first, check the variables in the thread at the moment in time it was hit (vs now), etc. etc.

This and an easy way to attach a line-by-line debugger and I’m golden.

I believe that is a vast minority of developments. And tbh multithreading debugging is a breeze in C# on Rider (except race conditions, those will always be tricky, but also easily identifiable).

In the early 2010s there was a trend to throw in obfuscation into the minis.