Simplified Technical English (opens in new tab)

What I think is interesting here, is that with so much detail specified, tools could be created to write and check technical documents. I suspect with LLMs and the like becoming broadly available, that could also help.

On the other hand, I've seen technical documents that were accurate and correct, but they obfuscated more than clarified. One document I remember specified linker records with items like 0x54 instead of 'C' and end-of-record instead of '\n'. It seemed a little too pedantic instead of common sense.

That said, for many applications following all of it is probably not worth it. It uses some very specific terminology with specific approved meanings for words that are commonly used. e.g "follow" can never be used in "follow these instructions", but in can be used in "follow the green lights to the nearest staircase". This makes a lot of sense, but sticking to one approved meaning for a hundreds of verbs and adjectives is hard word and requires specific expertise.

The only movement that's happening today is where individual ERP/PDM/ILS solutions are beginning to just incorporate the tech writing tools wholly into their ecosystem, rolling them up into SAP/Epicor/TeamCenter/Aras/etc. Or even into the CAD system[1]. Doing S1000D in Program X? Whelp, better get TeamCenter spooled up so you can do the writing and publishing.

What does that do for interoperability? Nothing good! But it doesn't matter - S1000D instances weren't interoperable to begin with. The one good thing from this, is that it might - and I do want to underline might - give the pubs team a somewhat better chance of optimizing their data flows from other business systems. Yeah. Might.

All this crap makes me think of Daniel Dennett's famous essay on Chmess. How "chmess" sucked in a whole generation of chess scholarship, with no one stopping the train for one hot second to ponder that they're blowing their entire careers optimizing something that never happens.

[1] Oh yeah, CAD for maintenance manuals. The engineering design system, that's a great place for parts lists.

STE, unlike Simplified English or International English or its many cousins, has what I like to call the "ISO Kiss of Death". Basically, with IKoD, you get a cabal that takes over a spec, and then it defends the spec like a kung fu master defends his secret style. Thing is, the cabal also mandates how documents get written, so now you have to go to the secret Kung Fu School to learn the Secret Style if you want to, yknow, deliver a product.

This can go on for decades, multiple decades, before something maybe breaks the chain - some busybody in procurement, or a major national embarassment, or an overactive journalist revealing how making a PDF file managed to cost two hundred million dollars. Or someone raising their hand and saying, um, sirs, very sorry to interrupt, but this is all common capability in the Lands Outside the Secret Temple.

Fighters from secret temples never amount to much.

It's still pretty mad!

I get why these technical expressions counter productive, they create uneven cognitive load on speech center in the brain rather than distributing interpretation task wide across from visual and motor and various cortex that would be readily available. But that's the goal; to minify dependency graph and remove variances coming from implementation differences.