RE: how to explain complex things that were originally invented by engineers, and often for engineers? Yeah, that’s a tough one, indeed.
Having now been on both sides of that problem (as an engineer creating things for tech writers to describe and trying to document things invented by (and, more to the point, named by) engineers, the answer is to get the two together very early on. Simple!
When I was an engineer designing a new feature or library, I had a hard enough time trying to figure out what it had to do and how to get it to do that (and then iterate through that process several times). I’d make up names that were good enough to get the job done in whatever context I was working and then those would slowly get baked into the code. When things settled down, I’d contact a (generally very scarce and overworked) technical writer to write something that would then make it easy to understand and to use (how hard could THAT be, anyway?!)
Well, now I know.
Later, as a writer, I was called in during the early stages of another development project. Alas, early for me was still late in the game for the developers. They’d already baked in the logic and many of the names and concepts. Worse, I came in cold while the developers had had months of discussion and early design. So, in a 1-hour meeting, I was expected to do something that made it all easy to use. (Again, how hard could that be?)
Ease of use starts at the beginning of the design and must be considered as a design requirement throughout the design and development process–it rarely (i.e. never) happens accidentally. Monitor resolution and security protocol negotiation were probably not designed with ease-of-use as a requirement. Often, such things are driven primarily by hardware limitations (e.g. squeezing the most performance out of slow communication lines, limited control signals, etc.) So, what they save in hardware engineering and manufacturing costs, they spend in customer support and training. Whether that’s a net win or loss, depends on many things.
So, the TL;DR version is that engineers and technical writers need to understand each others’ workflow and each others’ contribution to the end product. However, that’s going to involve a lot of retraining on both sides.
WRT computers talking and thinking, in HTTP and REST, we use request and respond, evaluate and determine, and the like.