ubu7737

> code which is hard to test is almost always going to be hard to maintain

This is a pointless equivalence to make. You're trying to suggest that code which is hard to test could be written differently, and better. This is not always true, and therefore useless to say.

STUXNET was very difficult to test. Reports are that it required an entire Israeli nuclear facility as a test environment. Would you suggest that STUXNET was written to a substandard level of professionalism? I doubt it.

I don't really agree. It's not like raising the minimum wage will train workers for tasks they can't already perform. The shortage of laborers in specialized task domains is endemic to our changing times, and I think framing the challenge as an old-school labor rights issue is just... terrible and stupid.

My experience is very similar to yours. I see my peers as too-easily crushed most of the time, and insist on my own way more than most.

I just watched Dept of Reclamation video on the designed failure of the Auburn Cofferdam. I get it now.

A failure of the emergency spillway could compromise the west side of the entire structure, no? What prevents that outcome?

To me it's sort of like people who use an index card when they read. They move it line-by-line down the page so their eyes have an easier time traversing the line of text.

If this is the crutch that makes you a better programmer, who am I to discredit the practice? But dogma has no place in software engineering.

> XML's saving grace was that it came with good schemas out of the box

JSON is inherently "schema-less". So this provides us with no grievance.

> something that has, at best, extremely weak types

You provide the reader with nothing that indicates that strong-typing is important for JSON use-cases.

> schema equivalents that are bolted on, rarely used, and end up relying on humans understanding exactly what the data looks like

There are no schemas in JSON.