What we need, admittedly, is more research and study around this. I know of one study which supports my position, but I'm happy to admit that the data is sparse.
https://arxiv.org/abs/2203.04374
From the abstract:
"By analyzing activity in 30,737 files, we find that low quality code contains 15 times more defects than high quality code."
Most companies have no relation between their code and their products at all - a major food conglomerate will have hundreds or thousands of IT personnel and no direct link between defects in their business process automation code (which is the #1 employment of developers) and the quality of their products.
For companies where the product does have some tech component (e.g. refrigerators mentioned above) again, I'd bet that most of that companies developers don't work on any code that's intended to be in the product, in such a company there simply is far more programming work outside of that product than inside of one. The companies making a software-first product (like startups on hackernews) where a software defect implies a product defect are an exception, not the mainstream.
I definitely expect them to improve. But I also think the point at which they can actually replace a senior programmer is pretty much the exact point at which they can replace any knowledge worker, at which point western society (possibly all society) is in way deeper shit than just me being out of a job.
> This is ego speaking.
It definitely isn't. LLMs are useful for coding now, but they can't really do the whole job without help - at least not for anything non-trivial.
Same with destroying documents. Having a retention period and destroying documents which have PII and could be used for identity fraud is a good practice. It's not generally illegal to do that either.
Where you get into trouble with the courts is when you have a specific obligation to retain or transfer information and you destroy it instead.
If a jury of your peers decides that you configured that firmware to protect your data from thieves, then it is not a problem.
But if a jury of your peers doesn't buy your assertion of that, and instead becomes convinced that you applied that (otherwise reasonable and legitimate) feature with the intent to destroy evidence of a crime so that it doesn't reach the court, then setting it up was a felony.
Also, I hate these kinds of lists. Are we just supposed to take the author by his word? He says:
> If you need examples of real names which disprove any of the above commonly held misconceptions, I will happily introduce you to several.
Then why doesn't he? I'm really curious about that last one: "People have names."
And typing JSON-like data is possible with TypedDict[1].
[0] https://docs.python.org/3/library/dataclasses.html
[1] https://docs.python.org/3/library/typing.html#typing.TypedDi...
To me, namedtuples are a convenience to give a nicer syntax than ordinary tuples in scenarios where I don't want the overhead of having to store a copy of all the keys with every object, like a dict would. Dataclass seems to be even more stuff on top of a class which is effectively even more stuff on top of a dict, but all the use cases of namedtuples are those where you want much less stuff than an ordinary class has. And I don't want to have to define a custom class just as I often don't define a custom namedtuple in my code but use the one the database driver generates based on the query, which is a very common use case for namedtuples as efficient temporary storage of data that then gets processed to something else.
What advantage does this offer?
So if the first step isn't near-perfect (which ASR isn't) and if there is some information or "world knowledge" in the later step(s) which is helpful in deciding that (which is true with respect to knowledge about named entities and ASR) then you can get better accuracy by having an end-to-end system where you don't attempt to pick just one best option at the system boundary. Also, joint training can be helpful, but that IMHO is less important.