On type safety in natural language

Byrne Hobart has a characteristically fun and insightful piece [$] analogizing the "four Amazon answers" to types in programming.

Some reactions:

1. As I've written, many of us pay too little attention to military traditions and to radiotelephony conventions when we're thinking about clear, mind-improving communication. It's no coincidence Socrates obsessed over communicative "rules of the dance."
2. But the lesson I'd draw is a bit different: what's important is often getting communicators in the right roles, not improving the precision of a given response. I'm tempted to believe that the problem of dependency management is prior to, and harder than, the problem of improving accuracy and precision. (And that this is less sensitive to scale that you might think.)
3. This makes sense, because types are only one way, and in practice often not a reliable one, to achieve accuracy in software. Moreover, the kind of accuracy it gets you is often misunderstood, because it's very hard to make the guarantees of a type system extend to relevant, valuable guarantees at the logical level.
4. So, while ambition and stronger typing might be correlated, I'd be more guarded than Byrne is when he says that "type-safe programs can be bigger, and the organizations that insist on them are implicitly more ambitious than the ones that don't." Programs that have good correctness checks can be bigger: stronger typing is one way to accomplish this, but only one. Good testing is another approach (I don't mean to imply that it's an orthogonal one). And I've seen strong typing prevent a code base from growing: complicated, ill-defined types can be so brittle that engineers either (i) leave the code in place, unable to change the types, or (ii) switch all those complicated types to Any (or some analogue of Any) when they need to change something.
5. I'm tempted to think of the Amazon approach less as a restriction on communication and more as a restriction on email. Certain questions can't be answered well, or at least felicitously, with one of the four answers ("do you think that John Doe will be back to full productivity soon?"). One way to think about this policy is as pressure to keep conversations off email that for legal reasons should not be conducted over email.
6. Further evidence for this is that many more companies than Amazon enforce similarly strong "typing" in other software (e.g., time estimates in JIRA). It's not clear how much this benefits them, especially if you try to control for other cultural factors.
7. Yet further evidence: big tech companies are famous for intellectual cross-pollination. Yet most non-Amazon FAANG employees (I'd bet) do not know about the "four email answers" policy, but many of them really hate and discourage email. I think this says something about what the policy's real effect and purpose is. (Is it four answers too many? Extending the typing analogy, perhaps "the best code is no code at all.")
8. People (I'm not implying Byrne is one of them) sometimes act as if the code-quality effects of strong typing are empirically proven. I do not think this belief can survive an honest encounter with Dan Luu's literature review.